From nobody Sat May 7 07:47:43 2016 Return-Path: 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 CEEAF12B052 for ; Sat, 7 May 2016 07:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 4AYzrbfZjJkF for ; Sat, 7 May 2016 07:47:40 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id 68EE312B03F for ; Sat, 7 May 2016 07:47:36 -0700 (PDT) X-AuditID: 1207440e-f07ff700000008c5-17-572e0007fabb Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 57.A4.02245.7000E275; Sat, 7 May 2016 10:47:35 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u47ElXul031714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 7 May 2016 10:47:35 -0400 To: quic@ietf.org From: Paul Kyzivat Message-ID: Date: Sat, 7 May 2016 10:47:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixO6iqMvOoBduMPOPqEXPAm4HRo8lS34y BTBGcdskJZaUBWem5+nbJXBn3Nx8haXgFEdF06rN7A2MH9m6GDk5JARMJBbNXwBkc3EICWxl lPj27Q0ThPODSeLO//2MIFUiAoISjbt6mEBsNgEtiTmH/rN0MXJwCAvYS+w6nwkS5gUyW79v AhvKIqAisbvnLTuILSqQIrHy011WiBpBiZMzn7CA2MwCZhLzNj9khrDlJZq3zmaewMgzC0nZ LCRls5CULWBkXsUol5hTmqubm5iZU5yarFucnJiXl1qka6yXm1mil5pSuokREjR8Oxjb18sc YhTgYFTi4T3hqRsuxJpYVlyZe4hRkoNJSZSXux8oxJeUn1KZkVicEV9UmpNafIhRgoNZSYSX /w9QjjclsbIqtSgfJiXNwaIkzqu2RN1PSCA9sSQ1OzW1ILUIJivDwaEkwXv5L1CjYFFqempF WmZOCUKaiYMTZDiXlEhxal5KalFiaUlGPCiS4ouBsQSS4gHay/4PZG9xQWIuUBSi9RSjopQ4 70mQuQIgiYzSPLixsFTwilEc6Eth3miQdh5gGoHrfgU0mAlo8Pu5miCDSxIRUlINjHZ/Jtin Cr9+wPDyiHLi4cdzCozmzTvTyXrw1bq3l5bp7/kidm/Hg/v77gV962Wf2PuhWdt0SYMTR+30 mxxszy/y/3pxYt+6SUt72G7cjmZ9Y/AirmLGnyUMbhfSqnUefn2i3mp+5UF8RXGG9trWuZUS K4RbBFj9mHRqp5nPUn73Y9PumyviuvYqsRRnJBpqMRcVJwIArbcDYeACAAA= Archived-At: Subject: [QUIC] Where does this effort stand wrt webrtc data channels? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 14:47:42 -0000 I just found the announcement of this list, and it raised more questions than answers. If this were a wg list then I could look at the charter to get an idea of what it is about, but it seems there is nothing. The announcement says: > QUIC is a UDP-based transport protocol that provides multiplexed > streams over an encrypted transport. While QUIC has been described > externally in the context of an HTTP-focused deployment, this mailing > list will discuss standardizing QUIC’s core transport protocol and > separately specify the mapping of the transport protocol to the > facilities of TLS. An additional work item of will be to describe how > to map specific application semantics onto the transport, starting with > the semantics of HTTP/2 ISTM the webrtc data channel mechanism, using SCTP over DTLS over UDP, satisfies the description of what this is looking for. I'm sure the organizers here are aware of that, so there must be some reason for discussing something that is presumably different. Can somebody explain the thinking here? Thanks, Paul From nobody Sat May 7 10:31:08 2016 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E9F12D0AD; Fri, 6 May 2016 13:50:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Secretariat To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160506205001.7493.44734.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2016 13:50:01 -0700 Archived-At: X-Mailman-Approved-At: Sat, 07 May 2016 10:31:07 -0700 Cc: ted.ietf@gmail.com, quic@ietf.org Subject: [QUIC] New Non-WG Mailing List: Quic -- Mailing list to discuss QUIC standardization X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 20:50:02 -0000 A new IETF non-working group email list has been created. List address: quic@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=quic To subscribe: https://www.ietf.org/mailman/listinfo/quic Purpose: QUIC is a UDP-based transport protocol that provides multiplexed streams over an encrypted transport. While QUIC has been described externally in the context of an HTTP-focused deployment, this mailing list will discuss standardizing QUIC’s core transport protocol and separately specify the mapping of the transport protocol to the facilities of TLS. An additional work item of will be to describe how to map specific application semantics onto the transport, starting with the semantics of HTTP/2 For additional information, please contact the list administrators. From nobody Sat May 7 18:24:30 2016 Return-Path: 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 5A58412D1D7 for ; Sat, 7 May 2016 18:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-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 0cpGKDqSbehM for ; Sat, 7 May 2016 18:24:26 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 04A8612D1DE for ; Sat, 7 May 2016 18:24:26 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id x19so177248893oix.2 for ; Sat, 07 May 2016 18:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F9DPEmqU9hQkE5La2y3rzouCnTP3GBdZsJkxAan2/3Q=; b=xohHxRXjBl6oX905woV6fWZZKShGfdS/H1Qu+st5D9J8YoqJWxkLhCoV0UsGaA9MBB UH4ppnn2Dguh+jQqDS0xK94IceHQ0Q3A8S/HLo+FtEgsdtBvQcaS/PCPcbTTiOB7wQ6j g4mJW++kngyUyV2T2H4dcBhdRsaaGF0gANhfzLfaeNXuPUHipS2iNjB8wbeH7LV/31bN o0CKzYj6iPmk2sx9cnYFik8cgsKAScT1rsfI7a5o9Zi9QchX2Qtg7Q36OLsc5IkQZ/QV ePFx9oBfxliYed28FbiyuME5gzBfaXOMa+fxD9kNYnR0kAPlLf4rOqqeDK7fT1xO/Ft0 K9IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F9DPEmqU9hQkE5La2y3rzouCnTP3GBdZsJkxAan2/3Q=; b=aiVgfEdwQtGOk/svFRhyA0ei9H0BROnAjyHIk3Lx0+4y85cDqodi/0pjNqSgskWkeF np/CnCMryU7vjyUCVqrjAm2FEKstyELeqeIiUBubkMqmo9y8Y3OoNhCElPYHNyQ60YLg wwP+Jap7EMIpO6NdhRM/AtQu+I+1YtAjVN0qf56O9VMdlunaoIruw+i+MXauPW3ZErFN GcofrJUDCUG+Dvst54gjmu1HhPI/9FYhoI97wOuwhVWk42F+xs4Ldu7DF6PK4FYv1nDn QevhQF61HeVNVAnL0vmuqXA7Klzetvade+hs9x8IqS6mvt9Um1nvBIFYjl+mShHYHxtE casg== X-Gm-Message-State: AOPr4FVe047UvvdXPOHrGE/37v3tNVan/hFyrxAcgAW3GwqmXsxWdfs9cnqrQc/k7sVZM7/9+sNuw2I9eHqx8A== X-Received: by 10.202.215.86 with SMTP id o83mr11662869oig.55.1462670665305; Sat, 07 May 2016 18:24:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.213.210 with HTTP; Sat, 7 May 2016 18:24:05 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Sat, 7 May 2016 18:24:05 -0700 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a113d3c306dd48d05324a8df9 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Where does this effort stand wrt webrtc data channels? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 01:24:28 -0000 --001a113d3c306dd48d05324a8df9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Paul, The BoF request is in TRAC now. The mailing list request went in first, so the BoF request could include the mailing list information. As a result, the mailng list got announced before the BoF request was posted; sorry for any confusion from the race condition. The URL, for your convenience, is: https://tools.ietf.org/bof/trac/ On Sat, May 7, 2016 at 7:47 AM, Paul Kyzivat wrote: > I just found the announcement of this list, and it raised more questions > than answers. If this were a wg list then I could look at the charter to > get an idea of what it is about, but it seems there is nothing. > > The announcement says: > > QUIC is a UDP-based transport protocol that provides multiplexed >> streams over an encrypted transport. While QUIC has been described >> externally in the context of an HTTP-focused deployment, this mailing >> list will discuss standardizing QUIC=E2=80=99s core transport protocol a= nd >> separately specify the mapping of the transport protocol to the >> facilities of TLS. An additional work item of will be to describe how >> to map specific application semantics onto the transport, starting with >> the semantics of HTTP/2 >> > > ISTM the webrtc data channel mechanism, using SCTP over DTLS over UDP, > satisfies the description of what this is looking for. > > I'm sure the organizers here are aware of that, so there must be some > reason for discussing something that is presumably different. > > QUIC is an existing protocol, see https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02 for a description. As you'll see from the BoF description, the proposal is to split the current omnibus description into multiple pieces, so that the core transport protocol can be used in systems that aren't based on HTTP/2 semantics. > Can somebody explain the thinking here? > > I hope that gave some context, regards, Ted > Thanks, > Paul > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a113d3c306dd48d05324a8df9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

The BoF request is in TRAC now.= =C2=A0 The mailing list request went in first, so the BoF request could inc= lude the mailing list information. As a result, the mailng list got announc= ed before the BoF request was posted; sorry for any confusion from the race= condition. The URL, for your convenience, is:

https://tools.ietf.org/bof/trac/

On Sat, May 7, 2016 at 7:47= AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
I just found the announcement= of this list, and it raised more questions than answers. If this were a wg= list then I could look at the charter to get an idea of what it is about, = but it seems there is nothing.

The announcement says:

QUIC is a UDP-based transport protocol that provides multiplexed
streams over an encrypted transport. While QUIC has been described
externally in the context of an HTTP-focused deployment, this mailing
list will discuss standardizing QUIC=E2=80=99s core transport protocol and<= br> separately specify the mapping of the transport protocol to the
facilities of TLS. An additional work item of will be to describe how
to map specific application semantics onto the transport, starting with
the semantics of HTTP/2

ISTM the webrtc data channel mechanism, using SCTP over DTLS over UDP, sati= sfies the description of what this is looking for.

I'm sure the organizers here are aware of that, so there must be some r= eason for discussing something that is presumably different.


QUIC is an existing protocol, see https://to= ols.ietf.org/html/draft-tsvwg-quic-protocol-02=C2=A0 for a description.= =C2=A0 As you'll see from the BoF description, the proposal is to split= the current omnibus description into multiple pieces, so that the core tra= nsport protocol can be used in systems that aren't based on HTTP/2 sema= ntics.
=C2=A0
Can somebody explain the thinking here?

I hope that gave some context,

rega= rds,

Ted
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--001a113d3c306dd48d05324a8df9-- From nobody Sun May 8 11:30:33 2016 Return-Path: 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 E3BF712B020 for ; Sun, 8 May 2016 11:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 29cixRiqqt2V for ; Sun, 8 May 2016 11:30:30 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B408128B44 for ; Sun, 8 May 2016 11:30:27 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by comcast with SMTP id zTT8aWegLbFYYzTTGaeCyZ; Sun, 08 May 2016 18:30:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1462732226; bh=yu5sqOIKbZP6/k9OOPOzqOq0GH/VcgaEfqz/tY3nKBY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=BJmclDmiTXW0TIWKUDxHa2ZFszDxGILRTR1uJllc7LyCqdCbDZzwo7MmsYcXoHmrP Liiz6BcQ+hdz8YqBNRtH5hwy2cdZaIGFD2s3Tr2YYlw0rqf9S1500de7QpehhicG9w puTjDdTb6dwgNOF+XiCubzJtAIn8bLZ4DAVU2nuv6Svo5hOtnanIC3je52Jl6Bw3Oo L4wFqfxEtbcPeUTgCz2ph9Hc4hj8nI0O5EBZQWEr4k4aTDXA6I0aHPpWNIFYhXg36N ibv0heBIgMom2BkrpaOeQMALmgJiNDSraJonHBCgn1rZMwaoMKcWflp7TmuasABlbJ MdEA0c4Gc4+Ng== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with comcast id ruWS1s0083KdFy101uWSnu; Sun, 08 May 2016 18:30:26 +0000 To: Ted Hardie References: From: Paul Kyzivat Message-ID: <8eac5e00-db94-86e7-3fd3-9ea238abd07a@alum.mit.edu> Date: Sun, 8 May 2016 14:30:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Where does this effort stand wrt webrtc data channels? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 18:30:32 -0000 Thanks Ted. I think I get it, that this is really starting on optimization of http(s), and so that dominates the engineering decisions. Any functional equivalence to data channels is entirely coincidental. Thanks, Paul On 5/7/16 9:24 PM, Ted Hardie wrote: > Hi Paul, > > The BoF request is in TRAC now. The mailing list request went in first, > so the BoF request could include the mailing list information. As a > result, the mailng list got announced before the BoF request was posted; > sorry for any confusion from the race condition. The URL, for your > convenience, is: > > https://tools.ietf.org/bof/trac/ > > On Sat, May 7, 2016 at 7:47 AM, Paul Kyzivat > wrote: > > I just found the announcement of this list, and it raised more > questions than answers. If this were a wg list then I could look at > the charter to get an idea of what it is about, but it seems there > is nothing. > > The announcement says: > > QUIC is a UDP-based transport protocol that provides multiplexed > streams over an encrypted transport. While QUIC has been described > externally in the context of an HTTP-focused deployment, this > mailing > list will discuss standardizing QUIC’s core transport protocol and > separately specify the mapping of the transport protocol to the > facilities of TLS. An additional work item of will be to > describe how > to map specific application semantics onto the transport, > starting with > the semantics of HTTP/2 > > > ISTM the webrtc data channel mechanism, using SCTP over DTLS over > UDP, satisfies the description of what this is looking for. > > I'm sure the organizers here are aware of that, so there must be > some reason for discussing something that is presumably different. > > > QUIC is an existing protocol, see > https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02 for a > description. As you'll see from the BoF description, the proposal is to > split the current omnibus description into multiple pieces, so that the > core transport protocol can be used in systems that aren't based on > HTTP/2 semantics. > > > Can somebody explain the thinking here? > > I hope that gave some context, > > regards, > > Ted > > > Thanks, > Paul > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > From nobody Thu May 12 18:54:38 2016 Return-Path: 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 CA00812B040 for ; Thu, 12 May 2016 18:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 3uJgIixIclTO for ; Thu, 12 May 2016 18:54:35 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 40F9612B009 for ; Thu, 12 May 2016 18:54:35 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id m64so80934763lfd.1 for ; Thu, 12 May 2016 18:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=w5xEsYgxZrJswtwOJCIel24vv4bCAt6ElNw81YARQ/E=; b=gGiDDtx2K96rD5nH15kJzAFoAwkkC9aPOWUBaj3Ma5t9QOcPgSPjPlkGiU66wtstjO yOUYpd9IKQdmcBUb5F9MmPeGT/t2/jCGmLLOtTd4BdwcILFWATDHD+ImgU0JOgJFAhUa EZiFm64Q2UiJDgXXSRoKwA2FqD1zLVggAAVPsNiST7nktC1tN3DUgdoo9yzmTa3Zxofw WTaPsoVI82EEUI1OWoq7VFodFqrnP3Ov8YMNJZ+SoDeMDJ2lpgUUi6TMzi/oqSGBkwkN YQVcE8d5r8v31v8HeGwiXyVxjLSWmter1XHrl17Wd+14WM8qrKIpfB2IXsqBYXISZo9E jHTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=w5xEsYgxZrJswtwOJCIel24vv4bCAt6ElNw81YARQ/E=; b=b47G7RpruU2LksVQ82Xc6E8NMtWQAwoJTtfS6kuUZXZXmqUEqVNOdf03/5fmeV1Vdt d6OoIRvUWAQDsru29ULWkhE2ennkao7+l/a0qtSkARuKo/73UAl6HZKVDCueEJVft929 lW/YNnQNgPBXyIjydAqxsPwJYOv/EH/jqcUloEF0HoLZ1m8hfI0XR2KYH3OnACdFI57s WLWxt2WQdYMS/gv5tmYrtG8msYvxCZv5NvQSnhe4/T3lHTO7k3BwwYm61Zs6+W+ADZLl okLHwYnw8lshO9QHuixqtrwiCmQvL6+yDF31lc3jhO7I0SNo8AGiDq/ongq5xikrObXG DWhg== X-Gm-Message-State: AOPr4FWIK20+JXBSzPgxRcdVw9hzWsiNFtbGE8fn2O28tP4UShALw3iMDtzs8hPYr3SM1R/WWvye7N/KfbdgiA== MIME-Version: 1.0 X-Received: by 10.25.163.211 with SMTP id m202mr4783296lfe.73.1463104473467; Thu, 12 May 2016 18:54:33 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.25.17.85 with HTTP; Thu, 12 May 2016 18:54:33 -0700 (PDT) In-Reply-To: <8eac5e00-db94-86e7-3fd3-9ea238abd07a@alum.mit.edu> References: <8eac5e00-db94-86e7-3fd3-9ea238abd07a@alum.mit.edu> Date: Thu, 12 May 2016 21:54:33 -0400 X-Google-Sender-Auth: 2y5xhuPvKa76HTcsgJkeGZ_ocww Message-ID: From: Erik Nygren To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a114116be69127a0532af8eb6 Archived-At: Cc: Ted Hardie , quic@ietf.org Subject: Re: [QUIC] Where does this effort stand wrt webrtc data channels? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 01:54:38 -0000 --001a114116be69127a0532af8eb6 Content-Type: text/plain; charset=UTF-8 On Sun, May 8, 2016 at 2:30 PM, Paul Kyzivat wrote: > I think I get it, that this is really starting on optimization of http(s), > and so that dominates the engineering decisions. Any functional equivalence > to data channels is entirely coincidental. > Mike Bishop's draft on Decomposing/Disentangling HTTP may provide some very helpful context: https://tools.ietf.org/html/draft-bishop-httpbis-decomposing-http-00 In particular, "HTTP" logically has multiple layers and HTTP/2 specifies a binding of HTTP semantics onto a new multiplexed framing layer. QUIC is a secure transport protocol with a multiplexed stream abstraction. One of its design trade-offs is to integrate the security mechanism (now QUIC_Crypto, hopefully TLS 1.3 in the future) in fairly tightly. For better or worse, the result is more integrated than SCTP-over-DTLS-over-UDP. The binding of HTTP onto it in the initial draft is not much different from (and heavily leverages) the HTTP/2 framing layer using one of the QUIC stream pairs for metadata/headers and additional QUIC stream pairs for request/response message bodies. There's a fairly clear separation. I think one of the interesting topics in standardization is what hooks make sense to add to QUIC to cover additional general-purpose use-cases. For example, having a lossy stream/frame type with no error recovery but still convered under the QUIC flow-control is a primitive that likely makes sense to add in but which is very much not HTTP-specific. Erik --001a114116be69127a0532af8eb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, May 8, 2016 at 2:30 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>= ; wrote:
I thin= k I get it, that this is really starting on optimization of http(s), and so= that dominates the engineering decisions. Any functional equivalence to da= ta channels is entirely coincidental.

Mike Bishop&= #39;s draft on Decomposing/Disentangling HTTP may provide some very helpful= context:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.or= g/html/draft-bishop-httpbis-decomposing-http-00
=C2=A0
In particular, "HTTP" logically has multiple layers and HTTP/2 s= pecifies a binding
of HTTP semantics onto a new multiplexed f= raming layer.

QUIC is a secure transport proto= col with a multiplexed stream abstraction.
One of its design = trade-offs is to integrate the security mechanism (now QUIC_Crypto,
hopefully TLS 1.3 in the future) in fairly tightly.=C2=A0 For better= or worse, the result
is more integrated than SCTP-over-DTLS-= over-UDP.

The binding of HTTP onto it in the initial draf= t is not much different from (and heavily leverages)
the HTTP= /2 framing layer using one of the QUIC stream pairs for metadata/headers
and additional QUIC stream pairs for request/response message b= odies.
There's a fairly clear separation.=C2=A0

<= /div>
I think one of the interesting topics in standardization is what = hooks make sense
to add to QUIC to cover additional general-p= urpose use-cases.
For example, having a lossy stream/frame ty= pe with no error recovery
but still convered under the QUIC = flow-control is a primitive that
likely makes sense to add in= but which is very much not HTTP-specific.

=C2=A0 Erik


--001a114116be69127a0532af8eb6-- From nobody Fri May 13 16:34:47 2016 Return-Path: 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 07A0C12D1B3 for ; Fri, 13 May 2016 16:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=unavailable 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 QE2ScPDaceLf for ; Fri, 13 May 2016 16:34:44 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 2B93C12D1D1 for ; Fri, 13 May 2016 16:26:59 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id x201so194073730oif.3 for ; Fri, 13 May 2016 16:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=CGhOKR2qyEPffj4RSCQli25oGoeYRa/5AhOuFti72bg=; b=l6N62HSZhzm5MhDTvfAufS1u4fzIjy/651g26DwivD35ok8Xx09Gzp8HKhz8D2OXAI NKszIFdK9dARshlhkrdQbs8s5FIQV7VHNYzF8e0LHME1gCKeKfHtJWeINsdL/tcf6bqe Cv8WZNXwTBkWnrTeL69kRT6Sm7Z6pQkDKuWJTuSlHs1ob3+tH8ww511QEWLApAGp372T hdHtHKTBL7HOvD54Ca4EcuNBeY1DGP4hryqzUcvZ1NY9GM8lNjazBEaRPNdmfP7SzyiH Hr+WKaTAp28vZwDkUMcysu7xNnvkJwTNCghomuk/1ifgZmz1eQ8oBf6CgDVYBv40Ibv3 T8Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CGhOKR2qyEPffj4RSCQli25oGoeYRa/5AhOuFti72bg=; b=P+7srWt8ND13JHTBs+6bpC4NyWOM3hTulJPmkHnIh5NVBr0Wjv4d7pf89NFMotuo+g gEFV7Pk5psd1wtCNAx/sRqZ7gutVOnfrMeEgMXsoE5oXKwxSrKrL0SRHG8S0OU76Q7F5 0wzoQF0O4/HQbT3NcchrMfOTtTCpQlLI6C7b/gTSfXTloxndP6gjDn5lNByQMnPOpz5V 7Ij1BwjoJM2qb5vylYVujF3dTh5bR7QccGZdzXn9MF7t1LnQ1S68IeDrKnc6j1ULOPE0 WG7HlSkPSVeudoUMc+cP8aYJsPaCVFJjX7MVS6WQdhrfoRdks6erkWs6+oQaO3i8JzNL dDJQ== X-Gm-Message-State: AOPr4FW+xt1IH63LYHX8Oxw8SeGIDHbgFwDFjc+5ilEN30Qk5KeAlkWAeNes5HCwRvPOAEnduvD1yps73PRcTA== X-Received: by 10.157.61.197 with SMTP id l63mr11063667otc.48.1463182018549; Fri, 13 May 2016 16:26:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.213.210 with HTTP; Fri, 13 May 2016 16:26:39 -0700 (PDT) From: Ted Hardie Date: Fri, 13 May 2016 16:26:39 -0700 Message-ID: To: quic@ietf.org, Jana Iyengar , Christian Huitema Content-Type: multipart/mixed; boundary=001a1149299c7538a60532c19c97 Archived-At: Subject: [QUIC] Draft charter X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 23:34:46 -0000 --001a1149299c7538a60532c19c97 Content-Type: multipart/alternative; boundary=001a1149299c7538a00532c19c95 --001a1149299c7538a00532c19c95 Content-Type: text/plain; charset=UTF-8 Howdy, As part of the BoF preparation, we put together a stab at a draft charter. It's available as html and markdown on github at: https://github.com/IETF-QUIC/Charter I've attached the HTML version as well. It would be great to have some of the discussion on the list before the BoF. Comments to the list or issues/pull requests at the github repo are welcome. We will periodically reflect any issues or suggestion from the Repo back to the list, but this will be manual, so expect some lag. regards, Ted --001a1149299c7538a00532c19c95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

As part of the BoF= preparation, we put together a stab at a draft charter.=C2=A0 It's ava= ilable as html and markdown on github at:

https://github.com/IETF-QUIC/Charter

I've attached the HTML version as well.=C2=A0

It w= ould be great to have some of the discussion on the list before the BoF.=C2= =A0 Comments to the list or issues/pull requests at the github repo are=20 welcome.=C2=A0 We will periodically reflect any issues or suggestion from t= he Repo back to the list, but this will be manual, so expect some lag.
<= div>
regards,

Ted
--001a1149299c7538a00532c19c95-- --001a1149299c7538a60532c19c97 Content-Type: text/html; charset=US-ASCII; name="quic-charter.html" Content-Disposition: attachment; filename="quic-charter.html" Content-Transfer-Encoding: base64 X-Attachment-Id: f_io6coola0 PGh0bWw+PGhlYWQ+PG1ldGEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04IiBodHRw LWVxdWl2PSJjb250ZW50LXR5cGUiPjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+b2x7bWFyZ2luOjA7 cGFkZGluZzowfXRhYmxlIHRkLHRhYmxlIHRoe3BhZGRpbmc6MH0uYzV7YmFja2dyb3VuZC1jb2xv cjojZmZmZmZmO21heC13aWR0aDo0NjhwdDtwYWRkaW5nOjcycHQgNzJwdCA3MnB0IDcycHR9LmMw e2JhY2tncm91bmQtY29sb3I6I2ZmZmZmZjtjb2xvcjojMjIyMjIyfS5jMXtvcnBoYW5zOjI7d2lk b3dzOjJ9LmMze2ZvbnQtc2l6ZToxN3B0O2ZvbnQtd2VpZ2h0OmJvbGR9LmM0e3BhZGRpbmctYm90 dG9tOjRwdH0uYzJ7aGVpZ2h0OjExcHR9LnRpdGxle3BhZGRpbmctdG9wOjBwdDtjb2xvcjojMDAw MDAwO2ZvbnQtc2l6ZToyNnB0O3BhZGRpbmctYm90dG9tOjNwdDtmb250LWZhbWlseToiQXJpYWwi O2xpbmUtaGVpZ2h0OjEuMTU7cGFnZS1icmVhay1hZnRlcjphdm9pZDtvcnBoYW5zOjI7d2lkb3dz OjI7dGV4dC1hbGlnbjpsZWZ0fS5zdWJ0aXRsZXtwYWRkaW5nLXRvcDowcHQ7Y29sb3I6IzY2NjY2 Njtmb250LXNpemU6MTVwdDtwYWRkaW5nLWJvdHRvbToxNnB0O2ZvbnQtZmFtaWx5OiJBcmlhbCI7 bGluZS1oZWlnaHQ6MS4xNTtwYWdlLWJyZWFrLWFmdGVyOmF2b2lkO29ycGhhbnM6Mjt3aWRvd3M6 Mjt0ZXh0LWFsaWduOmxlZnR9bGl7Y29sb3I6IzAwMDAwMDtmb250LXNpemU6MTFwdDtmb250LWZh bWlseToiQXJpYWwifXB7bWFyZ2luOjA7Y29sb3I6IzAwMDAwMDtmb250LXNpemU6MTFwdDtmb250 LWZhbWlseToiQXJpYWwifWgxe3BhZGRpbmctdG9wOjIwcHQ7Y29sb3I6IzAwMDAwMDtmb250LXNp emU6MjBwdDtwYWRkaW5nLWJvdHRvbTo2cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIjtsaW5lLWhlaWdo dDoxLjE1O3BhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7b3JwaGFuczoyO3dpZG93czoyO3RleHQtYWxp Z246bGVmdH1oMntwYWRkaW5nLXRvcDoxOHB0O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE2cHQ7 cGFkZGluZy1ib3R0b206NnB0O2ZvbnQtZmFtaWx5OiJBcmlhbCI7bGluZS1oZWlnaHQ6MS4xNTtw YWdlLWJyZWFrLWFmdGVyOmF2b2lkO29ycGhhbnM6Mjt3aWRvd3M6Mjt0ZXh0LWFsaWduOmxlZnR9 aDN7cGFkZGluZy10b3A6MTZwdDtjb2xvcjojNDM0MzQzO2ZvbnQtc2l6ZToxNHB0O3BhZGRpbmct Ym90dG9tOjRwdDtmb250LWZhbWlseToiQXJpYWwiO2xpbmUtaGVpZ2h0OjEuMTU7cGFnZS1icmVh ay1hZnRlcjphdm9pZDtvcnBoYW5zOjI7d2lkb3dzOjI7dGV4dC1hbGlnbjpsZWZ0fWg0e3BhZGRp bmctdG9wOjE0cHQ7Y29sb3I6IzY2NjY2Njtmb250LXNpemU6MTJwdDtwYWRkaW5nLWJvdHRvbTo0 cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIjtsaW5lLWhlaWdodDoxLjE1O3BhZ2UtYnJlYWstYWZ0ZXI6 YXZvaWQ7b3JwaGFuczoyO3dpZG93czoyO3RleHQtYWxpZ246bGVmdH1oNXtwYWRkaW5nLXRvcDox MnB0O2NvbG9yOiM2NjY2NjY7Zm9udC1zaXplOjExcHQ7cGFkZGluZy1ib3R0b206NHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCI7bGluZS1oZWlnaHQ6MS4xNTtwYWdlLWJyZWFrLWFmdGVyOmF2b2lkO29y cGhhbnM6Mjt3aWRvd3M6Mjt0ZXh0LWFsaWduOmxlZnR9aDZ7cGFkZGluZy10b3A6MTJwdDtjb2xv cjojNjY2NjY2O2ZvbnQtc2l6ZToxMXB0O3BhZGRpbmctYm90dG9tOjRwdDtmb250LWZhbWlseToi QXJpYWwiO2xpbmUtaGVpZ2h0OjEuMTU7cGFnZS1icmVhay1hZnRlcjphdm9pZDtmb250LXN0eWxl Oml0YWxpYztvcnBoYW5zOjI7d2lkb3dzOjI7dGV4dC1hbGlnbjpsZWZ0fTwvc3R5bGU+PC9oZWFk Pjxib2R5IGNsYXNzPSJjNSI+PHAgY2xhc3M9ImMxIGM0Ij48c3Bhbj5OYW1lICZuYnNwOzwvc3Bh bj48c3Bhbj5RdWljayBVRFAtYmFzZWQgSW50ZXJuZXQgQ29ubmVjdGlvbjwvc3Bhbj48c3Bhbj4m bmJzcDsoUVVJQyk8L3NwYW4+PC9wPjxwIGNsYXNzPSJjMSI+PHNwYW4+QWNyb255bSAmbmJzcDtR VUlDPC9zcGFuPjwvcD48cCBjbGFzcz0iYzEiPjxzcGFuPkFyZWEgVFNWPC9zcGFuPjwvcD48cCBj bGFzcz0iYzEiPjxzcGFuPlBlcnNvbm5lbDwvc3Bhbj48L3A+PHAgY2xhc3M9ImMxIj48c3Bhbj4m bmJzcDsgJm5ic3A7Q2hhaXJzICZuYnNwO1RCRDwvc3Bhbj48L3A+PHAgY2xhc3M9ImMxIj48c3Bh bj4mbmJzcDsgJm5ic3A7QXJlYSBEaXJlY3RvcjogU3BlbmNlciBEYXdraW5zPC9zcGFuPjwvcD48 cCBjbGFzcz0iYzEiPjxzcGFuPiZuYnNwOyAmbmJzcDtTZWN1cml0eSBBcmVhIEFkdmlzb3I6IFRC RDwvc3Bhbj48L3A+PGgyIGNsYXNzPSJjMSBjNCIgaWQ9ImgubjU1Y2pzdDNkbHFhIj48c3BhbiBj bGFzcz0iYzMiPkNoYXJ0ZXIgZm9yIFdvcmtpbmcgR3JvdXA8L3NwYW4+PC9oMj48cCBjbGFzcz0i YzEiPjxzcGFuPlRoZXJlIGlzIGVtZXJnaW5nIGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3ltZW50 IDwvc3Bhbj48c3Bhbj5leHBlcmllbmNlIHdpdGg8L3NwYW4+PHNwYW4+Jm5ic3A7UVVJQywgYSBV RFAtYmFzZWQgcHJvdG9jb2wgdGhhdCBwcm92aWRlcyBhIHN0cmVhbS1tdWx0aXBsZXhpbmcgZW5j cnlwdGVkIHRyYW5zcG9ydC4gQmFzZWQgb24gdGhhdCBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95 bWVudCBleHBlcmllbmNlLCB0PC9zcGFuPjxzcGFuPmhlIFFVSUMgd29ya2luZyBncm91cCB3aWxs IHByb3ZpZGUgYSBzdGFuZGFyZHMgdHJhY2sgc3BlY2lmaWNhdGlvbiBnZW5lcmFsaXppbmcgdGhl IGRlc2lnbiBkZXNjcmliZWQgaW4gdGhlIGluaXRpYWwgc2V0IG9mIGRyYWZ0LXRzdndnLXF1aWMt cHJvdG9jb2w8L3NwYW4+PHNwYW4gY2xhc3M9ImMwIj4sIGRyYWZ0LXRzdndnLXF1aWMtbG9zcy1y ZWNvdmVyeSwgPC9zcGFuPjxzcGFuPmFuZCByZWxhdGVkIGRvY3VtZW50cy4gPC9zcGFuPjxzcGFu PktleSBnb2FscyBmb3IgUVVJQzwvc3Bhbj48c3Bhbj4mbmJzcDthcmU6IG1pbmltaXppbmcgY29u bmVjdGlvbiBlc3RhYmxpc2htZW50IGFuZCBvdmVyYWxsIHRyYW5zcG9ydCBsYXRlbmN5IGZvciBh cHBsaWNhdGlvbnM8L3NwYW4+PHNwYW4+LCBzdGFydGluZyB3aXRoIEhUVFAvMjwvc3Bhbj48c3Bh bj47IHByb3ZpZGluZyBtdWx0aXBsZXhpbmcgd2l0aG91dCBoZWFkLW9mLWxpbmUgYmxvY2tpbmc7 IGVuYWJsaW5nIGRlcGxveW1lbnQgb3ZlciB1bm1vZGlmaWVkIEludGVybmV0IHBhdGhzOyBhbmQg ZW5hYmxpbmcgbXVsdGlwYXRoIGFuZCA8L3NwYW4+PHNwYW4+Zm9yd2FyZCBlcnJvciBjb3JyZWN0 aW9uPC9zcGFuPjxzcGFuPiZuYnNwO2V4dGVuc2lvbnMuPC9zcGFuPjwvcD48cCBjbGFzcz0iYzEg YzIiPjxzcGFuPjwvc3Bhbj48L3A+PHAgY2xhc3M9ImMxIj48c3Bhbj5UaGUgd29yayBvZiB0aGUg Z3JvdXAgd2lsbCBoYXZlIGZvdXIgbWFpbiBmb2N1cyBhcmVhcywgY29ycmVzcG9uZGluZyB0byBm b3VyIGNvcmUgZGVsaXZlcmFibGVzLiBUaGUgZmlyc3Qgb2YgdGhlc2UgaXMgdGhlIGNvcmUgdHJh bnNwb3J0IHdvcmssIHdoaWNoIHdpbGwgZGVzY3JpYmUgdGhlIHdpcmUgZm9ybWF0LCBhbG9uZyB3 aXRoIHRoZSBtZWNoYW5pc21zIGY8L3NwYW4+PHNwYW4+b3I8L3NwYW4+PHNwYW4+Jm5ic3A7Y29u bmVjdGlvbiBlc3RhYmxpc2htZW50LCBzdHJlYW0gbXVsdGlwbGV4aW5nLCBkYXRhIHJlbGlhYmls aXR5LCBsb3NzIGRldGVjdGlvbiBhbmQgcmVjb3ZlcnksIGNvbmdlc3Rpb24gY29udHJvbCwgYW5k PC9zcGFuPjxzcGFuPiZuYnNwO25lZ290aWF0aW9uPC9zcGFuPjxzcGFuPi4gPC9zcGFuPjxzcGFu PlFVSUMgaXMgZXhwZWN0ZWQgdG8gc3VwcG9ydCByYXBpZCBpdGVyYWJpbGl0eSBhbmQgZXhwZXJp bWVudGF0aW9uLCBhbmQgdDwvc3Bhbj48c3Bhbj5oaXMgd29yayB3aWxsIGFsc28gZGVzY3JpYmUg YSB2ZXJzaW9uaW5nIHByb2Nlc3MgdGhhdCBlbmFibGVzIGRpc3RyaWJ1dGVkIGV4cGVyaW1lbnRh dGlvbiB3aXRoIFFVSUMuPC9zcGFuPjwvcD48cCBjbGFzcz0iYzEgYzIiPjxzcGFuPjwvc3Bhbj48 L3A+PHAgY2xhc3M9ImMxIj48c3Bhbj5UaGUgc2Vjb25kIG9mIHRoZXNlIGZvY3VzIGFyZWFzIGlz IHNlY3VyaXR5LiBUaGlzIHdvcmsgd2lsbCBkZXNjcmliZSBob3cgdGhlIHByb3RvY29sIHVzZXMg dGhlIGZhY2lsaXRpZXMgb2YgVExTIDEuMyBmb3Iga2V5IG5lZ290aWF0aW9uIGFuZCB3aWxsIGFs c28gZGVzY3JpYmUgaG93IHRob3NlIGtleXMgYXJlIHVzZWQgdG8gcHJvdmlkZSBjb25maWRlbnRp YWxpdHkgYW5kIGludGVncml0eSBwcm90ZWN0aW9uLiA8L3NwYW4+PHNwYW4+SXQgd2lsbCBhbHNv IHByb3ZpZGUgYSB0aHJlYXQgbW9kZWwgZGVzY3JpcHRpb24gc3BlY2lmaWMgdG8gPC9zcGFuPjxz cGFuPmNvbm5lY3Rpb24gcmU8L3NwYW4+PHNwYW4+c3VtcHRpb248L3NwYW4+PHNwYW4+LCBhbG9u ZyB3aXRoIGEgZGVzY3JpcHRpb24gZm9yIGRlbmlhbC1vZi1zZXJ2aWNlIG1pdGlnYXRpb25zLjwv c3Bhbj48L3A+PHAgY2xhc3M9ImMxIGMyIj48c3Bhbj48L3NwYW4+PC9wPjxwIGNsYXNzPSJjMSI+ PHNwYW4+VGhlIHRoaXJkIGZvY3VzIGFyZWEgd2lsbCBkZXNjcmliZSBtYXBwaW5ncyBiZXR3ZWVu IHNwZWNpZmljIGFwcGxpY2F0aW9ucyZyc3F1bzsgc2VtYW50aWNzIGFuZCB0aGUgdHJhbnNwb3J0 IGZhY2lsaXRpZXMgb2YgUVVJQy4gVGhlIGZpcnN0IG1hcHBpbmcgd2lsbCBiZSBhIGRlc2NyaXB0 aW9uIG9mIEhUVFAvMiBzZW1hbnRpY3MgdXNpbmcgUVVJQywgc3BlY2lmaWNhbGx5IHdpdGggdGhl IGdvYWwgb2YgbWluaW1pemluZyB3ZWIgbGF0ZW5jeSB1c2luZyBRVUlDLiBVcG9uIGNvbXBsZXRp b24gb2YgdGhhdCBtYXBwaW5nLCBhZGRpdGlvbmFsIHByb3RvY29scyBtYXkgYmUgYWRkZWQgYnkg dXBkYXRpbmcgdGhpcyBjaGFydGVyIHRvIGluY2x1ZGUgdGhlbS48L3NwYW4+PC9wPjxwIGNsYXNz PSJjMSBjMiI+PHNwYW4+PC9zcGFuPjwvcD48cCBjbGFzcz0iYzEiPjxzcGFuPlRoZSBmb3VydGgg Zm9jdXMgYXJlYSB3aWxsIGV4dGVuZCBjb3JlIHByb3RvY29sIGZhY2lsaXRpZXMgdG8gZW5hYmxl IDwvc3Bhbj48c3Bhbj5tdWx0aXBhdGggYW5kIGZvcndhcmQgZXJyb3IgY29ycmVjdGlvbjwvc3Bh bj48c3Bhbj4mbmJzcDsoRkVDKS4gJm5ic3A7VGhlc2UgZXh0ZW5zaW9ucyB3aWxsIGJlIHNlcGFy YXRlIGZyb20gdGhlIGNvcmUgcHJvdG9jb2wgYW5kIHdpbGwgYmUgZGVzY3JpYmVkIGluIHNlcGFy YXRlIGRvY3VtZW50cy4gSW1wb3J0YW50bHksIHRoZSBGRUMgZXh0ZW5zaW9uIHdpbGwgZGVzY3Jp YmUgUVVJQyBwcm90b2NvbCBtZWNoYW5pc21zIHJlcXVpcmVkIHRvIGVuYWJsZSBuZWdvdGlhdGlv biBhbmQgdXNlIG9mIEZFQyBzY2hlbWVzOyBzcGVjaWZpYyBGRUMgc2NoZW1lIGRlZmluaXRpb25z IGFyZSBvdXQgb2Ygc2NvcGUuPC9zcGFuPjwvcD48cCBjbGFzcz0iYzEgYzIiPjxzcGFuPjwvc3Bh bj48L3A+PHAgY2xhc3M9ImMxIj48c3BhbiBjbGFzcz0iYzAiPk5vdGUgdGhhdCBjb25zZW5zdXMg aXMgcmVxdWlyZWQgYm90aCBmb3IgY2hhbmdlcyB0byB0aGUgY3VycmVudCBwcm90b2NvbCBtZWNo YW5pc21zIGFuZCByZXRlbnRpb24gb2YgY3VycmVudCBtZWNoYW5pc21zPC9zcGFuPjxzcGFuPi4g SW4gcGFydGljdWxhciwgYmVjYXVzZSBzb21ldGhpbmcgaXMgaW4gdGhlIGluaXRpYWwgZG9jdW1l bnQgc2V0IGRvZXMgbm90IGltcGx5IHRoYXQgdGhlcmUgaXMgY29uc2Vuc3VzIGFyb3VuZCB0aGUg ZmVhdHVyZSBvciBhcm91bmQgaG93IGl0IGlzIHNwZWNpZmllZC48L3NwYW4+PC9wPjxwIGNsYXNz PSJjMSBjMiI+PHNwYW4+PC9zcGFuPjwvcD48cCBjbGFzcz0iYzEiPjxzcGFuPk1pbGVzdG9uZXM8 L3NwYW4+PC9wPjxwIGNsYXNzPSJjMSBjMiI+PHNwYW4+PC9zcGFuPjwvcD48cCBjbGFzcz0iYzEi PjxzcGFuPldvcmtpbmcgZ3JvdXAgYWRvcHRpb24gb2YgQ29yZSBQcm90b2NvbCBkb2N1bWVudDxi cj5Xb3JraW5nIGdyb3VwIGFkb3B0aW9uIG9mIExvc3MgZGV0ZWN0aW9uIGFuZCBDb25nZXN0aW9u IENvbnRyb2wgZG9jdW1lbnQ8L3NwYW4+PC9wPjxwIGNsYXNzPSJjMSI+PHNwYW4+V29ya2luZyBn cm91cCBhZG9wdGlvbiBvZiBUTFMgMS4zIG1hcHBpbmcgZG9jdW1lbnQ8L3NwYW4+PC9wPjxwIGNs YXNzPSJjMSI+PHNwYW4+V29ya2luZyBncm91cCBhZG9wdGlvbiBvZiBIVFRQLzIgbWFwcGluZyBk b2N1bWVudDwvc3Bhbj48L3A+PHAgY2xhc3M9ImMxIj48c3Bhbj5Xb3JraW5nIGdyb3VwIGFkb3B0 aW9uIG9mIE11bHRpcGF0aCBleHRlbnNpb24gZG9jdW1lbnQ8L3NwYW4+PC9wPjxwIGNsYXNzPSJj MSI+PHNwYW4+V29ya2luZyBncm91cCBhZG9wdGlvbiBvZiBGRUMgZXh0ZW5zaW9uIGRvY3VtZW50 PC9zcGFuPjwvcD48cCBjbGFzcz0iYzEiPjxzcGFuPkNvcmUgUHJvdG9jb2wgZG9jdW1lbnQgdG8g SUVTRzwvc3Bhbj48L3A+PHAgY2xhc3M9ImMxIj48c3Bhbj5Mb3NzIGRldGVjdGlvbiBhbmQgQ29u Z2VzdGlvbiBDb250cm9sIGRvY3VtZW50IHRvIElFU0c8L3NwYW4+PC9wPjxwIGNsYXNzPSJjMSI+ PHNwYW4+VExTIDEuMyBNYXBwaW5nIGRvY3VtZW50IHRvIElFU0c8L3NwYW4+PC9wPjxwIGNsYXNz PSJjMSI+PHNwYW4+SFRUUC8yIG1hcHBpbmcgZG9jdW1lbnQgdG8gSUVTRzwvc3Bhbj48L3A+PHAg Y2xhc3M9ImMxIj48c3Bhbj5NdWx0aXBhdGggZXh0ZW5zaW9uIGRvY3VtZW50IHRvIElFU0c8L3Nw YW4+PC9wPjxwIGNsYXNzPSJjMSI+PHNwYW4+RkVDIGV4dGVuc2lvbiBkb2N1bWVudCB0byBJRVNH PC9zcGFuPjwvcD48cCBjbGFzcz0iYzEgYzIiPjxzcGFuPjwvc3Bhbj48L3A+PC9ib2R5PjwvaHRt bD4= --001a1149299c7538a60532c19c97-- From nobody Fri May 13 16:55:51 2016 Return-Path: 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 B81A412D6BC for ; Fri, 13 May 2016 16:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1YEzb_MzZmZD for ; Fri, 13 May 2016 16:55:48 -0700 (PDT) Received: from uk-www1.yaanatech.uk (uk-www1.yaanatech.uk [46.20.116.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D605E12D61D for ; Fri, 13 May 2016 16:55:46 -0700 (PDT) Received: from [192.168.1.51] (pool-173-67-205-17.clppva.fios.verizon.net [173.67.205.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by uk-www1.yaanatech.uk (Postfix) with ESMTPSA id 63A70540232; Sat, 14 May 2016 00:55:44 +0100 (BST) References: To: Ted Hardie , quic@ietf.org, Jana Iyengar , Christian Huitema From: Tony Rutkowski Organization: Yaana Ltd Message-ID: <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk> Date: Fri, 13 May 2016 19:55:43 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D313FC7DDC2A79AB81AD47E1" Archived-At: Subject: Re: [QUIC] Draft charter X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tony@yaanatech.co.uk List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 23:55:50 -0000 This is a multi-part message in MIME format. --------------D313FC7DDC2A79AB81AD47E1 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit How do you intend to provide for lawful interception that will allow it to be used? --tony On 2016-05-13 7:26 PM, Ted Hardie wrote: > Howdy, > > As part of the BoF preparation, we put together a stab at a draft > charter. It's available as html and markdown on github at: > > https://github.com/IETF-QUIC/Charter > > I've attached the HTML version as well. > > It would be great to have some of the discussion on the list before > the BoF. Comments to the list or issues/pull requests at the github > repo are welcome. We will periodically reflect any issues or > suggestion from the Repo back to the list, but this will be manual, so > expect some lag. > > regards, > > Ted > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --------------D313FC7DDC2A79AB81AD47E1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit How do you intend to provide for lawful
interception that will allow it to be used?
--tony

On 2016-05-13 7:26 PM, Ted Hardie wrote:
Howdy,

As part of the BoF preparation, we put together a stab at a draft charter. It's available as html and markdown on github at:

https://github.com/IETF-QUIC/Charter

I've attached the HTML version as well.

It would be great to have some of the discussion on the list before the BoF. Comments to the list or issues/pull requests at the github repo are welcome. We will periodically reflect any issues or suggestion from the Repo back to the list, but this will be manual, so expect some lag.

regards,

Ted


_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--------------D313FC7DDC2A79AB81AD47E1-- From nobody Fri May 13 17:28:07 2016 Return-Path: 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 B4E7512D6C6 for ; Fri, 13 May 2016 17:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 qsVO5F7vekBd for ; Fri, 13 May 2016 17:28:04 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 0999112D1A7 for ; Fri, 13 May 2016 17:28:04 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id x19so195149598oix.2 for ; Fri, 13 May 2016 17:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=CRnDwHdk2yvIFUDLQAWTi0fj5q0lbFi9YnpnEzco7/U=; b=Aco5b/fiCsi9idk3CFWhtuDGCkmYcDgiCTmk7mAiLImNoj0Jgl4+BHhCDl35iO1KUJ 4dwTU1PvKu9Hnoh8VUm/Kyoc7XpZs3cl3T/6iqBj1jOtu67wQJg7UJ+x94A+MTKbC1is sQYJWcDhA159qlKNd7fyXLm45r6ULcJ6/QDIL++TLE6kd5Ohvou+wdE8ORyl8Aorznr9 +XKbkzE9/xkV8BFE4Pq46UnNKhp9seMcVk4+2S8gKtAyTmiXexF2GmQa/jnSaweFy2NT pxpiRrzhVvrPNTzx3l8U4sNO2DMpGRkyzP2pHgp0O+V8GZE6l0UEXc2BO5JAMmJ1RPYz j1cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=CRnDwHdk2yvIFUDLQAWTi0fj5q0lbFi9YnpnEzco7/U=; b=DG00OjTxxsbuUCq5yR91W/QVcIzEkV7zypoGxdGrNeDxXFKcG+d0LtpHZkcYltodhH Yp5ZsFr+yXj2EJc6z1iYbFSkI9P7wl5U5+AGeOevuORiCSOaIbVM4f764dV7KnBzEndX r0qaToNNnsjKBY72gKbFVMRH9qu4xdT9GC2PwS1dDOfSSMRL5PdzkYTcrYPOmu8cnilP /SjT39IazUSCbIqA4nyBvKjrYLHBuvKQ8qvcd3K3I29xIecDE2IP184VysmW5QePjOwQ kIAQYPkDFSQB4CjNy9tdIbWWtFhfQRjCrIciRCISUPoP5QOg0Yh5PtubdO4FpqUGOJQV 2J3g== X-Gm-Message-State: AOPr4FWQGgnxBj98GU34ctp6cj0Ehd62Ph/dvC2wHk5FL2u13+xDz1rI6IGLSiF+a4dHwIvxbJ1R9dPsKinMhw== MIME-Version: 1.0 X-Received: by 10.202.240.68 with SMTP id o65mr10596085oih.0.1463185683406; Fri, 13 May 2016 17:28:03 -0700 (PDT) Received: by 10.202.213.210 with HTTP; Fri, 13 May 2016 17:28:02 -0700 (PDT) Received: by 10.202.213.210 with HTTP; Fri, 13 May 2016 17:28:02 -0700 (PDT) In-Reply-To: <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk> References: <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk> Date: Fri, 13 May 2016 17:28:02 -0700 Message-ID: From: Ted Hardie To: tony@yaanatech.co.uk Content-Type: multipart/alternative; boundary=94eb2c08fa66e667140532c2768a Archived-At: Cc: Jana Iyengar , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Draft charter X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 00:28:06 -0000 --94eb2c08fa66e667140532c2768a Content-Type: text/plain; charset=UTF-8 On May 13, 2016 16:55, "Tony Rutkowski" wrote: > > How do you intend to provide for lawful > interception that will allow it to be used? > --tony > Hi Tony, Please review RFC 2804. The issue you raise is not a consideration in this context. Regards, Ted Mobile, terse. > > On 2016-05-13 7:26 PM, Ted Hardie wrote: >> >> Howdy, >> >> As part of the BoF preparation, we put together a stab at a draft charter. It's available as html and markdown on github at: >> >> https://github.com/IETF-QUIC/Charter >> >> I've attached the HTML version as well. >> >> It would be great to have some of the discussion on the list before the BoF. Comments to the list or issues/pull requests at the github repo are welcome. We will periodically reflect any issues or suggestion from the Repo back to the list, but this will be manual, so expect some lag. >> >> regards, >> >> Ted >> >> >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic > > --94eb2c08fa66e667140532c2768a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On May 13, 2016 16:55, "Tony Rutkowski" <tony@yaanatech.co.uk> wrote:
>
> How do you intend to provide for lawful
> interception that will allow it to be used?
> --tony
>

Hi Tony,

Please review RFC 2804. The issue you raise is not a conside= ration in this context.

Regards,

Ted

Mobile, terse.
>
> On 2016-05-13 7:26 PM, Ted Hardie wrote:
>>
>> Howdy,
>>
>> As part of the BoF preparation, we put together a stab at a draft = charter.=C2=A0 It's available as html and markdown on github at:
>>
>> https://github.co= m/IETF-QUIC/Charter
>>
>> I've attached the HTML version as well.=C2=A0
>>
>> It would be great to have some of the discussion on the list befor= e the BoF.=C2=A0 Comments to the list or issues/pull requests at the github= repo are welcome.=C2=A0 We will periodically reflect any issues or suggest= ion from the Repo back to the list, but this will be manual, so expect some= lag.
>>
>> regards,
>>
>> Ted
>>
>>
>> _______________________________________________
>> QUIC mailing list
>> QUIC@ietf.org
>> https://www= .ietf.org/mailman/listinfo/quic
>
>

--94eb2c08fa66e667140532c2768a-- From nobody Fri May 13 17:34:23 2016 Return-Path: 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 8B1BC12D6C4 for ; Fri, 13 May 2016 17:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hPbSGJ4OuWFa for ; Fri, 13 May 2016 17:34:17 -0700 (PDT) Received: from uk-www1.yaanatech.uk (uk-www1.yaanatech.uk [46.20.116.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B4E12D098 for ; Fri, 13 May 2016 17:34:17 -0700 (PDT) Received: from [192.168.1.51] (pool-173-67-205-17.clppva.fios.verizon.net [173.67.205.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by uk-www1.yaanatech.uk (Postfix) with ESMTPSA id E9C325402C7; Sat, 14 May 2016 01:34:15 +0100 (BST) References: <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk> To: Ted Hardie From: Tony Rutkowski Organization: Yaana Ltd Message-ID: <364acd38-cea7-c242-5cb7-9f427c4f008e@yaanatech.co.uk> Date: Fri, 13 May 2016 20:34:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------74022BB42116C19BDE62230E" Archived-At: Cc: Jana Iyengar , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Draft charter X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tony@yaanatech.co.uk List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 00:34:19 -0000 This is a multi-part message in MIME format. --------------74022BB42116C19BDE62230E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ted, RFC2804 is familiar, but pronouncements do not solve real world requirements. There are many reasons today why providers require lawful interception capabilities - which is far broader than "wiretapping." Managing traffic, cybersecurity, and an array of compliance obligations worldwide necessitate a means under the appropriate circumstances to acquire a variety of circumscribed, controlled access to observables on the wire. This can't just be blown away by a political RFC reference. --tony On 2016-05-13 8:28 PM, Ted Hardie wrote: > > Hi Tony, > > Please review RFC 2804. The issue you raise is not a consideration in > this context. > > Regards, > > Ted > --------------74022BB42116C19BDE62230E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Ted,

RFC2804 is familiar, but pronouncements
do not solve real world requirements.  There
are many reasons today why providers require
lawful interception capabilities - which is far
broader than "wiretapping."  Managing traffic,
cybersecurity, and an array of compliance
obligations worldwide necessitate a means
under the appropriate circumstances to acquire
a variety of circumscribed, controlled access to
observables on the wire.  This can't just be blown
away by a political RFC reference.

--tony

On 2016-05-13 8:28 PM, Ted Hardie wrote:

Hi Tony,

Please review RFC 2804. The issue you raise is not a consideration in this context.

Regards,

Ted


--------------74022BB42116C19BDE62230E-- From nobody Fri May 13 17:50:57 2016 Return-Path: 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 710EC12D6C5 for ; Fri, 13 May 2016 17:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ci57nUFV00wt for ; Fri, 13 May 2016 17:50:54 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 2687712D098 for ; Fri, 13 May 2016 17:50:54 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id t10so133231382ywa.0 for ; Fri, 13 May 2016 17:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=eWHocOBjVOgCJOFTwORVvJ4pvjGb3/5CYvuC7k7bM8Q=; b=jBrtik9MVgQbwA5xAcM5mGtFUjmYt7fDAk6DkYswC8TNCLRDrLoL/zDr5LpJC9vWM3 +iyUHlyyy44KewoBGQ3QclSRgP2MWls+4EfkIV9LMy3U/f+v1g9iql9fx19Gmj4cf6l7 KZiw/t3mEnF9fsQmh+P9JoANjgYNrDX6Sk+fp4zWyBfGAUcQhiI8QkevDtBqjQwKpgLd /Ksffh7nhbJPuTSLZXkA+WXanvmkMidBolobfQ+wLcNorcUQzgdTGTJ2u0B3UCDOO3CL ZZ9/+M2nANaU1aKe9tnqbVwyaoEG1DagPW7rP2eVua7yId7h8dPDEY0sDa+aYg5QRQOT ta2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=eWHocOBjVOgCJOFTwORVvJ4pvjGb3/5CYvuC7k7bM8Q=; b=ekLbxAz+3BSe+was/Fo6qFjJ7kiBoPPUg+nYIc0fEEUQasKLYE/S26rjikFk9iv64w WSNEY1synl5BXBbDW9WHVpkjY/YUnUO6Ao+KSrQdCvGJs3EIiu+x7yqkPkouCKGF7FxA 7DjvB0YxhtfO7/BWF6P+sfUR3XH1hMZn3+HgD2vK8oTmFVsA+d1pq9xPPuxMhOg3GMuM dfLVP7efIVA0CXomK72Wd0xla8ULsGbOljcWSG1r9ohJ6hjLq6+7JzGEBRv+PnEFu1Ud Nz1eO6ukCr750zph+KLRuPJKxistQo9XvY2TDWdlrHT3etPf+g5ha+oT5ZD4x9AFiQhD QfIQ== X-Gm-Message-State: AOPr4FUfkFzaYonBZY+fqIWp7eXofgq525oj7bpqe4kc9ZtY0Q/h4P8NBKpXN1zVGR5ir2BuMZoP0W7IQZQs53W3 MIME-Version: 1.0 X-Received: by 10.129.121.81 with SMTP id u78mr8647743ywc.239.1463187053203; Fri, 13 May 2016 17:50:53 -0700 (PDT) Received: by 10.37.221.193 with HTTP; Fri, 13 May 2016 17:50:53 -0700 (PDT) Received: by 10.37.221.193 with HTTP; Fri, 13 May 2016 17:50:53 -0700 (PDT) In-Reply-To: <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk> References: <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk> Date: Fri, 13 May 2016 17:50:53 -0700 Message-ID: From: Jana Iyengar To: tony@yaanatech.co.uk Content-Type: multipart/alternative; boundary=94eb2c0a7b688c3bff0532c2c832 Archived-At: Cc: Christian Huitema , Ted Hardie , quic@ietf.org Subject: Re: [QUIC] Draft charter X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 00:50:56 -0000 --94eb2c0a7b688c3bff0532c2c832 Content-Type: text/plain; charset=UTF-8 Tony, I assume you are asking about lawful interception of HTTPS traffic, which can be over TCP, or, as will be proposed in this BoF, over QUIC -- this isn't a QUIC-specific problem, and therefore probably doesn't belong in this BoF. Did you mean something else? - jana On May 13, 2016 4:55 PM, "Tony Rutkowski" wrote: > How do you intend to provide for lawful > interception that will allow it to be used? > --tony > > On 2016-05-13 7:26 PM, Ted Hardie wrote: > > Howdy, > > As part of the BoF preparation, we put together a stab at a draft > charter. It's available as html and markdown on github at: > > https://github.com/IETF-QUIC/Charter > > I've attached the HTML version as well. > > It would be great to have some of the discussion on the list before the > BoF. Comments to the list or issues/pull requests at the github repo are > welcome. We will periodically reflect any issues or suggestion from the > Repo back to the list, but this will be manual, so expect some lag. > > regards, > > Ted > > > _______________________________________________ > QUIC mailing listQUIC@ietf.orghttps://www.ietf.org/mailman/listinfo/quic > > > --94eb2c0a7b688c3bff0532c2c832 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Tony,

I assume you are asking about lawful interception of HTTPS t= raffic, which can be over TCP, or, as will be proposed in this BoF, over QU= IC -- this isn't a QUIC-specific problem, and therefore probably doesn&= #39;t belong in this BoF.

Did you mean something else?

- jana

On May 13, 2016 4:55 PM, "Tony Rutkowski&qu= ot; <tony@yaanatech.co.uk>= ; wrote:
=20 =20 =20
How do you intend to provide for lawful
interception that will allow it to be used?
--tony

On 2016-05-13 7:26 PM, Ted Hardie wrote:
Howdy,

As part of the BoF preparation, we put together a stab at a draft charter.=C2=A0 It's available as html and markdow= n on github at:

https://github.com/IETF-QUIC/Charter

I've attached the HTML version as well.=C2=A0

It would be great to have some of the discussion on the list before the BoF.=C2=A0 Comments to the list or issues/pull requests at the github repo are welcome.=C2=A0 We will periodically reflect any issues or suggestion from the Repo back to the list, but this will be manual, so expect some lag.

regards,

Ted


_______________________________________________
QUIC mailing list
QUIC@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/quic

--94eb2c0a7b688c3bff0532c2c832-- From nobody Fri May 13 17:55:35 2016 Return-Path: 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 00E1412D1A7 for ; Fri, 13 May 2016 17:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 iKN162J6zZRs for ; Fri, 13 May 2016 17:55:31 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 AD46A12D098 for ; Fri, 13 May 2016 17:55:31 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id g133so117731623ywb.2 for ; Fri, 13 May 2016 17:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tDxz1e+JTG8lZEjZZMYrvdn7aWZY/mRgzpcgVG6XrW4=; b=Wfv3JHV/vYlCF/JxBK1lPRvFF2Ruc/De7FwIT2UXqccKA81haQw+QLIwRK10VwBjV+ MvXcNaFihcZ3grT0hTiOmTLEgxQ0iV1nqvN440ajohug0KnRfCz3YFN3pUPiy6TMKvw0 uyU5BRZM4JccWlxwdjbqTbjo1Vcub6lcl0gK0kMvRYfbKusuj87XwUi2pyivZWrEVAtF i1Xy+0aDiVs+p09rN2zsvG8ezVVw6m45ZJbenZmzzqaMyi1BfDnGP/c/o7kjv1Gj4ldE /KTcqkmbk/YtXLQMGMsQWXMV/cjFq1Va30WwOPKaK4IrCK/Mg4hso60WhOY8DaHntY4w tJ4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tDxz1e+JTG8lZEjZZMYrvdn7aWZY/mRgzpcgVG6XrW4=; b=eJpTY/3lWKSCVUjMQAZPg+yuUIbidNIJ4PkAmBE6utFm+AoJwBkrAeR5Eu4IJwxUcZ 1RzhgRG73su4mtSqIQDYZwTTC3rqAin/a+L41NXrjQGPg2RDtx0i+9FNTH+vc8qPknUG vnGDxZk1GMbrXArU0NPir3iPF1qLSGuFAO4RsBHFelC1JMqLzIJP/6Z2CPzYBMqYyAaY t7nSobddR5dwy/r78Wun1sr3Opu1+C4Xr7BTCi8LaDjj6HFaNtTlOpDrT5zhm7xPVMDC ikY3kFLeSc789Fpu6dlWx71kNsvp3j2FH7He2m17sesy0aWe2cBPTX1ceNfelT0q5SlN akVQ== X-Gm-Message-State: AOPr4FVkyYHgZ6bgCQ069rIJtshpght+3uaIVe7TurmSoPmBPtNyB+BXkxneejVhUPGj+y263fcTUAFpKDVNtA== X-Received: by 10.13.237.1 with SMTP id w1mr8830974ywe.62.1463187330972; Fri, 13 May 2016 17:55:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Fri, 13 May 2016 17:54:51 -0700 (PDT) In-Reply-To: References: <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk> From: Eric Rescorla Date: Fri, 13 May 2016 17:54:51 -0700 Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=94eb2c0864a81a71910532c2d916 Archived-At: Cc: Christian Huitema , tony@yaanatech.co.uk, quic@ietf.org, Ted Hardie Subject: Re: [QUIC] Draft charter X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 00:55:34 -0000 --94eb2c0864a81a71910532c2d916 Content-Type: text/plain; charset=UTF-8 I too am having trouble understanding the concern. We already have extensive experience with end-to-end encryption for HTTPS traffic (specifically HTTP over TLS over TCP) and those protocols contain no provisions for lawful intercept. As Jana says, QUIC is isomorphic to that stack and as it will be using the same security layer (TLS), whatever law enforcement currently does would presumably also apply with small modifications to QUIC. -Ekr On Fri, May 13, 2016 at 5:50 PM, Jana Iyengar wrote: > Tony, > > I assume you are asking about lawful interception of HTTPS traffic, which > can be over TCP, or, as will be proposed in this BoF, over QUIC -- this > isn't a QUIC-specific problem, and therefore probably doesn't belong in > this BoF. > > Did you mean something else? > > - jana > On May 13, 2016 4:55 PM, "Tony Rutkowski" wrote: > >> How do you intend to provide for lawful >> interception that will allow it to be used? >> --tony >> >> On 2016-05-13 7:26 PM, Ted Hardie wrote: >> >> Howdy, >> >> As part of the BoF preparation, we put together a stab at a draft >> charter. It's available as html and markdown on github at: >> >> https://github.com/IETF-QUIC/Charter >> >> I've attached the HTML version as well. >> >> It would be great to have some of the discussion on the list before the >> BoF. Comments to the list or issues/pull requests at the github repo are >> welcome. We will periodically reflect any issues or suggestion from the >> Repo back to the list, but this will be manual, so expect some lag. >> >> regards, >> >> Ted >> >> >> _______________________________________________ >> QUIC mailing listQUIC@ietf.orghttps://www.ietf.org/mailman/listinfo/quic >> >> >> > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --94eb2c0864a81a71910532c2d916 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I too am having trouble understanding the concern. We alre= ady have extensive experience with end-to-end encryption for HTTPS traffic = (specifically HTTP over TLS over TCP) and those protocols contain no provis= ions for lawful intercept. As Jana says, QUIC is isomorphic to that stack a= nd as it will be using the same security layer (TLS), whatever law enforcem= ent currently does would presumably also apply with small modifications to = QUIC.

-Ekr


On Fri, May 13, 2016 at 5:50 PM,= Jana Iyengar <jri@google.com> wrote:

Tony,

I assume you are asking about lawful interception of HTTPS t= raffic, which can be over TCP, or, as will be proposed in this BoF, over QU= IC -- this isn't a QUIC-specific problem, and therefore probably doesn&= #39;t belong in this BoF.

Did you mean something else?

- jana

On May 13, 2016 4:55 PM, "Tony Rutkowski&qu= ot; <tony@yaan= atech.co.uk> wrote:
=20 =20 =20
How do you intend to provide for lawful
interception that will allow it to be used?
--tony

On 2016-05-13 7:26 PM, Ted Hardie wrote:
Howdy,

As part of the BoF preparation, we put together a stab at a draft charter.=C2=A0 It's available as html and markdow= n on github at:

https://github.com/IETF-QUIC/Charter

I've attached the HTML version as well.=C2=A0

It would be great to have some of the discussion on the list before the BoF.=C2=A0 Comments to the list or issues/pull requests at the github repo are welcome.=C2=A0 We will periodically reflect any issues or suggestion from the Repo back to the list, but this will be manual, so expect some lag.

regards,

Ted


_______________________________________________
QUIC mailing list
QUIC@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/quic


_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic


--94eb2c0864a81a71910532c2d916-- From nobody Fri May 13 18:35:03 2016 Return-Path: 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 49B1912D65F for ; Fri, 13 May 2016 18:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 bdp9BisZgvE1 for ; Fri, 13 May 2016 18:34:59 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 9C5BC12D19E for ; Fri, 13 May 2016 18:34:59 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id k142so196896614oib.1 for ; Fri, 13 May 2016 18:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ogUgbhFYavSFA0xyorYyTmlVLWAsCYQxCZJajnqTq5E=; b=Jt2CbtSzFuFJTroK65zH0lrvX7YTu8c6AU1rfcxIsz3h14f3jIDDk4WZJxo6J9oBu5 QaBIc7sx58IIA2JKgE8SYxCb9xNFzo1QDmgRldc9yM3klzdN8x+P2vwX5a/xzuSXPgdO fzq9ashulzOKn1w83nxiHiqOhC1HGLaxA9yOsT2o5J2MFw/kxRgzwsDsiOKBJ1f7RGRZ HORS4KaTymW4FfqVKxF4dvb5EMou1Tz1T+Ay4zJo2OpVKLJhJw5sPN1OrW8K1Avr3TFv O8cOqcmyrprt8SSypkQ8MUToJx3lVK1SqUKEs+Y5rAQ9rqV6a0g+Ej2CGdsrkXn+CQD9 qHSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ogUgbhFYavSFA0xyorYyTmlVLWAsCYQxCZJajnqTq5E=; b=QOrn9i+4jMK9VR10mZNZtQEVKJ7iL/AIcI5xsj//eCKsZmOlHZDAmGL+oiQ9tk1T9X MXnQKZCIF7TZIFKkZa1KX1laDVI9VMXbzQpKBKjPh2w4HyiUgvaWL93pWRExaE/ZcPlE M342KUobXFyBf7xR4Lyty4AEkTqr7yBfo8obTarE9IdD7cxlsIF2HzN2M9mj85W9Pa8k g6HZzfigK5S2BHE60UrqVROTjQZ1kCKhgOqMcunhZH3Sy7qykF6QBU2VVNaaBoNqB+xs uw9ZXA0SKp8OD/mve2eyEqypHYPNqh+3/x/r9ywdhK1dNsogyBf21QpYQRCeIbrxgoAV I2cw== X-Gm-Message-State: AOPr4FVRXS/49fJEUIqCTXfxf4eUzSpSSovMgI30lPDjeFZL9dTo0I1wgFKdOoweuJ55TPl5nSzfDN055ljM1g== X-Received: by 10.157.20.149 with SMTP id d21mr10153936ote.143.1463189698983; Fri, 13 May 2016 18:34:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.213.210 with HTTP; Fri, 13 May 2016 18:34:39 -0700 (PDT) In-Reply-To: <364acd38-cea7-c242-5cb7-9f427c4f008e@yaanatech.co.uk> References: <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk> <364acd38-cea7-c242-5cb7-9f427c4f008e@yaanatech.co.uk> From: Ted Hardie Date: Fri, 13 May 2016 18:34:39 -0700 Message-ID: To: tony@yaanatech.co.uk Content-Type: multipart/alternative; boundary=001a113e22ac3f3b150532c366a8 Archived-At: Cc: Jana Iyengar , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Draft charter X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 01:35:02 -0000 --001a113e22ac3f3b150532c366a8 Content-Type: text/plain; charset=UTF-8 On Fri, May 13, 2016 at 5:34 PM, Tony Rutkowski wrote: > Hi Ted, > > RFC2804 is familiar, but pronouncements > do not solve real world requirements. > RFC 2804 is a consensus statement of the IETF on what sort of work it will take on. In the context of a charter for work in the IETF, it is salient. > There > are many reasons today why providers require > lawful interception capabilities - which is far > broader than "wiretapping." Managing traffic, > cybersecurity, and an array of compliance > obligations worldwide necessitate a means > under the appropriate circumstances to acquire > a variety of circumscribed, controlled access to > observables on the wire. This can't just be blown > away by a political RFC reference. > > You are welcome to suggest changes in IETF policy for these reasons (or any others). Given the publication of RFC 7258 and RFC 7624, I do not think of much of your chances, honestly, but the drafts directory is open at your will. The General Area director will no doubt be happy to suggest an appropriate place for discussion. Until the policy has changed, however, putting forward a charter with work the IETF will not do is simply a waste of time. Ted > --tony > > On 2016-05-13 8:28 PM, Ted Hardie wrote: > > Hi Tony, > > Please review RFC 2804. The issue you raise is not a consideration in this > context. > > Regards, > > Ted > > > --001a113e22ac3f3b150532c366a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, May 13, 2016 at 5:34 PM, Tony Rutkowski <tony= @yaanatech.co.uk> wrote:
=20 =20 =20
Hi Ted,

RFC2804 is familiar, but pronouncements
do not solve real world requirements.=C2=A0

=
RFC 2804 is a consensus statement of the IETF on what sort of wo= rk it will take on.=C2=A0 In the context of a charter for work in the IETF,= it is salient.
=C2=A0
There
are many reasons today why providers require
lawful interception capabilities - which is far
broader than "wiretapping."=C2=A0 Managing traffic,
cybersecurity, and an array of compliance
obligations worldwide necessitate a means
under the appropriate circumstances to acquire
a variety of circumscribed, controlled access to
observables on the wire.=C2=A0 This can't just be blown
away by a political RFC reference.


You are welcom= e to suggest changes in IETF policy for these reasons (or any others).=C2= =A0=C2=A0 Given the publication of RFC 7258 and RFC 7624, I do not think of= much of your chances, honestly, but the drafts directory is open at your w= ill.=C2=A0 The General Area director will no doubt be happy to suggest an a= ppropriate place for discussion.

Until the policy has changed, howev= er, putting forward a charter with work the IETF will not do is simply a wa= ste of time.=C2=A0

Ted
=C2=A0
--tony

On 2016-05-13 8:28 PM, Ted Hardie wrote:

Hi Tony,

Please review RFC 2804. The issue you raise is not a consideration in this context.

Regards,

Ted



--001a113e22ac3f3b150532c366a8-- From nobody Sat May 14 05:42:04 2016 Return-Path: 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 191CA12D72C for ; Sat, 14 May 2016 05:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 AFRYqxJZcl6Z for ; Sat, 14 May 2016 05:42:01 -0700 (PDT) Received: from uk-www1.yaanatech.uk (uk-www1.yaanatech.uk [46.20.116.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5594812D724 for ; Sat, 14 May 2016 05:42:01 -0700 (PDT) Received: from [192.168.1.51] (pool-173-67-205-17.clppva.fios.verizon.net [173.67.205.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by uk-www1.yaanatech.uk (Postfix) with ESMTPSA id 2BE605402A3; Sat, 14 May 2016 13:41:59 +0100 (BST) References: <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk> <364acd38-cea7-c242-5cb7-9f427c4f008e@yaanatech.co.uk> To: Ted Hardie From: Tony Rutkowski Organization: Yaana Ltd Message-ID: Date: Sat, 14 May 2016 08:41:58 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------631680585A8E11E9336BB619" Archived-At: Cc: Jana Iyengar , quic@ietf.org, Christian Huitema Subject: Re: [QUIC] Draft charter X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tony@yaanatech.co.uk List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 12:42:03 -0000 This is a multi-part message in MIME format. --------------631680585A8E11E9336BB619 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ted, This is an unfortunate fallout of the extreme politicization of the IETF in recent years resulting in religious dogma concerning the technology. The result is that the IETF does a lot of work that itself is a waste of time because it doesn't meet the requirements of industry and legal systems, and inures to the benefit of the worst kinds of end users. One would like to think there is some halfway house such as the IEEE's new Encrypted Traffic Inspection working group. It isn't quite so dogmatic and religious. sigh, tony On 2016-05-13 9:34 PM, Ted Hardie wrote: > Until the policy has changed, however, putting forward a charter with > work the IETF will not do is simply a waste of time. > --------------631680585A8E11E9336BB619 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Ted,

This is an unfortunate fallout of the extreme
politicization of the IETF in recent years resulting
in religious dogma concerning the technology.
The result is that the IETF does a lot of work
that itself is a waste of time because it doesn't
meet the requirements of industry and legal
systems, and inures to the benefit of the worst
kinds of end users.

One would like to think there is some halfway
house such as the IEEE's new Encrypted Traffic
Inspection working group.  It isn't quite so
dogmatic and religious.

sigh,
tony

On 2016-05-13 9:34 PM, Ted Hardie wrote:
Until the policy has changed, however, putting forward a charter with work the IETF will not do is simply a waste of time. 


--------------631680585A8E11E9336BB619-- From nobody Sat May 14 06:30:42 2016 Return-Path: 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 C04E712B01D for ; Sat, 14 May 2016 06:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 4MX_w02fqgiT for ; Sat, 14 May 2016 06:30:38 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id D5425128B44 for ; Sat, 14 May 2016 06:30:38 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A83463F4011; Sat, 14 May 2016 13:30:37 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 9004C3F400F; Sat, 14 May 2016 13:30:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1463232637; bh=GN/I+ECGnilrvH6x90vnjbPZE3tkkqlckHZiuPvVHAk=; l=140; h=From:To:CC:Date:References:In-Reply-To:From; b=Mbg994chYI5xMG7S4Nn7U+rCiSsJ6n5g+SSwJD7DpQE4n6Bdf8+gTX8c7ILCyTznU CeeQhM0dR+FH9g6bms5bXeYmI2j03kwpaWOXrrxpfJTnePO45a6FweuPx2yVKT/qDs uPnO1etfUVZTF2ndpR5uABYGGvo0t3KW0z7fzyZw= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 8C5F51FC8B; Sat, 14 May 2016 13:30:37 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sat, 14 May 2016 06:30:37 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Sat, 14 May 2016 09:30:37 -0400 From: "Salz, Rich" To: "tony@yaanatech.co.uk" , Ted Hardie Thread-Topic: [QUIC] Draft charter Thread-Index: AQHRrXBx6BMdhNaeXU+kg/B/eHuvHZ+3zhiAgAAJCACAAAG7AIAAEOGAgAC6cwD//8pskA== Date: Sat, 14 May 2016 13:30:36 +0000 Message-ID: <68abb62690a54ceaa80e70bd73045db3@usma1ex-dag1mb1.msg.corp.akamai.com> References: <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk> <364acd38-cea7-c242-5cb7-9f427c4f008e@yaanatech.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Jana Iyengar , "quic@ietf.org" , Christian Huitema Subject: Re: [QUIC] Draft charter X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 13:30:41 -0000 DQo+IFRoZSByZXN1bHQgaXMgdGhhdCB0aGUgSUVURiBkb2VzIGEgbG90IG9mIHdvcmsgdGhhdCBp dHNlbGYgaXMgYSB3YXN0ZSBvZiB0aW1lDQoNCg0KU3VjaCBhcz8NCg0KDQo= From nobody Sat May 14 08:23:42 2016 Return-Path: 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 5653D127058 for ; Sat, 14 May 2016 08:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NkiRAGsjFKBx for ; Sat, 14 May 2016 08:23:38 -0700 (PDT) Received: from uk-www1.yaanatech.uk (uk-www1.yaanatech.uk [46.20.116.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CEB312D11A for ; Sat, 14 May 2016 08:23:38 -0700 (PDT) Received: from [192.168.1.51] (pool-173-67-205-17.clppva.fios.verizon.net [173.67.205.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by uk-www1.yaanatech.uk (Postfix) with ESMTPSA id E568A540332; Sat, 14 May 2016 16:23:35 +0100 (BST) References: <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk> <364acd38-cea7-c242-5cb7-9f427c4f008e@yaanatech.co.uk> <68abb62690a54ceaa80e70bd73045db3@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" , Ted Hardie From: Tony Rutkowski Organization: Yaana Ltd Message-ID: <8adaaef1-f7f1-b350-cb14-88b2b9e46aef@yaanatech.co.uk> Date: Sat, 14 May 2016 11:23:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <68abb62690a54ceaa80e70bd73045db3@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------D1FA0AFFE74A8F0B085B1F8E" Archived-At: Cc: Jana Iyengar , "quic@ietf.org" , Christian Huitema Subject: Re: [QUIC] Draft charter X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tony@yaanatech.co.uk List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 15:23:40 -0000 This is a multi-part message in MIME format. --------------D1FA0AFFE74A8F0B085B1F8E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit As a SWAG, observing the IETF and precursor over the past 45 some years, maybe about 10 percent of its RFCs have seen substantial implementation. That's not bad for an academic oriented group and a testament to innovation introduced. The much larger, major industry ones such as 3GPP achieve higher success rates because their specs are mandated into the infrastructure and service. Ditto CableLabs and the large vendor development group organizations. The IETF's religious views on encryption and failure to support forensic requirements seem to be producing RFCs that will not pass legal muster or meet industry service agreements or expose providers to significant tort penalties. (As the guy who initially arranged for ISOC to provide liability insurance to those in IETF positions, it might be worth considering, increasing the coverage with the increasing awards being witnessed in tort litigation.) --tony On 2016-05-14 9:30 AM, Salz, Rich wrote: >> The result is that the IETF does a lot of work that itself is a waste of time > > Such as? > > --------------D1FA0AFFE74A8F0B085B1F8E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit As a SWAG, observing the IETF and
precursor over the past 45 some years,
maybe about 10 percent of its RFCs have
seen substantial implementation.  That's
not bad for an academic oriented group and
a testament to innovation introduced.

The much larger, major industry ones such
as 3GPP achieve higher success rates because
their specs are mandated into the infrastructure
and service.  Ditto CableLabs and the large vendor
development group organizations.

The IETF's religious views on encryption and
failure to support forensic requirements seem
to be producing RFCs that will not pass legal
muster or meet industry service agreements
or expose providers to significant tort penalties.
(As the guy who initially arranged for ISOC to
provide liability insurance to those in IETF
positions, it might be worth considering, increasing
the coverage with the increasing awards being
witnessed in tort litigation.)

--tony


On 2016-05-14 9:30 AM, Salz, Rich wrote:

      

        
The result is that the IETF does a lot of work that itself is a waste of time


      

      

Such as?




    

    

  


--------------D1FA0AFFE74A8F0B085B1F8E--


From nobody Sat May 14 08:30:03 2016
Return-Path: 
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 E845C12D11A for ; Sat, 14 May 2016 08:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.226
X-Spam-Level: 
X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 IokiP9HI7gkS for ; Sat, 14 May 2016 08:30:00 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2139F12D0DA for ; Sat, 14 May 2016 08:29:59 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2FDD743340F; Sat, 14 May 2016 15:29:59 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 1856B433401; Sat, 14 May 2016 15:29:59 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1463239799; bh=bWOzeJ+G6NWqWa58wcm0nh+91NG16q38lcvUYdXN23Y=; l=6064; h=From:To:CC:Date:References:In-Reply-To:From; b=pAbhud5U+biRpJz41amKGQX6lKQpw9EIoJMqPdSzmtiYtHaBKXzY5wa5Z7DESFP4g Z3yMGurcSUUCr0mPpR4twKjXn3VTjSGknsYonLdllMY2eUK9ASMbkPkd2HfvOmvDqp bjTtbDqjdLFzbPOQICQWDFgzXIRfpUY7t4Sn73cY=
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 12F151FC8B; Sat, 14 May 2016 15:29:59 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sat, 14 May 2016 11:29:58 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Sat, 14 May 2016 11:29:58 -0400
From: "Salz, Rich" 
To: "tony@yaanatech.co.uk" 
Thread-Topic: [QUIC] Draft charter
Thread-Index: AQHRrXBx6BMdhNaeXU+kg/B/eHuvHZ+3zhiAgAAJCACAAAG7AIAAEOGAgAC6cwD//8pskIAAYroA//+9ENA=
Date: Sat, 14 May 2016 15:29:57 +0000
Message-ID: <4702f8bff0af40459f50c466f98c2e25@usma1ex-dag1mb1.msg.corp.akamai.com>
References:  <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk>  <364acd38-cea7-c242-5cb7-9f427c4f008e@yaanatech.co.uk>   <68abb62690a54ceaa80e70bd73045db3@usma1ex-dag1mb1.msg.corp.akamai.com> <8adaaef1-f7f1-b350-cb14-88b2b9e46aef@yaanatech.co.uk>
In-Reply-To: <8adaaef1-f7f1-b350-cb14-88b2b9e46aef@yaanatech.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.47.54]
Content-Type: multipart/alternative; boundary="_000_4702f8bff0af40459f50c466f98c2e25usma1exdag1mb1msgcorpak_"
MIME-Version: 1.0
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 May 2016 15:30:02 -0000

--_000_4702f8bff0af40459f50c466f98c2e25usma1exdag1mb1msgcorpak_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VG9ueSwNCg0KUGxlYXNlIG5hbWUgb25lIHNwZWNpZmljIGV4YW1wbGUuICBObyBndWVzc2VzLiAg
T25lIHRoYXQgaXMgbm90IHRydW1wZWQgYnksIHNheSwgVExTIG9yIElQc2VjLg0KDQpBcyBmb3Ig
Y29tcGFyaXNvbnMgdG8gQ2FibGVMYWJzIG9yIDNHUFAsIHRoZXkgcGVyaGFwcyBnZXQgaGlnaGVy
IHJhdGVzIG9mIHN1Y2Nlc3MgYnV0IChhKSBlbnRyeSBjb3N0cyBhcmUgcHJvaGliaXRpdmUgYW5k
IChiKSByZWNvcmRzIGFyZSBub3QgcHVibGljLiAgU28gd2hvIGtub3dzIGlmIHdoYXQgeW91IGNs
YWltIGlzIGFjY3VyYXRlLCBvciBldmVuIHdoYXQgdGhlIHJlYXNvbnMgZm9yIGl0IGFyZT8gIFRo
ZSBtb2JpbGUgaW5kdXN0cmllcyBoaXN0b3J5IHdpdGggZW5jcnlwdGlvbiBpcyBhIHNhZCBvbmUs
IGlzbuKAmXQgaXQuDQotLQ0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0K
SU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0K

--_000_4702f8bff0af40459f50c466f98c2e25usma1exdag1mb1msgcorpak_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N
Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu
TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj
b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2
aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl
ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0K
c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt
YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI
VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N
c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox
MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp
bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y
ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd
LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+
DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht
bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V
UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPlRvbnksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2UgbmFtZSBvbmUgc3BlY2lmaWMgZXhhbXBs
ZS4mbmJzcDsgTm8gZ3Vlc3Nlcy4mbmJzcDsgT25lIHRoYXQgaXMgbm90IHRydW1wZWQgYnksIHNh
eSwgVExTIG9yIElQc2VjLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBmb3IgY29tcGFyaXNvbnMgdG8gQ2FibGVM
YWJzIG9yIDNHUFAsIHRoZXkgcGVyaGFwcyBnZXQgaGlnaGVyIHJhdGVzIG9mIHN1Y2Nlc3MgYnV0
IChhKSBlbnRyeSBjb3N0cyBhcmUgcHJvaGliaXRpdmUgYW5kIChiKSByZWNvcmRzIGFyZSBub3Qg
cHVibGljLiZuYnNwOyBTbyB3aG8NCiBrbm93cyBpZiB3aGF0IHlvdSBjbGFpbSBpcyBhY2N1cmF0
ZSwgb3IgZXZlbiB3aGF0IHRoZSByZWFzb25zIGZvciBpdCBhcmU/Jm5ic3A7IFRoZSBtb2JpbGUg
aW5kdXN0cmllcyBoaXN0b3J5IHdpdGggZW5jcnlwdGlvbiBpcyBhIHNhZCBvbmUsIGlzbuKAmXQg
aXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLSZuYnNwOw0KPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9s
b2dpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SU06IHJpY2hzYWx6QGphYmJlci5h
dCBUd2l0dGVyOiBSaWNoU2FsejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_4702f8bff0af40459f50c466f98c2e25usma1exdag1mb1msgcorpak_--


From nobody Sat May 14 08:46:02 2016
Return-Path: 
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 5790712D0DA for ; Sat, 14 May 2016 08:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 6wh2ROhtKdWj for ; Sat, 14 May 2016 08:46:00 -0700 (PDT)
Received: from uk-www1.yaanatech.uk (uk-www1.yaanatech.uk [46.20.116.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204A1127058 for ; Sat, 14 May 2016 08:46:00 -0700 (PDT)
Received: from [192.168.1.51] (pool-173-67-205-17.clppva.fios.verizon.net [173.67.205.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by uk-www1.yaanatech.uk (Postfix) with ESMTPSA id 68F6D540332; Sat, 14 May 2016 16:45:58 +0100 (BST)
References:  <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk>  <364acd38-cea7-c242-5cb7-9f427c4f008e@yaanatech.co.uk>   <68abb62690a54ceaa80e70bd73045db3@usma1ex-dag1mb1.msg.corp.akamai.com> <8adaaef1-f7f1-b350-cb14-88b2b9e46aef@yaanatech.co.uk> <4702f8bff0af40459f50c466f98c2e25@usma1ex-dag1mb1.msg.corp.akamai.com>
To: "Salz, Rich" 
From: Tony Rutkowski 
Organization: Yaana Ltd
Message-ID: <009b59bf-02a5-cc92-94dc-32f3c3a5afc9@yaanatech.co.uk>
Date: Sat, 14 May 2016 11:45:57 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <4702f8bff0af40459f50c466f98c2e25@usma1ex-dag1mb1.msg.corp.akamai.com>
Content-Type: multipart/alternative; boundary="------------A644E53F59CA88D4948EC1A0"
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: tony@yaanatech.co.uk
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 May 2016 15:46:01 -0000

This is a multi-part message in MIME format.
--------------A644E53F59CA88D4948EC1A0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Contraire.  Their specifications are public,
free, well versioned, and easily discoverable
with persistent URI's.  In the case of 3GPP, all
of its input materials are public - even if not
downloadable without membership - which
at the lowest levels is not much more than IETF
meeting charges these days.  The biggest challenge
is dealing with the enormous amount of work,
and frequency of meetings - spread across almost
40 groups.

The history is hardly sad.  It cost effectively meets
the needs of providers and end users and passes
legal muster.  It also by any metric has produced
by far the largest, most ubiquitous, and most
successful electronic communications infrastructure
worldwide.  It represents the difference between
industry and academic groups; and the fact that
the encryption is good enough for the vast preponderance
of users except maybe ISIS, underscores that difference.

--tony

On 2016-05-14 11:29 AM, Salz, Rich wrote:
>
> As for comparisons to CableLabs or 3GPP, they perhaps get higher rates 
> of success but (a) entry costs are prohibitive and (b) records are not 
> public.  So who knows if what you claim is accurate, or even what the 
> reasons for it are?  The mobile industries history with encryption is 
> a sad one, isn’t it.
>


--------------A644E53F59CA88D4948EC1A0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Contraire.  Their specifications are public,

    free, well versioned, and easily discoverable 

    with persistent URI's.  In the case of 3GPP, all 

    of its input materials are public - even if not 

    downloadable without membership - which 

    at the lowest levels is not much more than IETF 

    meeting charges these days.  The biggest challenge 

    is dealing with the enormous amount of work,

    and frequency of meetings - spread across almost

    40 groups.

    

    The history is hardly sad.  It cost effectively meets

    the needs of providers and end users and passes

    legal muster.  It also by any metric has produced

    by far the largest, most ubiquitous, and most 

    successful electronic communications infrastructure

    worldwide.  It represents the difference between

    industry and academic groups; and the fact that

    the encryption is good enough for the vast preponderance

    of users except maybe ISIS, underscores that difference.

    

    --tony

    

    
On 2016-05-14 11:29 AM, Salz, Rich
      wrote:

    

    

      
As
          for comparisons to CableLabs or 3GPP, they perhaps get higher
          rates of success but (a) entry costs are prohibitive and (b)
          records are not public.  So who knows if what you claim is
          accurate, or even what the reasons for it are?  The mobile
          industries history with encryption is a sad one, isn’t it.

      

        

      

    

    

  


--------------A644E53F59CA88D4948EC1A0--


From nobody Sat May 14 08:48:20 2016
Return-Path: 
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 0A0C012D0D3 for ; Sat, 14 May 2016 08:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.226
X-Spam-Level: 
X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 ktRp6W4co4-R for ; Sat, 14 May 2016 08:48:17 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 81D3F127058 for ; Sat, 14 May 2016 08:48:17 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A3A2916C82A; Sat, 14 May 2016 15:48:16 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 82C5316C919; Sat, 14 May 2016 15:48:16 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1463240896; bh=ho7HTguvwP9TEmRXU5QMstzSeWsWk7L6/jB8sJpbaIo=; l=5478; h=From:To:CC:Date:References:In-Reply-To:From; b=XnVFYzL8Y4sqjfMSXNECYd4OqVRUbJ6ZaPN4xSKKbi6ZEravZjrN/XXN8vUv1+6G5 UKb8BJrANx3potIETQIdzOseMph9lZFhpdIn/KTYyH44sTOoB1p7fmdrKMAfJQ8PM/ VezUFgY6kffxvCsHPaDziJXGGQVGYBI8q4gqJ1oM=
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 5FAD21E07C; Sat, 14 May 2016 15:48:16 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sat, 14 May 2016 11:48:15 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Sat, 14 May 2016 11:48:15 -0400
From: "Salz, Rich" 
To: "tony@yaanatech.co.uk" 
Thread-Topic: [QUIC] Draft charter
Thread-Index: AQHRrXBx6BMdhNaeXU+kg/B/eHuvHZ+3zhiAgAAJCACAAAG7AIAAEOGAgAC6cwD//8pskIAAYroA//+9ENCAAEkxgP//vRgA
Date: Sat, 14 May 2016 15:48:15 +0000
Message-ID: <09e4799c8c23497f843d5ea61c54202a@usma1ex-dag1mb1.msg.corp.akamai.com>
References:  <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk>  <364acd38-cea7-c242-5cb7-9f427c4f008e@yaanatech.co.uk>   <68abb62690a54ceaa80e70bd73045db3@usma1ex-dag1mb1.msg.corp.akamai.com> <8adaaef1-f7f1-b350-cb14-88b2b9e46aef@yaanatech.co.uk> <4702f8bff0af40459f50c466f98c2e25@usma1ex-dag1mb1.msg.corp.akamai.com> <009b59bf-02a5-cc92-94dc-32f3c3a5afc9@yaanatech.co.uk>
In-Reply-To: <009b59bf-02a5-cc92-94dc-32f3c3a5afc9@yaanatech.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.47.54]
Content-Type: multipart/alternative; boundary="_000_09e4799c8c23497f843d5ea61c54202ausma1exdag1mb1msgcorpak_"
MIME-Version: 1.0
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 May 2016 15:48:19 -0000

--_000_09e4799c8c23497f843d5ea61c54202ausma1exdag1mb1msgcorpak_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VG9ueSwNCg0KQ2FuIEkgc2VlIGRyYWZ0cyBhbmQgZmFpbGVkIHdvcmtpbmcgZ3JvdXBzIGFuZCBy
ZWFkIGVtYWlsIGFuZCB1bmRlcnN0YW5kIHdoeSBBUy81IHdhcyBwaWNrZWQsIGZvciBleGFtcGxl
PyAgQ29zdCB0byBmdWxseSBwYXJ0aWNpcGF0ZSBpbiBJRVRGIGlzIGVtYWlsIGFuZCBJbnRlcm5l
dCB2aWRlbywgcmVhbGx5Lg0KDQpBbnkgYW55IHJhdGUsIHN0aWxsIGxvb2tpbmcgZm9yIHByb29m
LCByYXRoZXIgdGhhbiBhc3NlcnRpb24sIG9mIElFVEYgUkZD4oCZcyB0aGF0IGZhaWxlZCBiZWNh
dXNlIG9mIGxhdyBlbmZvcmNlbWVudC4gIE9yIGV2ZW4ganVzdCB3YXN0ZWQgZWZmb3J0Lg0KDQot
LQ0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KSU06IHJpY2hzYWx6QGph
YmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0K

--_000_09e4799c8c23497f843d5ea61c54202ausma1exdag1mb1msgcorpak_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0K
YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s
b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N
c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy
cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg
ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N
Cjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRvbnksPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5DYW4gSSBzZWUgZHJhZnRzIGFuZCBmYWlsZWQgd29ya2luZyBncm91cHMgYW5kIHJlYWQgZW1h
aWwgYW5kIHVuZGVyc3RhbmQgd2h5IEFTLzUgd2FzIHBpY2tlZCwgZm9yIGV4YW1wbGU/Jm5ic3A7
IENvc3QgdG8gZnVsbHkgcGFydGljaXBhdGUgaW4gSUVURiBpcyBlbWFpbCBhbmQgSW50ZXJuZXQN
CiB2aWRlbywgcmVhbGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW55IGFueSByYXRlLCBzdGlsbCBsb29raW5nIGZv
ciBwcm9vZiwgcmF0aGVyIHRoYW4gYXNzZXJ0aW9uLCBvZiBJRVRGIFJGQ+KAmXMgdGhhdCBmYWls
ZWQgYmVjYXVzZSBvZiBsYXcgZW5mb3JjZW1lbnQuJm5ic3A7IE9yIGV2ZW4ganVzdCB3YXN0ZWQg
ZWZmb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+U2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llczxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5JTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hT
YWx6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_09e4799c8c23497f843d5ea61c54202ausma1exdag1mb1msgcorpak_--


From nobody Sat May 14 09:26:05 2016
Return-Path: 
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 F28B312D138 for ; Sat, 14 May 2016 09:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level: 
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Z__60tMLzaf6 for ; Sat, 14 May 2016 09:26:03 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 B015B12D135 for ; Sat, 14 May 2016 09:26:03 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id x201so213963160oif.3 for ; Sat, 14 May 2016 09:26:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KRmPo3u0xTiGGGvfWhep4XCSL6WhHR9SKI6AoK4+Uk4=; b=mvLQfq54ScACaDSFQSmSj93L7B7V9LBS0T4jeCVe6zoi58g9RejmlnPuQvce1E3b3P xgT/uLz8cSBqrE3Hc4wXVEGfdMxgO4hHYPrvc9iFAfJEXYX+pODFz+q/yJNSQl7QOePh b7fzd33xtRQ72q/jYG4lbx3tXP/jV89krzKeP1KQbkzK5xF2I0lbUFH3qBcclBe40WqX F8DmYf6MjKBaVCLXFdgmSFxgymwsb4d2s0vEwHFit8eMNce6m8cvMRpIve1MFfwRGkCG KPQG8TOHSse21hMNBZAJfp6sKuroD82vvgeltGLk+C+kIJuUZ4/v5Fyhiwq2WF2bH5YV 1dwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KRmPo3u0xTiGGGvfWhep4XCSL6WhHR9SKI6AoK4+Uk4=; b=l4URIqksA2mziWTfTZhioA1EnHobC95ZqIRYvZ6pYa1kpuSMj+xH7vZTKvwKCMKXpL dhblIHNL/TsGhLYbIg7Qn/+3URiE/Aq8uf4vVZ1viA3hkfAa1UEhH9J53rPyQMJ5y5Sg j8lhjFdQhXt9OnregJlBN2D5vvI4fWKJXvqc4OsXeeX1BroA4SE5OJuQ143BJs7ThDVH bfsGlo0iTwxbq+1m9ECUKglSN5BuVOTZLH4gcAmRclXtNDg5n0afclt4FGbE1r7EylA2 V7s4oFiw+V9MzeR3F2MIuIHe3x5uwSoojDjRtCTo6jFHfvchK7JJXeaGeIPOiIbvEC3C KofA==
X-Gm-Message-State: AOPr4FWkI6kGBwooJpl2l8wEaJO1ESzgR/TxDtqVcUssjda1Oe4CAwD9aiHbV7f2mCve2pX1hwA9IBzxfqG0kA==
X-Received: by 10.202.215.86 with SMTP id o83mr10913024oig.55.1463243162936; Sat, 14 May 2016 09:26:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.213.210 with HTTP; Sat, 14 May 2016 09:25:43 -0700 (PDT)
In-Reply-To: <09e4799c8c23497f843d5ea61c54202a@usma1ex-dag1mb1.msg.corp.akamai.com>
References:  <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk>  <364acd38-cea7-c242-5cb7-9f427c4f008e@yaanatech.co.uk>   <68abb62690a54ceaa80e70bd73045db3@usma1ex-dag1mb1.msg.corp.akamai.com> <8adaaef1-f7f1-b350-cb14-88b2b9e46aef@yaanatech.co.uk> <4702f8bff0af40459f50c466f98c2e25@usma1ex-dag1mb1.msg.corp.akamai.com> <009b59bf-02a5-cc92-94dc-32f3c3a5afc9@yaanatech.co.uk> <09e4799c8c23497f843d5ea61c54202a@usma1ex-dag1mb1.msg.corp.akamai.com>
From: Ted Hardie 
Date: Sat, 14 May 2016 09:25:43 -0700
Message-ID: 
To: "Salz, Rich" 
Content-Type: multipart/alternative; boundary=001a113d3c30f26cf00532cfd8ea
Archived-At: 
Cc: "tony@yaanatech.co.uk" , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 May 2016 16:26:05 -0000

--001a113d3c30f26cf00532cfd8ea
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Howdy,

This seems to have gone in a direction not directly related to the subject
"draft charter" or, indeed, to QUIC specifically.  Can I ask you gentlemen
to take the discussion to a different venue?

thanks,

Ted

On Sat, May 14, 2016 at 8:48 AM, Salz, Rich  wrote:

> Tony,
>
>
>
> Can I see drafts and failed working groups and read email and understand
> why AS/5 was picked, for example?  Cost to fully participate in IETF is
> email and Internet video, really.
>
>
>
> Any any rate, still looking for proof, rather than assertion, of IETF
> RFC=E2=80=99s that failed because of law enforcement.  Or even just waste=
d effort.
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> IM: richsalz@jabber.at Twitter: RichSalz
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>

--001a113d3c30f26cf00532cfd8ea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Howdy,

This seems to have gone=
 in a direction not directly related to the subject "draft charter&quo=
t; or, indeed, to QUIC specifically.=C2=A0 Can I ask you gentlemen to take =
the discussion to a different venue?

thanks,

Ted<=
br>

On Sat, =
May 14, 2016 at 8:48 AM, Salz, Rich <rsalz@akamai.com> wrote:=












Tony,


=C2=A0


Can I see drafts and fail=
ed working groups and read email and understand why AS/5 was picked, for ex=
ample?=C2=A0 Cost to fully participate in IETF is email and Internet
 video, really.


=C2=A0


Any any rate, still looki=
ng for proof, rather than assertion, of IETF RFC=E2=80=99s that failed beca=
use of law enforcement.=C2=A0 Or even just wasted effort.


=C2=A0




--=C2=A0



Senior Architect, Akamai =
Technologies


IM: richsalz@jabber.at Twitter: RichSalz=










_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--001a113d3c30f26cf00532cfd8ea--


From nobody Sat May 14 09:47:32 2016
Return-Path: 
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 35CC412B022 for ; Sat, 14 May 2016 09:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.226
X-Spam-Level: 
X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 WYx8COQ0W4xj for ; Sat, 14 May 2016 09:47:29 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 EB03812B018 for ; Sat, 14 May 2016 09:47:28 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id t10so145804316ywa.0 for ; Sat, 14 May 2016 09:47:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fE72sc0FqvxNM4s1sBgnwGicNBZ0/0hDRR0EcIbvmm4=; b=fTjOrzJ3BIjmwbaYht2wUNOi1kg4HMNzpv4BHxFkt4471i+Mla2ne2zw2WljrMexXy VIlqKiuNud397IjakrVz8O4fDWap+pue8M7Ely+23xEFk86t4ersOmDjPZTQVp+kL0li OIFP7QSvFTC5DZ4sDuu5O/SDthi4WNBq32zqQ/zcJPtYHqAkqQOF79ItSH5h1LDS51Xu OlQXE0ndqMqa2gNc7wUGkzfj9Dbe+ZF4g5IV/Nu6/sGlmFNBFlvOGuuVX3zXIpBV0Kll 57jElranVIGXxBKjv+FyLhuTtTPLTHYb+X6APj+Fm10ZPd+N3YZonH+Iv7X/8Y9TZM7k NtTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fE72sc0FqvxNM4s1sBgnwGicNBZ0/0hDRR0EcIbvmm4=; b=hfiK4ZFifdUguJruWkr/B6KFJGhUFTXy5fxxqf9BdGjC5CMoK8RTcSwClT418yyBYF z0kvILk0cIBP3YQy3fZ+raNfM+Hx1vBGAWxVqAnEJcG7J//BYOVFsl4L9nPF0Rlkg6ci wxPE1ShuUEgnvjLU0yAeyStw9sMnYzMctc35lkwRu8hMQmWhT4RDFDkRe265SK5E8kT9 5k21wMdqf1jTP9SH20BpvZarZqDgIZf/Oat3KrpSIvVLQFszneq9AwBWAq2UKLxc4R7s in23rWI5S5WW0TAuydw1nlE4h38K46UupD/G7Utosh7l7k6PW4F8HITlSB1kK6jbFPhU 3NFg==
X-Gm-Message-State: AOPr4FXyjggkRnkBtDtTBg5tV9lTxDK8/SNTtub0JaLnAqIYMJ3fAgtVNFDgtWMY6x6x1rMrSVSzA+1U9K5lbb4l
MIME-Version: 1.0
X-Received: by 10.37.34.84 with SMTP id i81mr10126356ybi.156.1463244447965; Sat, 14 May 2016 09:47:27 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Sat, 14 May 2016 09:47:27 -0700 (PDT)
In-Reply-To: 
References:  <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk>  <364acd38-cea7-c242-5cb7-9f427c4f008e@yaanatech.co.uk>   <68abb62690a54ceaa80e70bd73045db3@usma1ex-dag1mb1.msg.corp.akamai.com> <8adaaef1-f7f1-b350-cb14-88b2b9e46aef@yaanatech.co.uk> <4702f8bff0af40459f50c466f98c2e25@usma1ex-dag1mb1.msg.corp.akamai.com> <009b59bf-02a5-cc92-94dc-32f3c3a5afc9@yaanatech.co.uk> <09e4799c8c23497f843d5ea61c54202a@usma1ex-dag1mb1.msg.corp.akamai.com> 
Date: Sat, 14 May 2016 09:47:27 -0700
Message-ID: 
From: Jana Iyengar 
To: Ted Hardie 
Content-Type: multipart/alternative; boundary=001a11c113a08aefde0532d0254a
Archived-At: 
Cc: Rich Salz , "tony@yaanatech.co.uk" , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 May 2016 16:47:30 -0000

--001a11c113a08aefde0532d0254a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1.  None of this is specific to QUIC, and none of this is related to the
charter that's been proposed. I would love to see specific discussion on
the charter, so I encourage folks to read the charter and comment on it in
this or in new threads.

- jana
On May 14, 2016 9:26 AM, "Ted Hardie"  wrote:

Howdy,

This seems to have gone in a direction not directly related to the subject
"draft charter" or, indeed, to QUIC specifically.  Can I ask you gentlemen
to take the discussion to a different venue?

thanks,

Ted

On Sat, May 14, 2016 at 8:48 AM, Salz, Rich  wrote:

> Tony,
>
>
>
> Can I see drafts and failed working groups and read email and understand
> why AS/5 was picked, for example?  Cost to fully participate in IETF is
> email and Internet video, really.
>
>
>
> Any any rate, still looking for proof, rather than assertion, of IETF
> RFC=E2=80=99s that failed because of law enforcement.  Or even just waste=
d effort.
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> IM: richsalz@jabber.at Twitter: RichSalz
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--001a11c113a08aefde0532d0254a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1.=C2=A0 None of this is specific to QUIC, and none of=
 this is related to the charter that's been proposed. I would love to s=
ee specific discussion on the charter, so I encourage folks to read the cha=
rter and comment on it in this or in new threads.
- jana


On May 14, 2016 9:26 AM, "Ted Hardie" =
<ted.ietf@gmail.=
com> wrote:
<=
div>
Howdy,

This seems to have gone in a direction not dir=
ectly related to the subject "draft charter" or, indeed, to QUIC =
specifically.=C2=A0 Can I ask you gentlemen to take the discussion to a dif=
ferent venue?

thanks,

Ted

On Sat, May 14, 2016 at 8:=
48 AM, Salz, Rich <rsalz@akamai.com> wrote:











Tony,


=C2=A0


Can I see drafts and fail=
ed working groups and read email and understand why AS/5 was picked, for ex=
ample?=C2=A0 Cost to fully participate in IETF is email and Internet
 video, really.


=C2=A0


Any any rate, still looki=
ng for proof, rather than assertion, of IETF RFC=E2=80=99s that failed beca=
use of law enforcement.=C2=A0 Or even just wasted effort.


=C2=A0




--=C2=A0



Senior Architect, Akamai =
Technologies


IM: richsalz@jabber.at Twitter: RichSalz=










_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic






--001a11c113a08aefde0532d0254a--


From nobody Sat May 14 12:51:55 2016
Return-Path: 
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 CC7BF12D0F4 for ; Sat, 14 May 2016 12:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Uy6pFIGPGwHo for ; Sat, 14 May 2016 12:51:53 -0700 (PDT)
Received: from uk-www1.yaanatech.uk (uk-www1.yaanatech.uk [46.20.116.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD8C12B01F for ; Sat, 14 May 2016 12:51:52 -0700 (PDT)
Received: from [192.168.1.51] (pool-173-67-205-17.clppva.fios.verizon.net [173.67.205.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by uk-www1.yaanatech.uk (Postfix) with ESMTPSA id C68A05402C7; Sat, 14 May 2016 20:51:50 +0100 (BST)
References:  <72f38841-c9d6-a139-cf04-9e2a972eab5e@yaanatech.co.uk>  <364acd38-cea7-c242-5cb7-9f427c4f008e@yaanatech.co.uk>   <68abb62690a54ceaa80e70bd73045db3@usma1ex-dag1mb1.msg.corp.akamai.com> <8adaaef1-f7f1-b350-cb14-88b2b9e46aef@yaanatech.co.uk> <4702f8bff0af40459f50c466f98c2e25@usma1ex-dag1mb1.msg.corp.akamai.com> <009b59bf-02a5-cc92-94dc-32f3c3a5afc9@yaanatech.co.uk> <09e4799c8c23497f843d5ea61c54202a@usma1ex-dag1mb1.msg.corp.akamai.com> 
To: Ted Hardie , "Salz, Rich" 
From: Tony Rutkowski 
Organization: Yaana Ltd
Message-ID: 
Date: Sat, 14 May 2016 15:51:49 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C88A5ABC8EE168A7EF1F5AE9"
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: tony@yaanatech.co.uk
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 May 2016 19:51:54 -0000

This is a multi-part message in MIME format.
--------------C88A5ABC8EE168A7EF1F5AE9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

No need.  Did due diligence.
Swap those T-Shirts for ones
that read "Encryption everywhere" :-)

On 2016-05-14 12:25 PM, Ted Hardie wrote:
> indeed, to QUIC specifically.  Can I ask you gentlemen to take the 
> discussion to a different venue?


--------------C88A5ABC8EE168A7EF1F5AE9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    No need.  Did due diligence.

    Swap those T-Shirts for ones

    that read "Encryption everywhere" :-)

    

    
On 2016-05-14 12:25 PM, Ted Hardie
      wrote:

    

    
indeed, to QUIC specifically.  Can I ask you gentlemen
      to take the discussion to a different venue?

    

    

  


--------------C88A5ABC8EE168A7EF1F5AE9--


From nobody Sun May 15 02:08:44 2016
Return-Path: 
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 94BAB12D13A for ; Sun, 15 May 2016 02:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 N76DXNGRvUok for ; Sun, 15 May 2016 02:08:42 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 A70F112D12C for ; Sun, 15 May 2016 02:08:41 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id n129so68279581wmn.1 for ; Sun, 15 May 2016 02:08:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=4nMN4wKMZbAlr8nHVLcjulkZDXYxvcovaYGzWm6YyF8=; b=E8gQfGJjoMMm7u1GDiWY96Px095m9ncG1WZ3AA3lox3jGYa6KE59dpWu6vue91JiZK knh6ciEwnyYShQOq+ntmdc7eeTzAjIsAe9ltzX9zHckg/tjB73iTW60ViW7f+R693xFg MYZ8kpNqSui0RJ24OX7+Oq5fUJcaba5Ph2/zIj0fternA/lxRlbiVR0C/oJfqwlQz4Jq hpi5ILR1d3OWsyQm+r7RzR0vFWTqksTDG/AOSvOgwYIPMyqzRC6OpgaY+QrkMDFsUujg WdW2FeXmSCymeV6Tkm4VfyfMQ03ZXOMlboMYX2FoodmejirnQHuEuWCNo8VLXsig1DNY ke5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4nMN4wKMZbAlr8nHVLcjulkZDXYxvcovaYGzWm6YyF8=; b=EILS4qap+BgqbNGphikY1L9NJMPbiH4gL626KuLkDeq6yXJPi/SDKRy/NLM6XVcUX5 feUSDZBXiwcYg0SE10oAaZ10ZjvcS7RiMyP3Lz2NbiBvGZMYuB3VCTBiGzlywHJAs6tD fQWBXr7Nm0QqTIHfz2jwibko31dB2/mWao3pK8c5kygsyP/hcZze+YMUZwIP08X4dPev 3KJJoHsVCp0cC9P29QzJvovaqUrPEkSc+E90AcNtTL/H29xrOftWqABA/AnlEjl8iRg8 DyMFjRXvKZSJ0YkAB+zSKf8VrUwjfBZcair7PWCseD0M17l/tG/50mAIhqgqBc55S+fI LOKQ==
X-Gm-Message-State: AOPr4FWLwd8hbN0e45WRiMGEwQr2+s0CM57pesUPgaybYXwO5Zlem3dul6ZBusodPfUW2Q==
X-Received: by 10.28.142.82 with SMTP id q79mr12648334wmd.88.1463303319932; Sun, 15 May 2016 02:08:39 -0700 (PDT)
Received: from [172.24.249.66] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id i3sm27639278wjx.30.2016.05.15.02.08.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 15 May 2016 02:08:39 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_19954324-A136-4819-8ED9-254EE3EC5813"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir 
In-Reply-To: 
Date: Sun, 15 May 2016 12:08:36 +0300
Message-Id: <31BA99B2-F557-4CF4-8F6F-A006703CF664@gmail.com>
References: 
To: Ted Hardie 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , quic@ietf.org, Christian Huitema 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 May 2016 09:08:43 -0000

--Apple-Mail=_19954324-A136-4819-8ED9-254EE3EC5813
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, Ted

The charter looks OK, except that the term =E2=80=9Cquic=E2=80=9D is =
used for the Google experiment (=E2=80=9CThere is emerging =
implementation and deployment experience with QUIC=E2=80=9D), the =
protocol described in the initial set of drafts, and the output of the =
working group. The phrase =E2=80=9Ca standards track specification =
generalizing the design described in the initial set=E2=80=9D seems to =
limit the amount of change control the working group will have.

I think it would be better for the charter to read like many others =
along the lines of =E2=80=9Cthe WG will specify a standards-track =
protocol with these drafts as starting points and based on =
implementation and deployment experiments with UDP-based Google =
experiment.=E2=80=9D

Just so long as it=E2=80=99s clear that the WG has change control.

Yoav

> On 14 May 2016, at 2:26 AM, Ted Hardie  wrote:
>=20
> Howdy,
>=20
> As part of the BoF preparation, we put together a stab at a draft =
charter.  It's available as html and markdown on github at:
>=20
> https://github.com/IETF-QUIC/Charter =

>=20
> I've attached the HTML version as well. =20
>=20
> It would be great to have some of the discussion on the list before =
the BoF.  Comments to the list or issues/pull requests at the github =
repo are welcome.  We will periodically reflect any issues or suggestion =
from the Repo back to the list, but this will be manual, so expect some =
lag.
>=20
> regards,
>=20
> Ted
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic


--Apple-Mail=_19954324-A136-4819-8ED9-254EE3EC5813
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi, Ted

The=
 charter looks OK, except that the term =E2=80=9Cquic=E2=80=9D is used =
for the Google experiment (=E2=80=9CThere is emerging implementation and =
deployment experience with QUIC=E2=80=9D), the protocol described in the =
initial set of drafts, and the output of the working group. The phrase =
=E2=80=9Ca standards track specification generalizing the design =
described in the initial set=E2=80=9D seems to limit the amount of =
change control the working group will have.

I think it would be better for the =
charter to read like many others along the lines of =E2=80=9Cthe WG will =
specify a standards-track protocol with these drafts as starting points =
and based on implementation and deployment experiments with UDP-based =
Google experiment.=E2=80=9D

Just so long as it=E2=80=99s clear that the WG has change =
control.

Yoav

On 14 May 2016, at 2:26 AM, Ted =
Hardie <ted.ietf@gmail.com> wrote:

Howdy,

As part of the BoF =
preparation, we put together a stab at a draft charter.  It's =
available as html and markdown on github at:

https://github.com/IETF-QUIC/Charter

I've attached the HTML version as well.  

It would be great to =
have some of the discussion on the list before the BoF.  Comments =
to the list or issues/pull requests at the github repo are=20
welcome.  We will periodically reflect any issues or suggestion =
from the
 Repo back to the list, but this will be manual, so expect some =
lag.

regards,

Ted

<quic-charter.html><=
/span>_______________________________________________
QUIC =
mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

=

--Apple-Mail=_19954324-A136-4819-8ED9-254EE3EC5813--


From nobody Sun May 15 03:00:46 2016
Return-Path: 
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 7A61812D14D for ; Sun, 15 May 2016 03:00:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 YTmL98C1FmI7 for ; Sun, 15 May 2016 03:00:44 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087EE12D136 for ; Sun, 15 May 2016 03:00:43 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-ad-573848c914c7
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 70.1F.12516.9C848375; Sun, 15 May 2016 12:00:41 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Sun, 15 May 2016 12:00:41 +0200
From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= 
To: Ted Hardie , "quic@ietf.org" , "Jana Iyengar" , Christian Huitema 
Thread-Topic: Scope of multi-path WAS: Re: [QUIC] Draft charter
Thread-Index: AQHRrpCjbPTWKtI0i0yp4QlLaSxH8A==
Date: Sun, 15 May 2016 10:00:41 +0000
Message-ID: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.3.160329
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="utf-8"
Content-ID: <90CDF234C2FD004C87F9080290BC6C6B@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2J7oO5JD4twg+ufzSyaPvcxWkw6upDF omcBt0XjXDsHFo+ds+6yeyzYVOqxZMlPJo/WHX/ZA1iiuGxSUnMyy1KL9O0SuDK6Dn1mLTjG VvH7a0wD4wa2LkZODgkBE4nFPROhbDGJC/fWg9lCAkcYJV79y+ti5AKylzBKfOv/yAiSYBPw lmhrOcwCkhARmMQosXrzKbAOYQEriaYfs9lBbBEBe4mDlz4xQdh6En9/XACzWQRUJZbO+wBm 8wpYS6ybcJ8ZxGYUkJW4//0eC4jNLCAucevJfCaIiwQkluw5zwxhi0q8fPyPFcQWBZq578V5 Roi4kkTjkidAcQ6gXk2J9bv0IcZYSyw6cIkNwlaUmNL9kB1iraDEyZlPWCYwis5Csm0WQvcs JN2zkHTPQtK9gJF1FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgdB3c8lt3B+Pq146HGAU4 GJV4eBVumIcLsSaWFVfmHmKU4GBWEuHd4W4RLsSbklhZlVqUH19UmpNafIhRmoNFSZzX/6Vi uJBAemJJanZqakFqEUyWiYNTqoHRqu3JEz1/o8Uhrw9r2bnxP2Tfv/VW6GP/pP3Kje/W+9Xv m5Yr/W2K6qYInYQSw7JDigzVV+SzHh+qdDR4LPQv5+y9rjUqHb6LYqpc6+pqvnNtzI+7kPd/ O7dt9VcezYAV+zPdNmSvvmjsyxGXayyx7/LSrNxMvd9aCkf/z/6xUymZb5pnPo8SS3FGoqEW c1FxIgDKg25sqgIAAA==
Archived-At: 
Subject: [QUIC] Scope of multi-path WAS: Re:  Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 May 2016 10:00:45 -0000

Pg0KPg0KPg0KPg0KPkl0IHdvdWxkIGJlIGdyZWF0IHRvIGhhdmUgc29tZSBvZiB0aGUgZGlzY3Vz
c2lvbiBvbiB0aGUgbGlzdCBiZWZvcmUgdGhlDQo+Qm9GLiAgDQoNCg0KSGkhDQoNCkhhdmUgYSBx
dWVzdGlvbiBjb25jZXJuaW5nIHRoZSBzY29wZSBvZiDigJxtdWx0aS1wYXRo4oCdIHdvcms6DQoN
ClRoZSBmdWxsIGFyZWEgb2YgbXVsdGktcGF0aCBpcyByYXRoZXIgYmlnLCBlc3BlY2lhbGx5IGlm
IGNvbWJpbmVkIHdpdGgNCm1vYmlsaXR5IGFuZCB0aGUgcG9zc2liaWxpdHkgdG8gbWlncmF0ZSBz
b21lIGJ1dCBub3QgYWxsIGZsb3dzIHRoZQ0K4oCcYXBwbGljYXRpb27igJ0gdXNpbmcgYSDigJxy
aWNoIEFQSeKAnSB0byBwcm92aWRlIGhpbnRzIHRvIHRoZSB0cmFuc3BvcnQgbWlkZGxlDQp3YXJl
Lg0KDQpUaGUgY3VycmVudCBjaGFydGVyIHRleHQgaXMgbm90IHNvIHByZWNpc2Ugb24gdGhlIHNj
b3BlIGFuZCBhbWJpdGlvbiBvbg0KbXVsdGktcGF0aC4NCg0KSXMgdGhlIHNjb3BlIHBlcmhhcHMg
aW1wbGljaXRseSBsaW1pdGVkIHRvIGV4aXN0aW5nIG11bHRpLXBhdGggVENQDQpyZWFsaXNhdGlv
bi91c2FnZT8NCg0KUmVnYXJkcw0KR8O2cmFuDQoNCg0KDQo+DQoNCg==


From nobody Sun May 15 06:36:03 2016
Return-Path: 
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 0C2A712D0D1 for ; Sun, 15 May 2016 06:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.346
X-Spam-Level: 
X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 apBCXTi1mRqf for ; Sun, 15 May 2016 06:36:01 -0700 (PDT)
Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7F412D0C6 for ; Sun, 15 May 2016 06:36:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,623,1455004800";  d="asc'?scan'208,217";a="111132588"
Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx142-out.netapp.com with ESMTP; 15 May 2016 06:35:45 -0700
Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Sun, 15 May 2016 06:35:40 -0700
Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::7db0:a96:265e:db5e%21]) with mapi id 15.00.1156.000; Sun, 15 May 2016 06:35:40 -0700
From: "Eggert, Lars" 
To: Ted Hardie 
Thread-Topic: [QUIC] Draft charter
Thread-Index: AQHRrXAI6oEcIjNVN0WYu0h+61KYqZ+6d9OA
Date: Sun, 15 May 2016 13:35:40 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3124)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.120.60.36]
Content-Type: multipart/signed; boundary="Apple-Mail=_3702A8F7-960B-4C7E-A073-DCB04139BAE1"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: 
Cc: Jana Iyengar , "quic@ietf.org" , Christian Huitema 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 May 2016 13:36:03 -0000

--Apple-Mail=_3702A8F7-960B-4C7E-A073-DCB04139BAE1
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6F050F3F-0469-4EC6-932A-C731B9E0B330"


--Apple-Mail=_6F050F3F-0469-4EC6-932A-C731B9E0B330
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 2016-05-14, at 1:26, Ted Hardie  wrote:
> As part of the BoF preparation, we put together a stab at a draft =
charter.  It's available as html and markdown on github at:
>=20
> https://github.com/IETF-QUIC/Charter =


This is one of the better charters for new work I've read - good to go =
IMO.

Lars

--Apple-Mail=_6F050F3F-0469-4EC6-932A-C731B9E0B330
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

On 2016-05-14, at 1:26, Ted Hardie <ted.ietf@gmail.com> wrote:
As part of the BoF preparation, we put together a stab at a draft charter.  It's available as html and markdown on github at:

This is one of the better charters for new work I've read - good to go IMO.

Lars

--Apple-Mail=_6F050F3F-0469-4EC6-932A-C731B9E0B330--

--Apple-Mail=_3702A8F7-960B-4C7E-A073-DCB04139BAE1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXOHswAAoJEFS1wwm/cMFX2mgP/0cL6V31gVaty1iQMriSC1/d
svbi/0GTWMvmwkMa6vf4vDkH9YEY/qzQtE4ZvTZO/5ak4s60bEKgnBwRd7pJEPJ6
+jlhkcHVWZmbUGDnNHiSusnsSXpqCvAgoprNmwSI2hxrj4G3bK2FGgOv0k0mAHO/
vJFsa2xHBDfgkDLzpMhOri4fpJ7KlQmcW2sD929BNyEhEPt39HJ9N53JGxG7bSif
WXUHt6CZlJIHiM/VRIigj7QC09Pq6bCwFl0mo0bp0UiaTtUSDkb61RcBH4iENvDc
mALE5Cg0xASlZk6IJoFXSzh56RQ1RtdJXMrBgYJmm+u1YI9NaJP/85fJWn+yEyBz
Uar7LTusfMPyaGSVcw91NqmBH+0/u2jbysdEoWLDRat/0RI++gMkX7xHZlVstyS9
2UqewYpa058ZIxcCn7H+y0e0yebJ+1bPOBmt067GkOR/3mY4cPmSb+Cz61AItOIz
ExNWTkTvIaowc/XYFkDV0DG0gqqDF1k36sE3sdWi3RuYmwaf3Np+ndUs62RcuOmF
kGHUIxwlSQYqgv6wG+UbfaC7t2kQdaVIvOPwJLgEPc5b9M0LhoYPHSvXQlSzJ9uf
UQ4IDJKOdOUKBM1tUTio7To0CWLkJTY/eIljV6uzCvwEwI8VdX3ZSEAxt+HfPPeU
krwUPoh6wPXs4PNG7lrn
=BQh0
-----END PGP SIGNATURE-----

--Apple-Mail=_3702A8F7-960B-4C7E-A073-DCB04139BAE1--


From nobody Sun May 15 09:18:28 2016
Return-Path: 
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 0340D12B01B for ; Sun, 15 May 2016 09:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 T4mC6o0XKIrS for ; Sun, 15 May 2016 09:18:24 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 C6E7912B01A for ; Sun, 15 May 2016 09:18:23 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id x19so237334307oix.2 for ; Sun, 15 May 2016 09:18:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hx8WwXoxHmL41ryPLBY8ImVHISfllQrWmMKAd/b/3wQ=; b=wa8YbZO0l3Ruek4NDsRk+2HXQZAtSnOO6WQJM25vY8PoDlv5qmxTzJ6a8iAhD4/3ZN SYcTum2EhN780WFX69sisOL6/L2OGb1V1E9mprALXXUM7kIPYRpBHRvIL2EfXLP6WOk6 hu3sbglIOTHH9YOJLbt/tkK05ZlXHlDEhlWiNqlXWZYGcoCgfDGZXw6Snv1OHGXKTXf8 2mmVr+yGlseWBbIzyI91KjXsRjYMWjwQmODyRGHzpF5dMDJHAGVpN1i86V5kb7sKhgTD AGTIUQ/+MzfOTi9FWYSRf/sGUqD6CvmSDxVGuReqeah4ppkF6kQYrnyuMVVhD0oB16Yr qbCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hx8WwXoxHmL41ryPLBY8ImVHISfllQrWmMKAd/b/3wQ=; b=BfoYgSucofIR/IHzEinxTBKg979ugFEaD66fn5tI84BbGfnghyzAvT/16NJMylGE7/ mQI8FtJtUbdEGLaptCimPeRz4+n3QVkmkKMf5iSG2vF5SNbJkQPcpfgjRwb/07gQfcsF itEoEU8ILMVYBgZjb86EfTHUhD4/Xee6Hwar7ZRl+LQKJkGkF0/O3YU336gfKESNzFcv KFPjFD4arXeLYuKy2sAdVr8u2hpY7i8YmUi2a8Y4PoxRv812kMcOIkI6QzLFhj+eIxSn EOiDt+1bPRfCg8zMz3GZGGTBz3pZRh8vHRn6KFGOm1W8c05NK//r+yi9gMVuEHwzTyfq YFRQ==
X-Gm-Message-State: AOPr4FVOOL0KYZg2/h/21gzCguDrI6dWgTwMtx4VUFZHIfTB1zjQi9R1/SDYwWDNeqMPINIp8I5K2RNQtUiL/g==
X-Received: by 10.202.75.82 with SMTP id y79mr12404152oia.71.1463329103240; Sun, 15 May 2016 09:18:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.213.210 with HTTP; Sun, 15 May 2016 09:18:03 -0700 (PDT)
In-Reply-To: <31BA99B2-F557-4CF4-8F6F-A006703CF664@gmail.com>
References:  <31BA99B2-F557-4CF4-8F6F-A006703CF664@gmail.com>
From: Ted Hardie 
Date: Sun, 15 May 2016 09:18:03 -0700
Message-ID: 
To: Yoav Nir 
Content-Type: multipart/alternative; boundary=001a11c173f66364830532e3db6e
Archived-At: 
Cc: Jana Iyengar , quic@ietf.org, Christian Huitema 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 May 2016 16:18:26 -0000

--001a11c173f66364830532e3db6e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Yoav,

On Sun, May 15, 2016 at 2:08 AM, Yoav Nir  wrote:

> Hi, Ted
>
> The charter looks OK, except that the term =E2=80=9Cquic=E2=80=9D is used=
 for the Google
> experiment (=E2=80=9CThere is emerging implementation and deployment expe=
rience
> with QUIC=E2=80=9D), the protocol described in the initial set of drafts,=
 and the
> output of the working group. The phrase =E2=80=9Ca standards track specif=
ication
> generalizing the design described in the initial set=E2=80=9D seems to li=
mit the
> amount of change control the working group will have.
>
> That's not the intent--the change control will shift to the working group
as normal.  We tried to capture that with this language:

"Note that consensus is required both for changes to the current protocol
mechanisms and retention of current mechanisms. In particular, because
something is in the initial document set does not imply that there is
consensus around the feature or around how it is specified."

That's taken from how the HTTPbis work handled the input documents to
HTTP/2.

I think it would be better for the charter to read like many others along
> the lines of =E2=80=9Cthe WG will specify a standards-track protocol with=
 these
> drafts as starting points and based on implementation and deployment
> experiments with UDP-based Google experiment.=E2=80=9D
>
> If you are okay with "these drafts" being a bit of a moving target, I
think something like this would be okay, modulo the "Google" above.  Lots
of other folks have worked with quic and contributed.  Would this language
work:

"The Working group will specify a standards-track protocol based on drafts
derived from the implementation and deployment experiments of pre-standard
QUIC."?

regards,

Ted



> Just so long as it=E2=80=99s clear that the WG has change control.
>
> Yoav
>
> On 14 May 2016, at 2:26 AM, Ted Hardie  wrote:
>
> Howdy,
>
> As part of the BoF preparation, we put together a stab at a draft
> charter.  It's available as html and markdown on github at:
>
> https://github.com/IETF-QUIC/Charter
>
> I've attached the HTML version as well.
>
> It would be great to have some of the discussion on the list before the
> BoF.  Comments to the list or issues/pull requests at the github repo are
> welcome.  We will periodically reflect any issues or suggestion from the
> Repo back to the list, but this will be manual, so expect some lag.
>
> regards,
>
> Ted
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>
>

--001a11c173f66364830532e3db6e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Yoav,

On Sun, May 15, 2016 at 2:08 AM, Yoav Nir <ynir.ietf@gm=
ail.com> wrote:
Hi, Ted

The =
charter looks OK, except that the term =E2=80=9Cquic=E2=80=9D is used for t=
he Google experiment (=E2=80=9CThere is emerging implementation and deploym=
ent experience with QUIC=E2=80=9D), the protocol described in the initial s=
et of drafts, and the output of the working group. The phrase =E2=80=9Ca st=
andards track specification generalizing the design described in the initia=
l set=E2=80=9D seems to limit the amount of change control the working grou=
p will have.

That's not the=
 intent--the change control will shift to the working group as normal.=C2=
=A0 We tried to capture that with this language:

"Note that con=
sensus is required both for changes to the current=20
protocol mechanisms and retention of current mechanisms. In particular,=20
because something is in the initial document set does not imply that=20
there is consensus around the feature or around how it is specified."<=
br>
That's taken from how the HTTPbis work handled the in=
put documents to HTTP/2.

I think it would be better for the charter to read like many others along =
the lines of =E2=80=9Cthe WG will specify a standards-track protocol with t=
hese drafts as starting points and based on implementation and deployment e=
xperiments with UDP-based Google experiment.=E2=80=9D

<=
/div>
If you are okay with "these drafts" being =
a bit of a moving target, I think something like this would be okay, modulo=
 the "Google" above.=C2=A0 Lots of other folks have worked with q=
uic and contributed.=C2=A0 Would this language work:

&quo=
t;The Working group will specify a standards-track protocol based on drafts=
 derived from the implementation and deployment experiments of pre-standard=
 QUIC."?

regards,

Ted

=C2=A0
Just so long as it=E2=80=99s c=
lear that the WG has change control.

Yoav

On 14 May =
2016, at 2:26 AM, Ted Hardie <ted.ietf@gmail.com> wrote:

<=
div>
Howdy,

As part of the BoF preparation, we put together a stab at a draft chart=
er.=C2=A0 It's available as html and markdown on github at:

https://gith=
ub.com/IETF-QUIC/Charter

I've attached the HTML versio=
n as well.=C2=A0 

It would be great to have some of the d=
iscussion on the list before the BoF.=C2=A0 Comments to the list or issues/=
pull requests at the github repo are=20
welcome.=C2=A0 We will periodically reflect any issues or suggestion from t=
he
 Repo back to the list, but this will be manual, so expect some lag.
<=
div>
regards,

Ted


<quic-charter.html>_________________________=
______________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf=
.org/mailman/listinfo/quic




--001a11c173f66364830532e3db6e--


From nobody Sun May 15 09:43:01 2016
Return-Path: 
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 C8B8412D11B for ; Sun, 15 May 2016 09:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 0KJV8vze31Ar for ; Sun, 15 May 2016 09:42:58 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 3145B12D0F6 for ; Sun, 15 May 2016 09:42:57 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id 190so185803576iow.1 for ; Sun, 15 May 2016 09:42:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=NsNyVbzlC3ZGsHJMGZqsX69TBRVNOjLeiHo/tEz3b0A=; b=GYpnpS2qov4sEWeobFzF9eXOIOhlNLR9t1hqxPphKRWjjxfCHuN0JCtCraSY0HtCic Dey3LoyuKzpn+Y42x5tBVfHa+u7jO5kWlTgI/Ofilk5W8K5O1+UMIRB6UTkulZQoETz4 FNW8VNl/shuV4VfrHiY2oucvFcZzUs9ktzXCBIFVhyO6ZMPme+8vTsCgKQLOK2hHYe97 PEp1p1AtOpqsakddUMDulaESqOC8MiFBJjh6Hy16b19E8yTDF31SGTW2r7c9jzkhEBg6 5gGHwvQRx57LT77J1PbEQe+pDA5PAe1xn49BJPa7v+debj9fF/KLw5IFjezY+buSQO/i 9mRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NsNyVbzlC3ZGsHJMGZqsX69TBRVNOjLeiHo/tEz3b0A=; b=A5ckpGMPlL6s9vRUyd7lG6JKk7jheu9T4U3Sd/0nkNgC7xjcGi+Z3AlUAj1DuWKLmp SEMBCHFwS0NZsEDV1Akt15fBJB7UZe8IBH41/LpRhWLo691KSrP0w/kR4Rs7OLgj1orZ ZmofJ0WEJEsGlRZY4ByBJAqV+Vrwzesibf0FJVTpvnTSFKRqFMoTJZ9zZPYgPftNBXyo kyTQzQjV/+2cnmtU/wSgwJHMrEcQIPWAg3AVxXqLDhOre+MLyhO1wbip2d2gqJYWPX6z 8VyqDILecCNeS9+Nwzqqbf2xw2mu8Xg/23N7SDywVNec450IqGbqNqTbeVrgV6U/5WHV nHkg==
X-Gm-Message-State: AOPr4FUQBXQ9iqAadWAIhMxcOZBAR4FFjqUQ2Uvwpk3paxK5pvHsSHq5WEsvpYyoDhC/IdIso5sfGHKl/q8Hqg==
MIME-Version: 1.0
X-Received: by 10.107.136.76 with SMTP id k73mr17803370iod.100.1463330577359;  Sun, 15 May 2016 09:42:57 -0700 (PDT)
Received: by 10.36.43.82 with HTTP; Sun, 15 May 2016 09:42:57 -0700 (PDT)
In-Reply-To: 
References: 
Date: Sun, 15 May 2016 12:42:57 -0400
Message-ID: 
From: Martin Thomson 
To: Ted Hardie 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Jana Iyengar , quic@ietf.org, Christian Huitema 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 May 2016 16:43:00 -0000

On 13 May 2016 at 19:26, Ted Hardie  wrote:
> https://github.com/IETF-QUIC/Charter

As Lars says, this is pretty good.

I think that the first and second parts are the essential pieces to
concentrate on at this moment.  While I also want to do multipath and
FEC, I don't believe that we are ready enough yet to commit to doing
something with FEC.  A rechartering when that time comes should not be
hard and a smaller scope helps maintain focus.

If you reduce part 4 to a note saying that the group might recharter
to add these capabilities, then that gives you more space to expand on
part 1, which I think is lacking in detail.

--

This list in part 1 raises quite a few questions for me:

"connection establishment, stream multiplexing, data reliability, loss
detection and recovery, congestion control, and negotiation"

How is data reliability different to loss detection and recovery?

Are we talking about adding features like SCTP has with respect to
partial reliability?  HTTP doesn't need it, but I've heard of grand
plans to do real-time media over this abstraction.  Framing of that in
the charter is probably much harder than the actual technical work
needed to define such things.

What, if any, effort is this group going to put into defining a
congestion control mechanism as opposed to just picking one (or more)
existing mechanisms?  Can we push this more toward just picking
something, maybe allowing for a few tweaks?

And what is being negotiated?

--

I would recommend removing or reducing the following statement: "It
will also provide a threat model description specific to connection
resumption, along with a description for denial-of-service
mitigations."  The threat model should be a little more comprehensive
than just resumption, but we have a great deal of analysis for
existing and similar protocols.  It's unclear what additional work
would be required, and it might be the case that we don't want to
write that all down. Moreover, this implies a narrower scope than
necessary.

The denial of service aspects are important, but do we really need to
write those into a charter?  I notice that we aren't writing down
operational concerns, which are also considerable.


From nobody Sun May 15 11:21:22 2016
Return-Path: 
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 83F0A12D523 for ; Sun, 15 May 2016 11:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 4-UEMYCU7OQT for ; Sun, 15 May 2016 11:21:20 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 B70B912D0AF for ; Sun, 15 May 2016 11:21:19 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id n129so77432681wmn.1 for ; Sun, 15 May 2016 11:21:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=vbf0DAab5sMxsRGUfY4WljCq0XyxMXmPqxIu8s8JTeE=; b=MfS46nzaAhVxdxf5XWuzC6BK7fUDfPlIrRf7SPpuVr+DaB+9uvDA6iW4vamFdthrl/ ifZ+Y0nKaEwhlgwWD3X5YSdR3mM7f7TxTuJX8PJt3+5QyEVF9D5hZGdgedG2LeINa2VK NsK7qSG9EEIxg3Z+8D9TquRZQxedms08Xpd3pnj8wSAMMCXA9EZmlPZin268SYfifD76 +5ToKDXnrU7WyEQs3suj6psyiJ+YQSxskouWMFauP8GhVBEeg6DyZTDVecg7vwuWKJbc TQJOoq9lpI/vV7BBy+7LdDTOPWp+DMeFyIA4Zd4SEMKQJoL2G1LjjzC1eYNUlb4wUn+5 p8Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vbf0DAab5sMxsRGUfY4WljCq0XyxMXmPqxIu8s8JTeE=; b=c5kE2Z9fl9FbCrC0LbqYxs6jGUECUyKxyU3QazX+gQ6VNnfAXfv0wB/RzDXO4GEjOO 7T8/9IIryLZvCH6ust5yyg4T15wlgBuFa04PA//xCkn1USpFQ9TO2bkY8tnnsXWfHHA0 axF56Fd4uAxzi0ij4qW1N7J+B67TDGGRelarScR60LUfiO+zCBHrb2cyrECh+MuZM0dE JHtRQbinbXP7BWcWOfCvaexGCTbHNeGmt5YFjfWMTdyGxhRqBqtVtD1lgs+uVim7rCPv IknboDxjCR/9LHytSJOuDsen4qYwbAwn/kXX7mV5RYOhDE2ptm9x/i66cRGklwWJxC5O W2eQ==
X-Gm-Message-State: AOPr4FW/Fx2Yj0cBMD2ImGWYrnDXLhxFyulgUzzeeoN5F8uFwSJnnFGmhskuDLOgP1D/hA==
X-Received: by 10.194.123.67 with SMTP id ly3mr25666342wjb.135.1463336478123;  Sun, 15 May 2016 11:21:18 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id e16sm14380157wmc.3.2016.05.15.11.21.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 15 May 2016 11:21:17 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_941F74B5-1E96-47EF-A3A7-64DC12F55DA5"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir 
In-Reply-To: 
Date: Sun, 15 May 2016 21:21:14 +0300
Message-Id: <83E3D82D-1291-45F6-AD0C-EFA704175886@gmail.com>
References:  <31BA99B2-F557-4CF4-8F6F-A006703CF664@gmail.com> 
To: Ted Hardie 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , quic@ietf.org, Christian Huitema 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 May 2016 18:21:21 -0000

--Apple-Mail=_941F74B5-1E96-47EF-A3A7-64DC12F55DA5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 15 May 2016, at 7:18 PM, Ted Hardie  wrote:
>=20
> Hi Yoav,
>=20
> On Sun, May 15, 2016 at 2:08 AM, Yoav Nir > wrote:
> Hi, Ted
>=20
> The charter looks OK, except that the term =E2=80=9Cquic=E2=80=9D is =
used for the Google experiment (=E2=80=9CThere is emerging =
implementation and deployment experience with QUIC=E2=80=9D), the =
protocol described in the initial set of drafts, and the output of the =
working group. The phrase =E2=80=9Ca standards track specification =
generalizing the design described in the initial set=E2=80=9D seems to =
limit the amount of change control the working group will have.
>=20
> That's not the intent--the change control will shift to the working =
group as normal.  We tried to capture that with this language:
>=20
> "Note that consensus is required both for changes to the current =
protocol mechanisms and retention of current mechanisms. In particular, =
because something is in the initial document set does not imply that =
there is consensus around the feature or around how it is specified."
>=20
> That's taken from how the HTTPbis work handled the input documents to =
HTTP/2.

That=E2=80=99s fine. I think what=E2=80=99s bothering me is that the =
experiment, the (potential) working group and the output product are all =
called the same thing.  In HTTPbis it was clearer that SPDY was the =
experiment and HTTP/2 was the output.

But with that clarification, it seems ready-to-go to me as well, though =
I agree with Martin that we don=E2=80=99t need to spell out specific =
security considerations like DoS in the charter.

Yoav



--Apple-Mail=_941F74B5-1E96-47EF-A3A7-64DC12F55DA5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On 15 May 2016, at 7:18 PM, Ted Hardie <ted.ietf@gmail.com> =
wrote:

Hi Yoav,

On Sun, =
May 15, 2016 at 2:08 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi, Ted

The charter looks OK, except that the =
term =E2=80=9Cquic=E2=80=9D is used for the Google experiment (=E2=80=9CTh=
ere is emerging implementation and deployment experience with QUIC=E2=80=9D=
), the protocol described in the initial set of drafts, and the output =
of the working group. The phrase =E2=80=9Ca standards track =
specification generalizing the design described in the initial set=E2=80=9D=
 seems to limit the amount of change control the working group will =
have.

That's not the intent--the change control will shift to the =
working group as normal.  We tried to capture that with this =
language:

"Note that consensus is required =
both for changes to the current=20
protocol mechanisms and retention of current mechanisms. In particular,=20=

because something is in the initial document set does not imply that=20
there is consensus around the feature or around how it is specified."

That's taken from how =
the HTTPbis work handled the input documents to HTTP/2.

That=E2=80=99s fine. I think what=E2=80=99s =
bothering me is that the experiment, the (potential) working group and =
the output product are all called the same thing.  In HTTPbis it =
was clearer that SPDY was the experiment and HTTP/2 was the =
output.

But with that clarification, =
it seems ready-to-go to me as well, though I agree with Martin that we =
don=E2=80=99t need to spell out specific security considerations like =
DoS in the charter.

Yoav

=

--Apple-Mail=_941F74B5-1E96-47EF-A3A7-64DC12F55DA5--


From nobody Sun May 15 12:32:58 2016
Return-Path: 
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 F179212D1C9 for ; Sun, 15 May 2016 12:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 t79KNyakzzfZ for ; Sun, 15 May 2016 12:32:54 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FF312D1AC for ; Sun, 15 May 2016 12:32:53 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-f1-5738cee3dd6f
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 20.E3.12926.4EEC8375; Sun, 15 May 2016 21:32:52 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.166]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Sun, 15 May 2016 21:32:51 +0200
From: Salvatore Loreto 
To: Ted Hardie , "quic@ietf.org" , "Jana Iyengar" , Christian Huitema 
Thread-Topic: [QUIC] Draft charter
Thread-Index: AQHRrXALHarJ2uenb0CbuK/2CiPGXZ+6YoJw
Date: Sun, 15 May 2016 19:32:50 +0000
Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_2B9B48179856DC4FA00C93C79EB7E64A60D94ED9ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7je6TcxbhBncv81o0fe5jtJh0dCGL Rc8CbovGuXYOLB47Z91l91iwqdRjyZKfTB6tO/6yB7BEcdmkpOZklqUW6dslcGW0LrvCXvAq oGLKtDNMDYxn/LoYOTkkBEwkpk/pZYewxSQu3FvP1sXIxSEkcIRRYtPCpYwQzhJGieeLvoJV sQmYSTx/uIUZJCEiMIlRYvXmU2wgCWEBRYkV5w4ygdgiAkoSq65cY4OwjSSmXHkPFmcRUJVY +fkzaxcjBwevgK9E8/kSkLCQQIBEz9k/zCA2p0CgxMsT81lAbEagi76fWgPWyiwgLnHryXwm iEsFJJbsOc8MYYtKvHz8jxXCVpJYe3g7C0R9vsTb5kNgNq+AoMTJmU9YJjCKzEIyahaSsllI ymYBXccsoCmxfpc+RImixJTuh+wQtoZE65y57MjiCxjZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp 5aWWbGIERt7BLb9VdzBefuN4iFGAg1GJh1fhhnm4EGtiWXFl7iFGCQ5mJRHe3NMW4UK8KYmV ValF+fFFpTmpxYcYpTlYlMR5/V8qhgsJpCeWpGanphakFsFkmTg4pRoYc5s0p1Q+Vzj4436R x79NWg+m8/Jd+vf6wq+TjVfWXgm+u5ThemzPM+41j7KNl/BYM9QLqp2I3d/QJVd1/8V68bsq OZ1t996ZxDyWLlu2VOlD1Y3Cfys8N0ZdZ1Mq0DCdrPrr1wZB2/d3r52SfXrjyietC7Fqk9rX 7U6Xzb/4uHPmURXjpNzzCUosxRmJhlrMRcWJALbhZl24AgAA
Archived-At: 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 May 2016 19:32:56 -0000

--_000_2B9B48179856DC4FA00C93C79EB7E64A60D94ED9ESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgVGVkDQoNCkkgdGhpbmtzIHRoZSBjaGFydGVyIGxvb2tzIE9LLA0KSG93ZXZlciBJIHRlbmQg
dG8gYWdyZWUgd2l0aCBwcmV2aW91cyBjb21tZW50cw0KdGhhdCB0aGUgd29yayBhdCBtb21lbnQg
c2hvdWxkIHJlYWxseSBmb2N1c2VkIG9uIChuYXJyb3dlZCB0bykgdGhlIGZpcnN0IGFuZCBzZWNv
bmQgcGFydHMgdG8gdGhlIGRlc2lnbiBvZiBRVUlDIGFzIHRyYW5zcG9ydCBwcm90b2NvbA0KDQpm
b3IgdGhlIHRoaXJkIGZvY3VzDQpJIGhhdmUgc29tZSBjb25jZXJucyBvZiB0aGUgd2cgZG9pbmcg
YXQgc2FtZSB0aW1lIHRoZSB3b3JrIGZvciBkZXNpZ25pbmcgdGhlIHRyYW5zcG9ydCBwcm90b2Nv
bCBhbmQgZGVzY3JpYmluZw0K4oCcbWFwcGluZ3MgYmV0d2VlbiBzcGVjaWZpYyBhcHBsaWNhdGlv
bnPigJkgc2VtYW50aWNzIGFuZCB0aGUgdHJhbnNwb3J0IGZhY2lsaXRpZXMgb2YgUVVJQ+KAnQ0K
DQpGb3IgdGhlIGZvdXJ0aCBmb2N1cyBJIGRvbuKAmXQgdGhpbmsgdGhlIGV4cGVyaW1lbnRhdGlv
biBoYXMgc2hvd2VkIHNvIGZhciBlbm91Z2ggaW50ZXJlc3RpbmcgcmVzdWx0cyBkZXNlcnZpbmcg
dG8gYmUgc3RhbmRhcmRpemVkLg0KDQpDaGVlcnMNClNhbHZhdG9yZQ0KDQpGcm9tOiBRVUlDIFtt
YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIEhhcmRpZQ0KU2Vu
dDogZGVuIDE0IG1haiAyMDE2IDAxOjI3DQpUbzogcXVpY0BpZXRmLm9yZzsgSmFuYSBJeWVuZ2Fy
OyBDaHJpc3RpYW4gSHVpdGVtYQ0KU3ViamVjdDogW1FVSUNdIERyYWZ0IGNoYXJ0ZXINCg0KSG93
ZHksDQpBcyBwYXJ0IG9mIHRoZSBCb0YgcHJlcGFyYXRpb24sIHdlIHB1dCB0b2dldGhlciBhIHN0
YWIgYXQgYSBkcmFmdCBjaGFydGVyLiAgSXQncyBhdmFpbGFibGUgYXMgaHRtbCBhbmQgbWFya2Rv
d24gb24gZ2l0aHViIGF0Og0KDQpodHRwczovL2dpdGh1Yi5jb20vSUVURi1RVUlDL0NoYXJ0ZXIN
CkkndmUgYXR0YWNoZWQgdGhlIEhUTUwgdmVyc2lvbiBhcyB3ZWxsLg0KSXQgd291bGQgYmUgZ3Jl
YXQgdG8gaGF2ZSBzb21lIG9mIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGJlZm9yZSB0aGUg
Qm9GLiAgQ29tbWVudHMgdG8gdGhlIGxpc3Qgb3IgaXNzdWVzL3B1bGwgcmVxdWVzdHMgYXQgdGhl
IGdpdGh1YiByZXBvIGFyZSB3ZWxjb21lLiAgV2Ugd2lsbCBwZXJpb2RpY2FsbHkgcmVmbGVjdCBh
bnkgaXNzdWVzIG9yIHN1Z2dlc3Rpb24gZnJvbSB0aGUgUmVwbyBiYWNrIHRvIHRoZSBsaXN0LCBi
dXQgdGhpcyB3aWxsIGJlIG1hbnVhbCwgc28gZXhwZWN0IHNvbWUgbGFnLg0KDQpyZWdhcmRzLA0K
VGVkDQo=

--_000_2B9B48179856DC4FA00C93C79EB7E64A60D94ED9ESESSMB109erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44
NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX
b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp
Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0
Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv
eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi
IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBU
ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkkgdGhpbmtzIHRoZSBjaGFydGVyIGxvb2tzIE9LLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5Ib3dldmVyIEkgdGVuZCB0byBhZ3JlZSB3aXRoIHByZXZpb3VzIGNv
bW1lbnRzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhhdCB0aGUgd29yayBhdCBt
b21lbnQgc2hvdWxkIHJlYWxseSBmb2N1c2VkIG9uIChuYXJyb3dlZCB0bykgdGhlIGZpcnN0IGFu
ZCBzZWNvbmQgcGFydHMgdG8gdGhlIGRlc2lnbiBvZiBRVUlDIGFzIHRyYW5zcG9ydCBwcm90b2Nv
bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+Zm9yIHRoZSB0aGlyZCBmb2N1czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5JIGhhdmUgc29tZSBjb25jZXJucyBvZiB0aGUgd2cgZG9pbmcgYXQgc2FtZSB0aW1lIHRo
ZSB3b3JrIGZvciBkZXNpZ25pbmcgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBhbmQgZGVzY3JpYmlu
Zw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnG1hcHBpbmdzIGJldHdlZW4gc3Bl
Y2lmaWMgYXBwbGljYXRpb25z4oCZIHNlbWFudGljcyBhbmQgdGhlIHRyYW5zcG9ydCBmYWNpbGl0
aWVzIG9mIFFVSUPigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciB0aGUgZm91cnRoIGZvY3VzIEkgZG9u4oCZdCB0
aGluayB0aGUgZXhwZXJpbWVudGF0aW9uIGhhcyBzaG93ZWQgc28gZmFyIGVub3VnaCBpbnRlcmVz
dGluZyByZXN1bHRzIGRlc2VydmluZyB0byBiZSBzdGFuZGFyZGl6ZWQuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVl
cnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2FsdmF0b3JlPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGll
dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UZWQgSGFyZGllPGJyPg0KPGI+U2VudDo8L2I+
IGRlbiAxNCBtYWogMjAxNiAwMToyNzxicj4NCjxiPlRvOjwvYj4gcXVpY0BpZXRmLm9yZzsgSmFu
YSBJeWVuZ2FyOyBDaHJpc3RpYW4gSHVpdGVtYTxicj4NCjxiPlN1YmplY3Q6PC9iPiBbUVVJQ10g
RHJhZnQgY2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhvd2R5
LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPkFzIHBhcnQgb2YgdGhlIEJvRiBwcmVwYXJhdGlvbiwgd2UgcHV0
IHRvZ2V0aGVyIGEgc3RhYiBhdCBhIGRyYWZ0IGNoYXJ0ZXIuJm5ic3A7IEl0J3MgYXZhaWxhYmxl
IGFzIGh0bWwgYW5kIG1hcmtkb3duIG9uIGdpdGh1YiBhdDo8YnI+DQo8YnI+DQo8YSBocmVmPSJo
dHRwczovL2dpdGh1Yi5jb20vSUVURi1RVUlDL0NoYXJ0ZXIiPmh0dHBzOi8vZ2l0aHViLmNvbS9J
RVRGLVFVSUMvQ2hhcnRlcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JJ3ZlIGF0dGFjaGVkIHRoZSBI
VE1MIHZlcnNpb24gYXMgd2VsbC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd291bGQgYmUgZ3JlYXQgdG8gaGF2ZSBzb21lIG9m
IHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGJlZm9yZSB0aGUgQm9GLiZuYnNwOyBDb21tZW50
cyB0byB0aGUgbGlzdCBvciBpc3N1ZXMvcHVsbCByZXF1ZXN0cyBhdCB0aGUgZ2l0aHViIHJlcG8g
YXJlIHdlbGNvbWUuJm5ic3A7IFdlIHdpbGwgcGVyaW9kaWNhbGx5IHJlZmxlY3QgYW55IGlzc3Vl
cyBvciBzdWdnZXN0aW9uIGZyb20gdGhlIFJlcG8gYmFjayB0byB0aGUNCiBsaXN0LCBidXQgdGhp
cyB3aWxsIGJlIG1hbnVhbCwgc28gZXhwZWN0IHNvbWUgbGFnLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+
cmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGVk
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_2B9B48179856DC4FA00C93C79EB7E64A60D94ED9ESESSMB109erics_--


From nobody Sun May 15 13:52:09 2016
Return-Path: 
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 11A1212D517 for ; Sun, 15 May 2016 13:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=microsoft.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 uH-Hl2Wg0rnO for ; Sun, 15 May 2016 13:52:06 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838F112D093 for ; Sun, 15 May 2016 13:52:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qPmAxmh8EuBAaxj8bw2D36QhdfNfS6mgRPzARUO/VK8=; b=NXHkHF69fBnxAJ0jDM9atETgsT3XZ2uCAaoLmSrYIldER1oh8VJm2XZPbOpDOsEY/MO9YMwvlcgRGjPN5I9kEHiOqGN0ZgiX8WRS+BXWaCm9/N525s65l0+qJzc8fMMw4raA5iKQSC6lHzRGQ2kWBk6udw6qNLd36yd7oT9OkLQ=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (TLS) id 15.1.492.11; Sun, 15 May 2016 20:51:47 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0492.020; Sun, 15 May 2016 20:51:47 +0000
From: Christian Huitema 
To: Salvatore Loreto , Ted Hardie , "quic@ietf.org" , Jana Iyengar 
Thread-Topic: [QUIC] Draft charter
Thread-Index: AQHRrW/Sb0NYcU1DiUO0Xn0RTsSsY5+6ZkIAgAAT8zA=
Date: Sun, 15 May 2016 20:51:46 +0000
Message-ID: 
References:  <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se>
In-Reply-To: <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=microsoft.com; 
x-originating-ip: [72.235.151.78]
x-ms-office365-filtering-correlation-id: 68314c68-6fad-4aee-795f-08d37d02bb00
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 5:veaLzICJuw5ntL1ReZwgjrpAArn/4P3T1eF3IQYsjL75sYWGHbO8yyn2wSB5uS6DBrlel1+RrgCDiuIINNat5IcuWmA50+uuh9vyOI2vhLqO7H2uu/gsQO9nly6w/8HWg2hfPDuSRpm3J5o6XXZe0Q==; 24:riYgiu1pJ1xSysjkW6bheMg6CKcGqYvQt7GL20qDfBACuzjxkVGLPuZmyTnfenchRM7BIwAKtcWSn6wEYywzNOJ77jPkzFNROcFPCOx/q6c=; 7:7y9kziRsAnhUr7nVgSkSBqhEOStcR9u9PVvn86zQXDwC0xWil/s5o8ROunw+HBWSV+8r6dvX2rcKUFoIfmi6Em9Bi8E3V9XAXcXO7ajScU62Vdyc8ucHB/jkIojd3E13FfkpqjPlpG2bnrFkydUNNp0XQGQjR499YpHGNV0Pr0Ge0AIMnKm+c14TpbNrj7tUaCVG3r4k3yaSjQ+EJFiZ5Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; 
x-forefront-prvs: 09435FCA72
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(86612001)(8936002)(8676002)(189998001)(2950100001)(2900100001)(5003600100002)(81166006)(76576001)(10090500001)(5001770100001)(77096005)(74316001)(2501003)(9686002)(76176999)(92566002)(50986999)(5002640100001)(54356999)(33656002)(122556002)(5005710100001)(86362001)(11100500001)(10290500002)(107886002)(1220700001)(3846002)(66066001)(586003)(2906002)(102836003)(5008740100001)(87936001)(6116002)(99286002)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2016 20:51:46.7023 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654
Archived-At: 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 May 2016 20:52:08 -0000

T24gU3VuZGF5LCBNYXkgMTUsIDIwMTYgMTI6MzMgUE0sIFNhbHZhdG9yZSBMb3JldG8gd3JvdGU6
DQoNCj4gSGkgVGVkDQo+DQo+IEkgdGhpbmtzIHRoZSBjaGFydGVyIGxvb2tzIE9LLA0KPiBIb3dl
dmVyIEkgdGVuZCB0byBhZ3JlZSB3aXRoIHByZXZpb3VzIGNvbW1lbnRzIA0KPiB0aGF0IHRoZSB3
b3JrIGF0IG1vbWVudCBzaG91bGQgcmVhbGx5IGZvY3VzZWQgb24gKG5hcnJvd2VkIHRvKSB0aGUg
Zmlyc3QgYW5kIHNlY29uZCBwYXJ0cyB0byB0aGUgZGVzaWduIG9mIFFVSUMgYXMgdHJhbnNwb3J0
IHByb3RvY29sDQo+DQo+IGZvciB0aGUgdGhpcmQgZm9jdXMNCj4gSSBoYXZlIHNvbWUgY29uY2Vy
bnMgb2YgdGhlIHdnIGRvaW5nIGF0IHNhbWUgdGltZSB0aGUgd29yayBmb3IgZGVzaWduaW5nIHRo
ZSB0cmFuc3BvcnQgcHJvdG9jb2wgYW5kIGRlc2NyaWJpbmcgDQo+IOKAnG1hcHBpbmdzIGJldHdl
ZW4gc3BlY2lmaWMgYXBwbGljYXRpb25z4oCZIHNlbWFudGljcyBhbmQgdGhlIHRyYW5zcG9ydCBm
YWNpbGl0aWVzIG9mIFFVSUPigJ0NCg0KV2UgY2VydGFpbmx5IG5lZWQgdG8gc3BlY2lmeSB0aGUg
bWFwcGluZyB3aXRoIEhUVFAgMi4gQnV0IHdpdGggSFRUUCB0aGUgY2xpZW50IGFsd2F5cyBzZW5k
cyB0aGUgZmlyc3QgbWVzc2FnZSwgYW5kIHRoYXQgY3JlYXRlcyBhbiAiZXhwZXJpbWVudGF0aW9u
IGdhcC4iIEluIHNob3J0LCBIVFRQIHdpbGwgdXNlIDAtUlRUIGFuZCAxLVJUVCBkYXRhLCBidXQg
bm90IDAuNS1SVFQgZGF0YS4gVGhhdCdzIG9ubHkgZXhlcmNpc2VkIGJ5IGFwcGxpY2F0aW9ucyBm
b3Igd2hpY2ggdGhlIHNlcnZlciBzZW5kcyB0aGUgZmlyc3QgbWVzc2FnZS4gSSBkb24ndCBjYXJl
IG11Y2ggd2hpY2ggb2YgdGhlc2UgYXBwbGljYXRpb25zIHdlIGxvb2sgYXQsIGJ1dCB3ZSBzaG91
bGQgcGljayBvbmUsIGp1c3QgZm9yIGNsb3NpbmcgdGhlIGV4cGVyaW1lbnRhdGlvbiBnYXAuIE1h
eWJlIEZUUA0KDQo+IEZvciB0aGUgZm91cnRoIGZvY3VzIEkgZG9u4oCZdCB0aGluayB0aGUgZXhw
ZXJpbWVudGF0aW9uIGhhcyBzaG93ZWQgc28gZmFyIGVub3VnaCBpbnRlcmVzdGluZyByZXN1bHRz
IGRlc2VydmluZyB0byBiZSBzdGFuZGFyZGl6ZWQuDQoNCkFnYWluLCB3ZSBuZWVkIHRvIGNvbnNp
ZGVyIGF0IGxlYXN0IG9uZSBleHBlcmltZW50YXRpb24sIGlmIG9ubHkgdG8gdGVzdCB0aGUgZXh0
ZW5zaW9uIG1lY2hhbmlzbXMuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCg0K


From nobody Sun May 15 14:36:25 2016
Return-Path: 
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 B87FD12D53D for ; Sun, 15 May 2016 14:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 8ydUgd3LEFSa for ; Sun, 15 May 2016 14:36:21 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 A318012D536 for ; Sun, 15 May 2016 14:36:14 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id o66so166617710ywc.3 for ; Sun, 15 May 2016 14:36:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OFCv32Np85v4/Ip4t8FUCVVMUqlXDQAbMx2/LB85ask=; b=Dz1i2LeunapiqfYByROOaaJzFiqEL8RjvfpSd/OLwZ+8Axm5vwnJcIW+TiTQxZtG62 sBHZ963SsTKmRmWXAoIZ50Bq0IYVUaL1x2YRCcGtd9+REoAq6PvzQjwtbiQIJduU2KnP UzWgCuad2PgK+JhtAGf/bPS2vZnIr6v50Bhe7Z7LTzVtYT7b7rv6mSIzqQzejrJzj9n7 UOthkgaQRv1TTxBmNwuqJu1wPePT6zMrGcv/0D2usqNKBcNOJ/mOEBsrfYK53MAwEK93 HWUPInhgx99vsvxqQERBiO3zlyCJjzJFkcxvJECUxMyhvGQ8xKkHq0czk3cJ6YH966NR U7iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OFCv32Np85v4/Ip4t8FUCVVMUqlXDQAbMx2/LB85ask=; b=EY6iyzh4388t9diNJOnjxOP3gOBQ1yTqXLBaKgUBCm3bD7L1spvtUNU4YVPPnpPE7h lllGfUxeWMV89MPu6AZKuiutZAezftcUPrGDLqsbBZ48eKItq7wU+MVLDFfr2If4DaVO rfU7LA1crWoJanvG+cmDAN9o1PHTupqSpW9b9Ao/FKxTsSsPJGzQ4eCg36IoCcElETFX 8cfvbGOU97gYR/e1GxViNvKEB6b37IBJvHwX5BK/dheB58EkCatFOAfqIREi3FkrPqEB /VeyxFgcGQ/nLse+DloBoWGkaMMN8TwHa3wuszyWkUyKGPvCw0cm/+vc3S0UTCGYi2jm O/uw==
X-Gm-Message-State: AOPr4FUtJY9q4pVUIAYLqm6QDfYXtRKIcuUGdP55Htqn+WU7bOoQjN+KTPSGNpMpeHnt8KfGuEyhF/ofu18Pww==
X-Received: by 10.129.163.146 with SMTP id a140mr12769649ywh.254.1463348173732;  Sun, 15 May 2016 14:36:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.132.12 with HTTP; Sun, 15 May 2016 14:35:34 -0700 (PDT)
In-Reply-To: 
References:  <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se> 
From: Eric Rescorla 
Date: Sun, 15 May 2016 14:35:34 -0700
Message-ID: 
To: Christian Huitema 
Content-Type: multipart/alternative; boundary=94eb2c1287ee142b090532e84c3f
Archived-At: 
Cc: Salvatore Loreto , Jana Iyengar , Ted Hardie , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 May 2016 21:36:24 -0000

--94eb2c1287ee142b090532e84c3f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, May 15, 2016 at 1:51 PM, Christian Huitema 
wrote:

> On Sunday, May 15, 2016 12:33 PM, Salvatore Loreto wrote:
>
> > Hi Ted
> >
> > I thinks the charter looks OK,
> > However I tend to agree with previous comments
> > that the work at moment should really focused on (narrowed to) the firs=
t
> and second parts to the design of QUIC as transport protocol
> >
> > for the third focus
> > I have some concerns of the wg doing at same time the work for designin=
g
> the transport protocol and describing
> > =E2=80=9Cmappings between specific applications=E2=80=99 semantics and =
the transport
> facilities of QUIC=E2=80=9D
>
> We certainly need to specify the mapping with HTTP 2. But with HTTP the
> client always sends the first message, and that creates an "experimentati=
on
> gap." In short, HTTP will use 0-RTT and 1-RTT data, but not 0.5-RTT data.
> That's only exercised by applications for which the server sends the firs=
t
> message. I don't care much which of these applications we look at, but we
> should pick one, just for closing the experimentation gap. Maybe FTP
>

What about relaxing the HTTP profile to allow server push immediately upon
connection?

-Ekr


> > For the fourth focus I don=E2=80=99t think the experimentation has show=
ed so far
> enough interesting results deserving to be standardized.
>
> Again, we need to consider at least one experimentation, if only to test
> the extension mechanisms.
>
> -- Christian Huitema
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>

--94eb2c1287ee142b090532e84c3f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Sun, May 15, 2016 at 1:51 PM, Christian Huitema &l=
t;huitema@micros=
oft.com> wrote:
On Sunday, May 15, 2016 12:33 PM, Salvatore Loreto wrote:



> Hi Ted

>

> I thinks the charter looks OK,

> However I tend to agree with previous comments

> that the work at moment should really focused on (narrowed to) the fir=
st and second parts to the design of QUIC as transport protocol

>

> for the third focus

> I have some concerns of the wg doing at same time the work for designi=
ng the transport protocol and describing

> =E2=80=9Cmappings between specific applications=E2=80=99 semantics and=
 the transport facilities of QUIC=E2=80=9D



We certainly need to specify the mapping with HTTP 2. But with HTTP =
the client always sends the first message, and that creates an "experi=
mentation gap." In short, HTTP will use 0-RTT and 1-RTT data, but not =
0.5-RTT data. That's only exercised by applications for which the serve=
r sends the first message. I don't care much which of these application=
s we look at, but we should pick one, just for closing the experimentation =
gap. Maybe FTP

What about relaxing the =
HTTP profile to allow server push immediately upon connection?
-Ekr




> For the fourth focus I don=E2=80=99t think the experimentation has sho=
wed so far enough interesting results deserving to be standardized.



Again, we need to consider at least one experimentation, if only to =
test the extension mechanisms.



-- Christian Huitema






_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--94eb2c1287ee142b090532e84c3f--


From nobody Sun May 15 17:32:31 2016
Return-Path: 
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 437E712D567 for ; Sun, 15 May 2016 17:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 jw5HlVil5eWd for ; Sun, 15 May 2016 17:32:29 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 E67BB12B030 for ; Sun, 15 May 2016 17:32:28 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id 190so192696528iow.1 for ; Sun, 15 May 2016 17:32:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ZHGsj55nQ1jhpvrz/h8n7oX6nCUi2//j5hClGHyqhrU=; b=FtwbXf9MVlO63Wo8Bz3X7m9biBw7rDPHEGZr3dttN5Ip6Z/2vxD3L5Akq+vt89We4A Cuo/gZeuSOaciWfH+yd9WiK8mysLyE4r7vdP9x01Byw4D9oYL5ChkNGnRpXu76k3en5V o+tgCR26OldB+du3NmvqjqCwohcVuhBVPtwotXUb6paVPzNn013BOcBkKW86sV462VUM 4HfU5jccc9IqrhaleMg2aKF0LkzpP077URYMs+lAsAvR45QOElUWzaTH0lGXUvI3wO+N +alqVnLBt8gu5xMVjdifyBIGtq1QmfPhmd3FonK3aeGGeDYG8AfMk4CgfKuy37VkLflR rAvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ZHGsj55nQ1jhpvrz/h8n7oX6nCUi2//j5hClGHyqhrU=; b=CHrnvr8yd03L33SAcGKayINrYLkGq9lcJJleGv9pa5CrD/tBGtbdMrcXEaH+8U0FZ9 GEjZf9u5RIk8/hFKYurRId+YT3xhYA1sMREqGnouLPzYwQ2FtlK3vsKUL3dINcVNxQMs ibj1KOOPI4Re9gSBPmf6CzPjoUBHQfCvBLbgnx7cQ12uj2U8ULKGv/ljvHI2e5iHJMva 8pPo2Lc8UmbBIooVdncz9sl3hKL0+d+JR39WqwMs8RJfb9zo19kyL9VfBjl1cr6WA/X3 9IT1we+EQ5sSRIaU2JmuFHe7C8tbUTWZX/gMISaUQ861fCxrcvaaeVsxZpz8zZTzV5ls MUzg==
X-Gm-Message-State: AOPr4FVjCzHooISfi6Wc1FYRDUCrPkCugkOMwo+n650gqsOVQ4fOxQI7QozPkGgiNFDnsowWNmpNNgBog1ASVg==
MIME-Version: 1.0
X-Received: by 10.107.161.195 with SMTP id k186mr4935140ioe.190.1463358748342;  Sun, 15 May 2016 17:32:28 -0700 (PDT)
Received: by 10.36.43.82 with HTTP; Sun, 15 May 2016 17:32:28 -0700 (PDT)
In-Reply-To: 
References:  <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se>  
Date: Sun, 15 May 2016 20:32:28 -0400
Message-ID: 
From: Martin Thomson 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Salvatore Loreto , Christian Huitema , Ted Hardie , "quic@ietf.org" , Jana Iyengar 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 00:32:30 -0000

On 15 May 2016 at 17:35, Eric Rescorla  wrote:
>> We certainly need to specify the mapping with HTTP 2. But with HTTP the
>> client always sends the first message, and that creates an "experimentation
>> gap." In short, HTTP will use 0-RTT and 1-RTT data, but not 0.5-RTT data.
>> That's only exercised by applications for which the server sends the first
>> message. I don't care much which of these applications we look at, but we
>> should pick one, just for closing the experimentation gap. Maybe FTP
>
>
> What about relaxing the HTTP profile to allow server push immediately upon
> connection?

That doesn't work particularly well unless you associate the push with
a request, but I'm sure that we can work something out.

I don't know if the settings that HTTP/2 sends are considerable enough
that we can claim to be using 0.5-RTT data, but they are something
that a server can send.  Maybe Christian wants to find something with
which the pipe can be filled, in which case pushing seems like a
plausible option.


From nobody Sun May 15 22:00:37 2016
Return-Path: 
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 75F8512B02F for ; Sun, 15 May 2016 22:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 RNf2iEJ2KNBw for ; Sun, 15 May 2016 22:00:34 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 E740012B01F for ; Sun, 15 May 2016 22:00:33 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id j74so152037630ywg.1 for ; Sun, 15 May 2016 22:00:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=cun/kh+YD8dbrsiN0JHjvrndsMuScuMN+4ZkIrzMqyg=; b=JmsXxlVV6LiqLe2SDRfKyMTcNARRc2arLQdP6EtQ/0vRE4xiIKU9q46Bbzts5xFi/S fGck3LDJK3JUqyAOfVIJGyNxQ3wpmzMlsjfE5i0KThZCP7Qw5PwCZf9qLcDnr43xVzH0 WvW9a6Ix2LxCd++n2hi5NZj6Rvr/Pw/465ZZWDX7omdmh4aOx6fIayL9YUEt50WQAUoa EVteVtggwKACd0sRSU302678p72X9CvWzI1NRl7MpaP8ZuuvqVuJXIcO9imYxFkUL+fM mACpGinm4zkqGSizIOovSb4QXw6VtkkmH2zs2bQmiq2zFOp38h+PoWTewf753IZhUnLp 3bmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=cun/kh+YD8dbrsiN0JHjvrndsMuScuMN+4ZkIrzMqyg=; b=bNIvqZZwQIDpCqNI3/F78MAutL83wcJTVbhcJfiLresRSRz7ftkMrBwQ0xU/oDIaO5 6bp/ff+OBXeuK+jOmuDwgNDJ97wK3K7et6K1Flpe3+HNo8wbugqnRr1/br+3/etXbaLi C3tV2qgMAbZrrI5fB8ZlrOiiJooIdnLITJsWRFl0YAkcGd6z6jGmQPxwED7huZ/ggMLR Vdw2KQH/4xPNf85hPWZ8z1Ola65zFZVBoS8WCTy7C7eaEINaMVZQZELZTrPHAbqRK2LY hOJQx/KJ/G0lwdODXF6Tt09o447JvbMn0UsHMHBoWfyPxJHrWzAeDW3zwRMdX5rokdKr kW/g==
X-Gm-Message-State: AOPr4FWC/CGmsyWCImaIi/WM8LVcP/Zd9fLpTpqoXVYzrx3X2NxOEqjQ2QRPQTLikfljUKjluKsXMFbHzZiuF2YO
MIME-Version: 1.0
X-Received: by 10.13.218.65 with SMTP id c62mr6711723ywe.36.1463374832902; Sun, 15 May 2016 22:00:32 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Sun, 15 May 2016 22:00:32 -0700 (PDT)
In-Reply-To: 
References:  
Date: Sun, 15 May 2016 22:00:32 -0700
Message-ID: 
From: Jana Iyengar 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=94eb2c080508170e550532ee8125
Archived-At: 
Cc: Christian Huitema , Ted Hardie , quic@ietf.org
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 05:00:36 -0000

--94eb2c080508170e550532ee8125
Content-Type: text/plain; charset=UTF-8

Martin,

Responses inline.

On Sun, May 15, 2016 at 9:42 AM, Martin Thomson 
wrote:

> On 13 May 2016 at 19:26, Ted Hardie  wrote:
> > https://github.com/IETF-QUIC/Charter
>
> As Lars says, this is pretty good.
>
> I think that the first and second parts are the essential pieces to
> concentrate on at this moment.  While I also want to do multipath and
> FEC, I don't believe that we are ready enough yet to commit to doing
> something with FEC.  A rechartering when that time comes should not be
> hard and a smaller scope helps maintain focus.
>

It should be clear  but it's worth clarifying that the FEC item is not
about FEC schemes, but about identifying and specifying core protocol
mechanisms that will be required to allow FEC schemes to be used by QUIC.
That said, I'm on the fence about requiring a re-charter for FEC; and I
would very much like to hear more voices on this question.

If you reduce part 4 to a note saying that the group might recharter
> to add these capabilities, then that gives you more space to expand on
> part 1, which I think is lacking in detail.
>

(Assuming the specific details you are asking about are the ones listed
below.)


> --
>
> This list in part 1 raises quite a few questions for me:
>
> "connection establishment, stream multiplexing, data reliability, loss
> detection and recovery, congestion control, and negotiation"
>
> How is data reliability different to loss detection and recovery?
>

They aren't functionally different. But I think it's worth calling out loss
detection and recovery mechanisms separately, since most modern loss
detection and recovery mechanisms are all about performance. Specifically,
RFC 793 specifies a completely reliable TCP, and it specifies a
retransmission timeout as the mechanism for loss detection and recovery.
Pretty much all of loss detection and recovery mechanisms built since 1981
(NewReno, FR, ER, TLP, F-RTO) fall under the category of performance
optimizations of this reliability function. I think it's worth calling that
out separately, since we'll need to specify how to get these (and more)
performance optimizations in loss detection and recovery with QUIC as well.


> Are we talking about adding features like SCTP has with respect to
> partial reliability?  HTTP doesn't need it, but I've heard of grand
> plans to do real-time media over this abstraction.  Framing of that in
> the charter is probably much harder than the actual technical work
> needed to define such things.
>

This charter does not propose SCTP-style packet-level partial reliability
at the moment.

What, if any, effort is this group going to put into defining a
> congestion control mechanism as opposed to just picking one (or more)
> existing mechanisms?  Can we push this more toward just picking
> something, maybe allowing for a few tweaks?
>

At the moment, the charter deliberately does not mention defining or
negotiating a congestion control mechanism. My specific expectation was
that we'd end up defining a NewReno-style CC as a (non-mandatory) default,
since it is one CC that will probably need to be specified for QUIC. That
said, CC is largely a sender-side concern, and with a reasonable ack
mechanism, a sender can unilaterally implement quite a diverse set of CC
mechanisms. Folks will ultimately use whatever CC they want with QUIC, just
as they do with TCP -- I expect CC in QUIC deployments to be at least as
diverse as it is for TCP now. Do you think something should be added to the
charter to clarify that the wg is expected to map existing TCP CC onto QUIC
and not define new CC mechanisms?


> And what is being negotiated?
>

It was supposed to be a placeholder for negotiating QUIC version, in
addition to any transport extensions (multipath) that may need negotiation.
How about we change it to just "version negotiation" and deal with other
negotiation needs as we encounter them?

--
>
> I would recommend removing or reducing the following statement: "It
> will also provide a threat model description specific to connection
> resumption, along with a description for denial-of-service
> mitigations."  The threat model should be a little more comprehensive
> than just resumption, but we have a great deal of analysis for
> existing and similar protocols.  It's unclear what additional work
> would be required, and it might be the case that we don't want to
> write that all down. Moreover, this implies a narrower scope than
> necessary.
>
> The denial of service aspects are important, but do we really need to
> write those into a charter?  I notice that we aren't writing down
> operational concerns, which are also considerable.
>

That's fair. I'm comfortable removing that statement.

Thanks much!
- jana

--94eb2c080508170e550532ee8125
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Martin,

Responses inline.

On Sun, May 15, 2016 at 9:4=
2 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 13 May 2016 at 19:26, Ted Hardie <ted.ietf@gmail.com> wrote:

> ht=
tps://github.com/IETF-QUIC/Charter



As Lars says, this is pretty good.



I think that the first and second parts are the essential pieces to

concentrate on at this moment.=C2=A0 While I also want to do multipath and<=
br>
FEC, I don't believe that we are ready enough yet to commit to doing
something with FEC.=C2=A0 A rechartering when that time comes should not be=


hard and a smaller scope helps maintain focus.

It should be clear =C2=A0but it's worth clarifying that the FEC=
 item is not about FEC schemes, but about identifying and specifying core p=
rotocol mechanisms that will be required to allow FEC schemes to be used by=
 QUIC. That said, I'm on the fence about requiring a re-charter for FEC=
; and I would very much like to hear more voices on this question.


If you reduce part 4 to a note saying that the group might recharter

to add these capabilities, then that gives you more space to expand on

part 1, which I think is lacking in detail.

=

(Assuming the specific details you are asking about are the ones liste=
d below.)
=C2=A0

--



This list in part 1 raises quite a few questions for me:



"connection establishment, stream multiplexing, data reliability, loss=


detection and recovery, congestion control, and negotiation"



How is data reliability different to loss detection and recovery?

They aren't functionally different. But I th=
ink it's worth calling out loss detection and recovery mechanisms separ=
ately, since most modern loss detection and recovery mechanisms are all abo=
ut performance. Specifically, RFC 793 specifies a completely reliable TCP, =
and it specifies a retransmission timeout as the mechanism for loss detecti=
on and recovery. Pretty much all of loss detection and recovery mechanisms =
built since 1981 (NewReno, FR, ER, TLP, F-RTO) fall under the category of p=
erformance optimizations of this reliability function. I think it's wor=
th calling that out separately, since we'll need to specify how to get =
these (and more) performance optimizations in loss detection and recovery w=
ith QUIC as well.
=C2=A0

Are we talking about adding features like SCTP has with respect to

partial reliability?=C2=A0 HTTP doesn't need it, but I've heard of =
grand

plans to do real-time media over this abstraction.=C2=A0 Framing of that in=


the charter is probably much harder than the actual technical work

needed to define such things.

This char=
ter does not propose SCTP-style packet-level partial reliability at the mom=
ent.


What, if any, effort is this group going to put into defining a

congestion control mechanism as opposed to just picking one (or more)

existing mechanisms?=C2=A0 Can we push this more toward just picking

something, maybe allowing for a few tweaks?

=

At the moment, the charter deliberately does not mention defining or n=
egotiating a congestion control mechanism. My specific expectation was that=
 we'd end up defining a NewReno-style CC as a (non-mandatory) default, =
since it is one CC that will probably need to be specified for QUIC. That s=
aid, CC is largely a sender-side concern, and with a reasonable ack mechani=
sm, a sender can unilaterally implement quite a diverse set of CC mechanism=
s. Folks will ultimately use whatever CC they want with QUIC, just as they =
do with TCP --=C2=A0I expect CC in QUIC deployments to be at least as diver=
se as it is for TCP now. Do you think something should be added to the char=
ter to clarify that the wg is expected to map existing TCP CC onto QUIC and=
 not define new CC mechanisms?
=C2=A0

And what is being negotiated?

It was su=
pposed to be a placeholder for negotiating QUIC version, in addition to any=
 transport extensions (multipath) that may need negotiation. How about we c=
hange it to just "version negotiation" and deal with other negoti=
ation needs as we encounter them?


--



I would recommend removing or reducing the following statement: "It
will also provide a threat model description specific to connection

resumption, along with a description for denial-of-service

mitigations."=C2=A0 The threat model should be a little more comprehen=
sive

than just resumption, but we have a great deal of analysis for

existing and similar protocols.=C2=A0 It's unclear what additional work=


would be required, and it might be the case that we don't want to

write that all down. Moreover, this implies a narrower scope than

necessary.



The denial of service aspects are important, but do we really need to

write those into a charter?=C2=A0 I notice that we aren't writing down<=
br>
operational concerns, which are also considerable.



That's fair. I&=
#39;m comfortable removing that statement.
=

Thanks much!
- jana


--94eb2c080508170e550532ee8125--


From nobody Sun May 15 22:18:50 2016
Return-Path: 
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 298A012B02F for ; Sun, 15 May 2016 22:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8HBvEtXnP4fh for ; Sun, 15 May 2016 22:18:45 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 C6BA612D0CD for ; Sun, 15 May 2016 22:18:44 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id g133so152247982ywb.2 for ; Sun, 15 May 2016 22:18:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=GwW3JQTUFVyjRPpEYvGq1ixczjDH0GkXkBN6P57JiQY=; b=Ad7uo0yYv39Ll+G+ain94ti3m4+brCAD8Sk44+7RB9zq2nDswze/1gL9S6Y/lKHUq4 Fma/px3p75a8Sc4GmlJJUd5maeHWXAQg4fppY7olUuTwnUBMh5r/CtlkbGikVbS6OHci X/DpCQZc067fdGUUikGhHc7wVPIEgR+yvAU9iSkWurxnFRCZoBS/ALiQjDp1On5tzfvF DzcGZI7PTwxym5MbFUxWtO92XtWyGyhbOqgZaYJlGWTRUb6S6Prjgl/j+bSOzGhn8OqU O0gfJ1GkZDWFgRIw7L1qFeWyKUTLmkzdpchZNhiWmrGfIRFCA1q4nU+Mtm1MeSucvZwn OF7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GwW3JQTUFVyjRPpEYvGq1ixczjDH0GkXkBN6P57JiQY=; b=HhpybBQQzLGjNdW9qg4iQJn7GrLG3jtsHZ0qQkXQSrbKsMGUz8ne6CY6nepq4IG0UG I3Q31icYRAaYT5dP1wRwXcynIyVpZwl8dv8Jnn3YKlzC/X0vy/WX5Azwd8LrjNT2nncy SIHF8XJr3xEd8hZU+LHL2GErr6xoe3yM6XSEDawzWuG0UCRdzH20iQcGtjq0ean9Iyc/ SE/kW4BmvWQ2pJSMJbSAT53aKJ1v3dqcPOqISjlBJdjjDiFaBgg5hNXECaFAckt6Imdn AxUCQvjf2W9MVzEyqA5GPchmDcay35DdSK91sf5yAygYsG1JgQOIavy19maRImL8LBL0 CF7w==
X-Gm-Message-State: AOPr4FWKPODagkbDQZx+r2KULf0neyV0Svb9T8c2bI3mPPM2Ss9WbvRlrM5L6ot9yD2k6c/PjzO6XygAloGKYsC4
MIME-Version: 1.0
X-Received: by 10.129.121.81 with SMTP id u78mr13036628ywc.239.1463375923906;  Sun, 15 May 2016 22:18:43 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Sun, 15 May 2016 22:18:43 -0700 (PDT)
In-Reply-To: <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se>
References:  <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se>
Date: Sun, 15 May 2016 22:18:43 -0700
Message-ID: 
From: Jana Iyengar 
To: Salvatore Loreto 
Content-Type: multipart/alternative; boundary=94eb2c0a7b681eb4c20532eec229
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 05:18:48 -0000

--94eb2c0a7b681eb4c20532eec229
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

To concerns about multipath in the fourth area: TSVAREA has done multipath
in SCTP and in MPTCP. MPTCP is seeing deployment -- albeit slowly and in
limited quarters -- and I would argue that expecting multipath to be a
facility available as a part of a brand new transport seems quite
reasonable.

Mechanisms for enabling FEC are a bit more experimental, so I'm more
comfortable moving this item to requiring a re-charter.


On Sun, May 15, 2016 at 12:32 PM, Salvatore Loreto <
salvatore.loreto@ericsson.com> wrote:

> Hi Ted
>
>
>
> I thinks the charter looks OK,
>
> However I tend to agree with previous comments
>
> that the work at moment should really focused on (narrowed to) the first
> and second parts to the design of QUIC as transport protocol
>
>
>
> for the third focus
>
> I have some concerns of the wg doing at same time the work for designing
> the transport protocol and describing
>
> =E2=80=9Cmappings between specific applications=E2=80=99 semantics and th=
e transport
> facilities of QUIC=E2=80=9D
>
>
>
> For the fourth focus I don=E2=80=99t think the experimentation has showed=
 so far
> enough interesting results deserving to be standardized.
>
>
>
> Cheers
>
> Salvatore
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ted Hardie
> *Sent:* den 14 maj 2016 01:27
> *To:* quic@ietf.org; Jana Iyengar; Christian Huitema
> *Subject:* [QUIC] Draft charter
>
>
>
> Howdy,
>
> As part of the BoF preparation, we put together a stab at a draft
> charter.  It's available as html and markdown on github at:
>
> https://github.com/IETF-QUIC/Charter
>
> I've attached the HTML version as well.
>
> It would be great to have some of the discussion on the list before the
> BoF.  Comments to the list or issues/pull requests at the github repo are
> welcome.  We will periodically reflect any issues or suggestion from the
> Repo back to the list, but this will be manual, so expect some lag.
>
>
>
> regards,
>
> Ted
>

--94eb2c0a7b681eb4c20532eec229
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


To concerns about multipath in the fourth area: TSVAR=
EA has done multipath in SCTP and in MPTCP. MPTCP is seeing deployment -- a=
lbeit slowly and in limited quarters -- and I would argue that expecting mu=
ltipath to be a facility available as a part of a brand new transport seems=
 quite reasonable.

Mechanisms for enabli=
ng FEC are a bit more experimental, so I'm more comfortable moving this=
 item to requiring a re-charter.


On Sun, May 15, 2016 at 12:=
32 PM, Salvatore Loreto <salvatore.loreto@ericsson.com>=
 wrote:











Hi Ted


=C2=A0


I thinks the charter look=
s OK,


However I tend to agree w=
ith previous comments



that the work at moment s=
hould really focused on (narrowed to) the first and second parts to the des=
ign of QUIC as transport protocol


=C2=A0


for the third focus


I have some concerns of t=
he wg doing at same time the work for designing the transport protocol and =
describing



=E2=80=9Cmappings between=
 specific applications=E2=80=99 semantics and the transport facilities of Q=
UIC=E2=80=9D


=C2=A0


For the fourth focus I do=
n=E2=80=99t think the experimentation has showed so far enough interesting =
results deserving to be standardized.


=C2=A0


Cheers


Salvatore


=C2=A0


From: QUIC [ma=
ilto:quic-bounce=
s@ietf.org]
On Behalf Of Ted Hardie

Sent: den 14 maj 2016 01:27

To: quic@ietf.org=
; Jana Iyengar; Christian Huitema

Subject: [QUIC] Draft charter


=C2=A0












Howdy,<=
/p>



As part of the BoF pr=
eparation, we put together a stab at a draft charter.=C2=A0 It's availa=
ble as html and markdown on github at:



https://=
github.com/IETF-QUIC/Charter




I've attached the=
 HTML version as well.=C2=A0







It would be great to have some of the discussion on =
the list before the BoF.=C2=A0 Comments to the list or issues/pull requests=
 at the github repo are welcome.=C2=A0 We will periodically reflect any iss=
ues or suggestion from the Repo back to the
 list, but this will be manual, so expect some lag.






=C2=A0




regards,




Ted












--94eb2c0a7b681eb4c20532eec229--


From nobody Sun May 15 22:33:18 2016
Return-Path: 
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 7C01312B03F for ; Sun, 15 May 2016 22:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 tHoWJ9mgQRMY for ; Sun, 15 May 2016 22:33:15 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 B27C112B02F for ; Sun, 15 May 2016 22:33:15 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id x194so18253781ywd.0 for ; Sun, 15 May 2016 22:33:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jz8id36T04LXOmJimLPLdI5jdNOa54Bm1r+wimMItP0=; b=IcgEVtEmARB4UOSuAGMfpWdlQDcgzQ6dSRKHenWqNBdvjbUYealH02cJBXzZwQXeyz wApaFsFezOiMNOUfOMhORSHhDkW90NTkQY2xV4JVhZwFqOam68HaK/4hCbZzEatBj2Ys XbDioil3IHGcfvk5WFBGwRfCRJF+Yqtg/B+au9B2V0dVfrRVSsGoNzvvukksM2QFN/mG NLejxMe2lcRXaNZuM3VS2iDcDooBfLVHTbEf/jUbMb+Ozm+3FRLP3eX5c04Cl279Yumr OF60b5+7EBTzX873kEtkJtYu//4if38hd9NRCuv8LfYbhxdGbWMyYmjXwTNtUOTo3Opy t4Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jz8id36T04LXOmJimLPLdI5jdNOa54Bm1r+wimMItP0=; b=mQsi3p4vZ+PgwKhizGiM6bEn2HZFZi9LgomiQ7Hj1cu/E2UUIlliYzp7FUj6NvmY3a XVRf8MbyxmONEHdsMXC3XqeKaLwSLnjzEM98Me+IDvsweeS6JBgeQyVdrynwF3KwxDA9 DMmGZYPtt1I8HDbW01MK5XfxPKlIEpCKrQCI2K2/GohtO+jEfo5e+oGnor2pCcGsfRtD S+EizN6rTeAUYTmfZOCkMuCpA2A4gqkYi1FvjKkbT16orvSOgkSwQeL3KoAy/swoHIUS QQ89PY28coJwwz4SRQGq4UW2QWhgMGyrzsswTtx9wqanmYX1NefhGW+s83PI6TP9rhyV 6UxA==
X-Gm-Message-State: AOPr4FXXTnBqLHCGyxw++Y18hHydqKHcpjVi+4PLO9XTDNfeOgvQJEJj3MeHmD2ckAhv46zzJRj5GqBMO0vS/yRA
MIME-Version: 1.0
X-Received: by 10.129.121.81 with SMTP id u78mr13058889ywc.239.1463376794725;  Sun, 15 May 2016 22:33:14 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Sun, 15 May 2016 22:33:14 -0700 (PDT)
In-Reply-To: <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se>
References:  <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se>
Date: Sun, 15 May 2016 22:33:14 -0700
Message-ID: 
From: Jana Iyengar 
To: Salvatore Loreto 
Content-Type: multipart/alternative; boundary=94eb2c0a7b680617940532eef6b1
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 05:33:17 -0000

--94eb2c0a7b680617940532eef6b1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Salvatore,

On Sun, May 15, 2016 at 12:32 PM, Salvatore Loreto <
salvatore.loreto@ericsson.com> wrote:

> Hi Ted
>
>
>
> I thinks the charter looks OK,
>
> However I tend to agree with previous comments
>
> that the work at moment should really focused on (narrowed to) the first
> and second parts to the design of QUIC as transport protocol
>
>
> for the third focus
>
> I have some concerns of the wg doing at same time the work for designing
> the transport protocol and describing
>
> =E2=80=9Cmappings between specific applications=E2=80=99 semantics and th=
e transport
> facilities of QUIC=E2=80=9D
>

The thinking was that it's helpful to have an application mapping going on
in parallel to ensure that we don't miss any important gotchas while
specifying the transport and its interfaces... and HTTP/2 is the only
application that QUIC has any real deployment experience with so far, so
specifying it alongside the transport seemed natural.

As a high-order point, I tend to think that having no application use-case
for a transport is equivalent to having all applications as use-cases for
the transport, since it quickly becomes difficult to tell which facilities
are important for the transport and which ones are not.

- jana

For the fourth focus I don=E2=80=99t think the experimentation has showed s=
o far
> enough interesting results deserving to be standardized.
>
>
>
> Cheers
>
> Salvatore
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ted Hardie
> *Sent:* den 14 maj 2016 01:27
> *To:* quic@ietf.org; Jana Iyengar; Christian Huitema
> *Subject:* [QUIC] Draft charter
>
>
>
> Howdy,
>
> As part of the BoF preparation, we put together a stab at a draft
> charter.  It's available as html and markdown on github at:
>
> https://github.com/IETF-QUIC/Charter
>
> I've attached the HTML version as well.
>
> It would be great to have some of the discussion on the list before the
> BoF.  Comments to the list or issues/pull requests at the github repo are
> welcome.  We will periodically reflect any issues or suggestion from the
> Repo back to the list, but this will be manual, so expect some lag.
>
>
>
> regards,
>
> Ted
>

--94eb2c0a7b680617940532eef6b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Salvatore,

On Sun, May 15, 2016 at 12:32 PM, Salvatore Loreto <salvatore.lor=
eto@ericsson.com> wrote:











Hi Ted


=C2=A0


I thinks the charter looks OK,<=
u>


However I tend to agree with previous =
comments



that the work at moment should really =
focused on (narrowed to) the first and second parts to the design of QUIC a=
s transport protocol





for the third focus


I have some concerns of the wg doing a=
t same time the work for designing the transport protocol and describing



=E2=80=9Cmappings between specific app=
lications=E2=80=99 semantics and the transport facilities of QUIC=E2=80=9D<=
/span>
=C2=A0
The thinking was t=
hat it's helpful to have an application mapping going on in parallel to=
 ensure that we don't miss any important gotchas while specifying the t=
ransport and its interfaces... and=C2=A0HTTP/2 is the only application that=
 QUIC has any real deployment experience with so far, so specifying it alon=
gside the transport seemed natural.

As a high-orde=
r point, I tend to think that having no application use-case for a transpor=
t is equivalent to having all applications as use-cases for the transport, =
since it quickly becomes difficult to tell which facilities are important f=
or the transport and which ones are not.

- jana



For the fourth focus I don=E2=80=99t t=
hink the experimentation has showed so far enough interesting results deser=
ving to be standardized.


=C2=A0


Cheers


Salvatore


=C2=A0


From: QUIC [mailto:=
quic-bounces@ietf.org]
On Behalf Of Ted Hardie

Sent: den 14 maj 2016 01:27

To: quic@ietf.org; Jana Iyengar=
; Christian Huitema

Subject: [QUIC] Draft charter


=C2=A0












Howdy,<=
/u>




As part of the Bo=
F preparation, we put together a stab at a draft charter.=C2=A0 It's av=
ailable as html and markdown on github at:



https://github.com/IETF-QU=
IC/Charter




I've attached=
 the HTML version as well.=C2=A0







It would be great to have some of the discussi=
on on the list before the BoF.=C2=A0 Comments to the list or issues/pull re=
quests at the github repo are welcome.=C2=A0 We will periodically reflect a=
ny issues or suggestion from the Repo back to the
 list, but this will be manual, so expect some lag.






=C2=A0




regards,




Ted












--94eb2c0a7b680617940532eef6b1--


From nobody Sun May 15 22:58:14 2016
Return-Path: 
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 3234A12B02F for ; Sun, 15 May 2016 22:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 y9W6BMDZ1rxS for ; Sun, 15 May 2016 22:58:12 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 D263312B02B for ; Sun, 15 May 2016 22:58:11 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id x194so18591535ywd.0 for ; Sun, 15 May 2016 22:58:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sUwAgwfAlgmupMJMKEjwXM0V1CSM6UV+l2iYQ3IR90Q=; b=Xc8Vve+zlyYKUdGzBQb5hoyp90h3QAM19e1jNjSCleQ0gQ1LOSA6HJDHtSJzBydDR5 RNVTvegZHC8p8makupKfB9G31yjcEVgX8gpnDE4MKi/Yjt0rCr5dZpzX3uayJBMOrGL7 aolMpi553+eWZNdjnIQDUVp8PzOKfMGTZOeJVQZGmhj04Q4Q0iT+qylr/iwMbAri5Ipu wjRHrHKIiYfdkhBlQJVCYPIOChr0GEWiRj5C9msISHgACqLdDrrawFtNcUNHcrcpqm55 E16pOQUuvAXdTYIqN4X+AEU4MtgxPb58r+6OlKt0xX9sJwerQNUxFzNLTyXgQ9UL4RYq 5olw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sUwAgwfAlgmupMJMKEjwXM0V1CSM6UV+l2iYQ3IR90Q=; b=SDD5qZGj4rqVlncZ3SXiu2SU2xi7iy3x9P4evc7NUE6uTaHmXl+/qzJRPNo1uhgUDA 4sK5yZ+k9zfpHVJGXHyWDG9PLc3leWVAwur+yMLD6xF5SLTlRAv1eJ0ARplKpx7/nqjf /22b2Ev1bTwA7vcfitYijlawWzs5RUVc+XrSN/pnV52ASPo01xSh7eO4LPXx2RhxPn8i T9FidsFIKPi3hzhs10ESM08mPSd1D4SIhxc6MGXDxrQF7ce8Sip0BXPBKFwsEqw36u/d nxwo0vhaU8dOfqj9pP5LVktc+BNb5vvRDrRibbxctWXptd5zRneWY/sRPjw02/+BUpJn 5kLA==
X-Gm-Message-State: AOPr4FWQ79I0oeak4nCHiquEWS5RUnDTIclCvrYsQsrJ7BpZ4672B2tL7z/X7n+2Po+M60JenoO7UNR4uv8Wnhkz
MIME-Version: 1.0
X-Received: by 10.129.165.135 with SMTP id c129mr14852746ywh.67.1463378290927;  Sun, 15 May 2016 22:58:10 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Sun, 15 May 2016 22:58:10 -0700 (PDT)
In-Reply-To: 
References:  <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se>   
Date: Sun, 15 May 2016 22:58:10 -0700
Message-ID: 
From: Jana Iyengar 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=94eb2c12a0623458df0532ef4fdc
Archived-At: 
Cc: Salvatore Loreto , Christian Huitema , Eric Rescorla , "quic@ietf.org" , Ted Hardie 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 05:58:13 -0000

--94eb2c12a0623458df0532ef4fdc
Content-Type: text/plain; charset=UTF-8

On Sun, May 15, 2016 at 5:32 PM, Martin Thomson 
wrote:

> On 15 May 2016 at 17:35, Eric Rescorla  wrote:
> >> We certainly need to specify the mapping with HTTP 2. But with HTTP the
> >> client always sends the first message, and that creates an
> "experimentation
> >> gap." In short, HTTP will use 0-RTT and 1-RTT data, but not 0.5-RTT
> data.
> >> That's only exercised by applications for which the server sends the
> first
> >> message. I don't care much which of these applications we look at, but
> we
> >> should pick one, just for closing the experimentation gap. Maybe FTP
> >
> >
> > What about relaxing the HTTP profile to allow server push immediately
> upon
> > connection?
>
> That doesn't work particularly well unless you associate the push with
> a request, but I'm sure that we can work something out.
>
> I don't know if the settings that HTTP/2 sends are considerable enough
> that we can claim to be using 0.5-RTT data, but they are something
> that a server can send.  Maybe Christian wants to find something with
> which the pipe can be filled, in which case pushing seems like a
> plausible option.
>

You've identified an outcome of the choice of HTTP/2 as the first
application on the charter. I'm sure that as we start talking about more
applications, we are likely to find additional tweaks that we'd want to
start making to accomodate those use cases. I'm wary of simply adding
features to the charter that might become hurdles to getting to first
application use-cases. Is there another application that we think is
important enough that we add as additional first application use-cases to
the charter?

I'd prefer that we keep a tight application-set to start with, which at the
moment is {HTTP/2}, and then re-charter to add more as the initial specs
mature.

--94eb2c12a0623458df0532ef4fdc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Sun, May 15, 2016 at 5:32 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 15 May 2016 at 17:=
35, Eric Rescorla <ekr@rtfm.com> =
wrote:

>> We certainly need to specify the mapping with HTTP 2. But with HTT=
P the

>> client always sends the first message, and that creates an "e=
xperimentation

>> gap." In short, HTTP will use 0-RTT and 1-RTT data, but not 0=
.5-RTT data.

>> That's only exercised by applications for which the server sen=
ds the first

>> message. I don't care much which of these applications we look=
 at, but we

>> should pick one, just for closing the experimentation gap. Maybe F=
TP

>

>

> What about relaxing the HTTP profile to allow server push immediately =
upon

> connection?



That doesn't work particularly well unless you associate the pus=
h with

a request, but I'm sure that we can work something out.



I don't know if the settings that HTTP/2 sends are considerable enough<=
br>
that we can claim to be using 0.5-RTT data, but they are something

that a server can send.=C2=A0 Maybe Christian wants to find something with<=
br>
which the pipe can be filled, in which case pushing seems like a

plausible option.



You've identifi=
ed an outcome of the choice of HTTP/2 as the first application on the chart=
er. I'm sure that as we start talking about more applications, we are l=
ikely to find additional tweaks that we'd want to start making to accom=
odate those use cases. I'm wary of simply adding features to the charte=
r that might become hurdles to getting to first application use-cases. Is t=
here another application that we think is important enough that we add as a=
dditional first application use-cases to the charter?

I'd prefer that we keep=
 a tight application-set to start with, which at the moment is {HTTP/2}, an=
d then re-charter to add more as the initial specs mature.



--94eb2c12a0623458df0532ef4fdc--


From nobody Sun May 15 23:18:25 2016
Return-Path: 
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 319B012D14B for ; Sun, 15 May 2016 23:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 HLPlVHyM38rX for ; Sun, 15 May 2016 23:18:22 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F40712B03F for ; Sun, 15 May 2016 23:18:22 -0700 (PDT)
Received: from [192.168.1.109] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1C2DE22E253; Mon, 16 May 2016 02:18:13 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: <83E3D82D-1291-45F6-AD0C-EFA704175886@gmail.com>
Date: Mon, 16 May 2016 16:18:10 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <31BA99B2-F557-4CF4-8F6F-A006703CF664@gmail.com>  <83E3D82D-1291-45F6-AD0C-EFA704175886@gmail.com>
To: Yoav Nir 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , Ted Hardie , quic@ietf.org, Christian Huitema 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 06:18:24 -0000

> On 16 May 2016, at 4:21 AM, Yoav Nir  wrote:
>=20
>> "Note that consensus is required both for changes to the current =
protocol mechanisms and retention of current mechanisms. In particular, =
because something is in the initial document set does not imply that =
there is consensus around the feature or around how it is specified."
>>=20
>> That's taken from how the HTTPbis work handled the input documents to =
HTTP/2.
>=20
> That=E2=80=99s fine. I think what=E2=80=99s bothering me is that the =
experiment, the (potential) working group and the output product are all =
called the same thing.  In HTTPbis it was clearer that SPDY was the =
experiment and HTTP/2 was the output.

I tend to agree with Yoav's concern; it will be easier to manage =
perceptions both inside and outside of the IETF if there's a clear =
distinction between the experiment and the standard (it was certainly =
helpful in H2).

That said, I fear the inevitable bikeshed.

Cheers,

--
Mark Nottingham   https://www.mnot.net/





From nobody Mon May 16 02:18:57 2016
Return-Path: 
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 E50AC12D0A2 for ; Mon, 16 May 2016 02:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 3X8cAUr6WmZt for ; Mon, 16 May 2016 02:18:53 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A101412D0B7 for ; Mon, 16 May 2016 02:18:51 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-bf-573990792f9d
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 89.84.12926.97099375; Mon, 16 May 2016 11:18:50 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.166]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Mon, 16 May 2016 11:18:49 +0200
From: Salvatore Loreto 
To: Jana Iyengar 
Thread-Topic: [QUIC] Draft charter
Thread-Index: AQHRrXALHarJ2uenb0CbuK/2CiPGXZ+6YoJwgACF6oCAAF1DsA==
Date: Mon, 16 May 2016 09:18:49 +0000
Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A60D98DEC@ESESSMB109.ericsson.se>
References:  <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_2B9B48179856DC4FA00C93C79EB7E64A60D98DECESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7h27VBMtwgxf9zBZNn/sYLSYdXchi 0bOA26Jxrp0Di8fOWXfZPRZsKvVYsuQnk0frjr/sASxRXDYpqTmZZalF+nYJXBln57xiKpg3 m7Fi6zvjBsae6YxdjJwcEgImEttWH2WDsMUkLtxbD2RzcQgJHGGU2Hr/HwuEs4RR4vjKfiaQ KjYBM4nnD7cwg9giAooST39+ZQexmQUKJV5/fwwWFwaKrzh3kAmiRkli1ZVrbBC2k8SRBz1g cRYBVYkvp5eygti8Ar4Szf9vQy27zShx+ec5sEGcAoESHzbsAWtmBDrv+6k1TBDLxCVuPZnP BHG2gMSSPeeZIWxRiZeP/7FC2IoSO8+2M0PU50usvrOeCWKZoMTJmU9YJjCKzkIyahaSsllI ymYxcgDFNSXW79KHKFGUmNL9kB3C1pBonTOXHVl8ASP7KkbR4tTipNx0I2O91KLM5OLi/Dy9 vNSSTYzAqDy45bfqDsbLbxwPMQpwMCrx8C7QtAwXYk0sK67MPcQowcGsJMKb2AUU4k1JrKxK LcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnVwKjd8DIi1C5TJXYTU5dX /Q11nQ7rGNtr/MeX/xPc9WerjNA033T9xOYCUSZ1xyVld36tWJiWk3b+XMu3OYtm3YhYbf32 76uXFg8nRu21Nys7zPfnTMQV5yUvzr+ru3z9a93iG2+V9j/cXyGiv9HT86Kh72bdKv4Xee+m XHbaNfdmwFPps9rz7cWVWIozEg21mIuKEwFqWEZUxgIAAA==
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 09:18:55 -0000

--_000_2B9B48179856DC4FA00C93C79EB7E64A60D98DECESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpUaHJ1DQpidXQgd2l0aCB0aGUgZGlmZmVyZW5jZSB0aGF0IHRoZSB3b3JrIGJlZW4gZG9uZSBz
byBmYXIgaW4gVFNWQVJFQSAoaS5lLiBTQ1RQIGFuZCBNdWx0aXBhdGggVENQKSBpcyBmb3IgY29u
bmVjdGlvbiBvcmllbnRlZA0KdHJhbnNwb3J0IHByb3RvY29scy4NCmRvbuKAmXQgZ2V0IG1lIHdy
b25nIEkgZG8gdGhpbmsgYSBicmFuZCBuZXcgdHJhbnNwb3J0IHByb3RvY29sIHNob3VsZCAoYWN0
dWFsbHkgaGFzIHRvKSBpbmNsdWRlIHRoZSBtdWx0aXBhdGggZmFjaWxpdHkgYW5kIGhhdmUgaXQN
CmFjdHVhbGx5IGFzIGEgbmF0aXZlIG9uZS4gIEluZGVlZCBJIHdvdWxkIGxpa2UgdG8gc2VlIHRo
ZSBtdWx0aXBhdGggaXRlbSBleHBhbmRlZCBhbmQgZXhwbGFpbmVkIG1vcmUgaW4gdGhlIGNoYXJ0
ZXIuDQoNCk15IGNvbW1lbnQgd2FzIG1haW5seSBmb3IgRkVDLCBhbmQgbW92aW5nIHRoaXMgaXRl
bSB0byByZXF1aXJpbmcgYSByZS1jaGFydGVyIHdvdWxkIG1ha2UgbWUgbW9yZSBjb21mb3J0YWJs
ZSB3aXRoDQp0aGUgY2hhcnRlciBmb3IgdGhlIEJvRg0KDQoNCg0KRnJvbTogSmFuYSBJeWVuZ2Fy
IFttYWlsdG86anJpQGdvb2dsZS5jb21dDQpTZW50OiBkZW4gMTYgbWFqIDIwMTYgMDc6MTkNClRv
OiBTYWx2YXRvcmUgTG9yZXRvDQpDYzogVGVkIEhhcmRpZTsgcXVpY0BpZXRmLm9yZzsgQ2hyaXN0
aWFuIEh1aXRlbWENClN1YmplY3Q6IFJlOiBbUVVJQ10gRHJhZnQgY2hhcnRlcg0KDQpUbyBjb25j
ZXJucyBhYm91dCBtdWx0aXBhdGggaW4gdGhlIGZvdXJ0aCBhcmVhOiBUU1ZBUkVBIGhhcyBkb25l
IG11bHRpcGF0aCBpbiBTQ1RQIGFuZCBpbiBNUFRDUC4gTVBUQ1AgaXMgc2VlaW5nIGRlcGxveW1l
bnQgLS0gYWxiZWl0IHNsb3dseSBhbmQgaW4gbGltaXRlZCBxdWFydGVycyAtLSBhbmQgSSB3b3Vs
ZCBhcmd1ZSB0aGF0IGV4cGVjdGluZyBtdWx0aXBhdGggdG8gYmUgYSBmYWNpbGl0eSBhdmFpbGFi
bGUgYXMgYSBwYXJ0IG9mIGEgYnJhbmQgbmV3IHRyYW5zcG9ydCBzZWVtcyBxdWl0ZSByZWFzb25h
YmxlLg0KDQpNZWNoYW5pc21zIGZvciBlbmFibGluZyBGRUMgYXJlIGEgYml0IG1vcmUgZXhwZXJp
bWVudGFsLCBzbyBJJ20gbW9yZSBjb21mb3J0YWJsZSBtb3ZpbmcgdGhpcyBpdGVtIHRvIHJlcXVp
cmluZyBhIHJlLWNoYXJ0ZXIuDQoNCk9uIFN1biwgTWF5IDE1LCAyMDE2IGF0IDEyOjMyIFBNLCBT
YWx2YXRvcmUgTG9yZXRvIDxzYWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNvbTxtYWlsdG86c2Fs
dmF0b3JlLmxvcmV0b0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpIFRlZA0KDQpJIHRoaW5rcyB0
aGUgY2hhcnRlciBsb29rcyBPSywNCkhvd2V2ZXIgSSB0ZW5kIHRvIGFncmVlIHdpdGggcHJldmlv
dXMgY29tbWVudHMNCnRoYXQgdGhlIHdvcmsgYXQgbW9tZW50IHNob3VsZCByZWFsbHkgZm9jdXNl
ZCBvbiAobmFycm93ZWQgdG8pIHRoZSBmaXJzdCBhbmQgc2Vjb25kIHBhcnRzIHRvIHRoZSBkZXNp
Z24gb2YgUVVJQyBhcyB0cmFuc3BvcnQgcHJvdG9jb2wNCg0KZm9yIHRoZSB0aGlyZCBmb2N1cw0K
SSBoYXZlIHNvbWUgY29uY2VybnMgb2YgdGhlIHdnIGRvaW5nIGF0IHNhbWUgdGltZSB0aGUgd29y
ayBmb3IgZGVzaWduaW5nIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgYW5kIGRlc2NyaWJpbmcNCuKA
nG1hcHBpbmdzIGJldHdlZW4gc3BlY2lmaWMgYXBwbGljYXRpb25z4oCZIHNlbWFudGljcyBhbmQg
dGhlIHRyYW5zcG9ydCBmYWNpbGl0aWVzIG9mIFFVSUPigJ0NCg0KRm9yIHRoZSBmb3VydGggZm9j
dXMgSSBkb27igJl0IHRoaW5rIHRoZSBleHBlcmltZW50YXRpb24gaGFzIHNob3dlZCBzbyBmYXIg
ZW5vdWdoIGludGVyZXN0aW5nIHJlc3VsdHMgZGVzZXJ2aW5nIHRvIGJlIHN0YW5kYXJkaXplZC4N
Cg0KQ2hlZXJzDQpTYWx2YXRvcmUNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0Bp
ZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFRlZCBI
YXJkaWUNClNlbnQ6IGRlbiAxNCBtYWogMjAxNiAwMToyNw0KVG86IHF1aWNAaWV0Zi5vcmc8bWFp
bHRvOnF1aWNAaWV0Zi5vcmc+OyBKYW5hIEl5ZW5nYXI7IENocmlzdGlhbiBIdWl0ZW1hDQpTdWJq
ZWN0OiBbUVVJQ10gRHJhZnQgY2hhcnRlcg0KDQpIb3dkeSwNCkFzIHBhcnQgb2YgdGhlIEJvRiBw
cmVwYXJhdGlvbiwgd2UgcHV0IHRvZ2V0aGVyIGEgc3RhYiBhdCBhIGRyYWZ0IGNoYXJ0ZXIuICBJ
dCdzIGF2YWlsYWJsZSBhcyBodG1sIGFuZCBtYXJrZG93biBvbiBnaXRodWIgYXQ6DQoNCmh0dHBz
Oi8vZ2l0aHViLmNvbS9JRVRGLVFVSUMvQ2hhcnRlcg0KSSd2ZSBhdHRhY2hlZCB0aGUgSFRNTCB2
ZXJzaW9uIGFzIHdlbGwuDQpJdCB3b3VsZCBiZSBncmVhdCB0byBoYXZlIHNvbWUgb2YgdGhlIGRp
c2N1c3Npb24gb24gdGhlIGxpc3QgYmVmb3JlIHRoZSBCb0YuICBDb21tZW50cyB0byB0aGUgbGlz
dCBvciBpc3N1ZXMvcHVsbCByZXF1ZXN0cyBhdCB0aGUgZ2l0aHViIHJlcG8gYXJlIHdlbGNvbWUu
ICBXZSB3aWxsIHBlcmlvZGljYWxseSByZWZsZWN0IGFueSBpc3N1ZXMgb3Igc3VnZ2VzdGlvbiBm
cm9tIHRoZSBSZXBvIGJhY2sgdG8gdGhlIGxpc3QsIGJ1dCB0aGlzIHdpbGwgYmUgbWFudWFsLCBz
byBleHBlY3Qgc29tZSBsYWcuDQoNCnJlZ2FyZHMsDQpUZWQNCg0K

--_000_2B9B48179856DC4FA00C93C79EB7E64A60D98DECESESSMB109erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3
RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v
biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5
Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2Lldv
cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy
NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh
cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+
DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n
PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj
dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaHJ1
DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YnV0IHdpdGggdGhlIGRpZmZlcmVuY2Ug
dGhhdCB0aGUgd29yayBiZWVuIGRvbmUgc28gZmFyIGluIFRTVkFSRUEgKGkuZS4gU0NUUCBhbmQg
TXVsdGlwYXRoIFRDUCkgaXMgZm9yIGNvbm5lY3Rpb24gb3JpZW50ZWQNCjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj50cmFuc3BvcnQgcHJvdG9jb2xzLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5kb27igJl0IGdldCBtZSB3cm9uZyBJIGRvIHRoaW5rIGEgYnJhbmQgbmV3IHRy
YW5zcG9ydCBwcm90b2NvbCBzaG91bGQgKGFjdHVhbGx5IGhhcyB0bykgaW5jbHVkZSB0aGUgbXVs
dGlwYXRoIGZhY2lsaXR5IGFuZCBoYXZlIGl0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PmFjdHVhbGx5IGFzIGEgbmF0aXZlIG9uZS4gJm5ic3A7SW5kZWVkIEkgd291bGQgbGlrZSB0byBz
ZWUgdGhlIG11bHRpcGF0aCBpdGVtIGV4cGFuZGVkIGFuZCBleHBsYWluZWQgbW9yZSBpbiB0aGUg
Y2hhcnRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IGNvbW1lbnQgd2FzIG1haW5seSBmb3IgRkVDLCBhbmQgbW92
aW5nIHRoaXMgaXRlbSB0byByZXF1aXJpbmcgYSByZS1jaGFydGVyIHdvdWxkIG1ha2UgbWUgbW9y
ZSBjb21mb3J0YWJsZSB3aXRoDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhlIGNo
YXJ0ZXIgZm9yIHRoZSBCb0Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21d
DQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDE2IG1haiAyMDE2IDA3OjE5PGJyPg0KPGI+VG86PC9i
PiBTYWx2YXRvcmUgTG9yZXRvPGJyPg0KPGI+Q2M6PC9iPiBUZWQgSGFyZGllOyBxdWljQGlldGYu
b3JnOyBDaHJpc3RpYW4gSHVpdGVtYTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1FVSUNdIERy
YWZ0IGNoYXJ0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VG8gY29uY2VybnMgYWJvdXQgbXVsdGlwYXRoIGluIHRoZSBmb3VydGggYXJlYTogVFNWQVJFQSBo
YXMgZG9uZSBtdWx0aXBhdGggaW4gU0NUUCBhbmQgaW4gTVBUQ1AuIE1QVENQIGlzIHNlZWluZyBk
ZXBsb3ltZW50IC0tIGFsYmVpdCBzbG93bHkgYW5kIGluIGxpbWl0ZWQgcXVhcnRlcnMgLS0gYW5k
IEkgd291bGQgYXJndWUgdGhhdCBleHBlY3RpbmcgbXVsdGlwYXRoIHRvIGJlIGEgZmFjaWxpdHkg
YXZhaWxhYmxlDQogYXMgYSBwYXJ0IG9mIGEgYnJhbmQgbmV3IHRyYW5zcG9ydCBzZWVtcyBxdWl0
ZSByZWFzb25hYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TWVj
aGFuaXNtcyBmb3IgZW5hYmxpbmcgRkVDIGFyZSBhIGJpdCBtb3JlIGV4cGVyaW1lbnRhbCwgc28g
SSdtIG1vcmUgY29tZm9ydGFibGUgbW92aW5nIHRoaXMgaXRlbSB0byByZXF1aXJpbmcgYSByZS1j
aGFydGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBNYXkgMTUsIDIwMTYgYXQgMTI6MzIgUE0sIFNh
bHZhdG9yZSBMb3JldG8gJmx0OzxhIGhyZWY9Im1haWx0bzpzYWx2YXRvcmUubG9yZXRvQGVyaWNz
c29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNhbHZhdG9yZS5sb3JldG9AZXJpY3Nzb24uY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFRl
ZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmtzIHRoZSBjaGFydGVyIGxvb2tzIE9LLDwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIgSSB0ZW5kIHRvIGFncmVlIHdpdGggcHJldmlv
dXMgY29tbWVudHMNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRoYXQgdGhlIHdv
cmsgYXQgbW9tZW50IHNob3VsZCByZWFsbHkgZm9jdXNlZCBvbiAobmFycm93ZWQgdG8pIHRoZSBm
aXJzdCBhbmQgc2Vjb25kIHBhcnRzIHRvIHRoZQ0KIGRlc2lnbiBvZiBRVUlDIGFzIHRyYW5zcG9y
dCBwcm90b2NvbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmZvciB0aGUgdGhpcmQgZm9jdXM8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5JIGhhdmUgc29tZSBjb25jZXJucyBvZiB0aGUgd2cgZG9pbmcg
YXQgc2FtZSB0aW1lIHRoZSB3b3JrIGZvciBkZXNpZ25pbmcgdGhlIHRyYW5zcG9ydCBwcm90b2Nv
bCBhbmQNCiBkZXNjcmliaW5nIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnG1h
cHBpbmdzIGJldHdlZW4gc3BlY2lmaWMgYXBwbGljYXRpb25z4oCZIHNlbWFudGljcyBhbmQgdGhl
IHRyYW5zcG9ydCBmYWNpbGl0aWVzIG9mIFFVSUPigJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgdGhlIGZv
dXJ0aCBmb2N1cyBJIGRvbuKAmXQgdGhpbmsgdGhlIGV4cGVyaW1lbnRhdGlvbiBoYXMgc2hvd2Vk
IHNvIGZhciBlbm91Z2ggaW50ZXJlc3RpbmcgcmVzdWx0cw0KIGRlc2VydmluZyB0byBiZSBzdGFu
ZGFyZGl6ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+U2FsdmF0b3JlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4gUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm
IE9mIDwvYj5UZWQgSGFyZGllPGJyPg0KPGI+U2VudDo8L2I+IGRlbiAxNCBtYWogMjAxNiAwMToy
Nzxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5xdWljQGlldGYub3JnPC9hPjsgSmFuYSBJeWVuZ2FyOyBDaHJpc3RpYW4gSHVpdGVt
YTxicj4NCjxiPlN1YmplY3Q6PC9iPiBbUVVJQ10gRHJhZnQgY2hhcnRlcjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206
MTIuMHB0Ij5Ib3dkeSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5B
cyBwYXJ0IG9mIHRoZSBCb0YgcHJlcGFyYXRpb24sIHdlIHB1dCB0b2dldGhlciBhIHN0YWIgYXQg
YSBkcmFmdCBjaGFydGVyLiZuYnNwOyBJdCdzIGF2YWlsYWJsZSBhcyBodG1sIGFuZCBtYXJrZG93
biBvbiBnaXRodWIgYXQ6PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL0lF
VEYtUVVJQy9DaGFydGVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL0lFVEYt
UVVJQy9DaGFydGVyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi
PkkndmUgYXR0YWNoZWQgdGhlIEhUTUwgdmVyc2lvbiBhcyB3ZWxsLiZuYnNwOw0KPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IHdvdWxkIGJl
IGdyZWF0IHRvIGhhdmUgc29tZSBvZiB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBiZWZvcmUg
dGhlIEJvRi4mbmJzcDsgQ29tbWVudHMgdG8gdGhlIGxpc3Qgb3IgaXNzdWVzL3B1bGwgcmVxdWVz
dHMgYXQgdGhlIGdpdGh1YiByZXBvIGFyZSB3ZWxjb21lLiZuYnNwOyBXZSB3aWxsIHBlcmlvZGlj
YWxseQ0KIHJlZmxlY3QgYW55IGlzc3VlcyBvciBzdWdnZXN0aW9uIGZyb20gdGhlIFJlcG8gYmFj
ayB0byB0aGUgbGlzdCwgYnV0IHRoaXMgd2lsbCBiZSBtYW51YWwsIHNvIGV4cGVjdCBzb21lIGxh
Zy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+cmVnYXJkcyw8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UZWQ8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_2B9B48179856DC4FA00C93C79EB7E64A60D98DECESESSMB109erics_--


From nobody Mon May 16 02:30:12 2016
Return-Path: 
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 D3AB712D0A5 for ; Mon, 16 May 2016 02:30:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.027
X-Spam-Level: 
X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 jRtUSZWntBMq for ; Mon, 16 May 2016 02:30:08 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C7B9128E19 for ; Mon, 16 May 2016 02:30:08 -0700 (PDT)
Received: from [192.168.1.100] (p508F0FEB.dip0.t-ipconnect.de [80.143.15.235]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 99DBB721E281E; Mon, 16 May 2016 11:30:04 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Tuexen 
In-Reply-To: 
Date: Mon, 16 May 2016 11:30:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <039E7D03-E38D-4FE0-A303-D5DBDA43C5C0@lurchi.franken.de>
References:  <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se> 
To: Jana Iyengar 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Salvatore Loreto , Christian Huitema , Ted Hardie , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 09:30:11 -0000

> On 16 May 2016, at 07:18, Jana Iyengar  wrote:
>=20
> To concerns about multipath in the fourth area: TSVAREA has done =
multipath in SCTP and in MPTCP.=20
There is a difference here:
* For SCTP this work was done only for redundancy, not for load sharing. =
The CMT work
  wasn't accepted as a work item in TSVWG.
* For MTPTCP, multipath for load sharing and redundancy was considered.
> MPTCP is seeing deployment -- albeit slowly and in limited quarters -- =
and I would argue that=20
The initial deployment target for SCTP are signalling networks. As far =
as I know,
multipath support for redundancy is deployed there.
As far as I know the deployment for MPTCP within the Siri context also =
focuses on
the redundancy part. Other deployments use the load sharing part.

Another use-case, where MPTCP is used, is the one of transport layer =
mobility, where
the end-point can change its IP-addresses and/or port numbers. This is =
supported by
MPTCP, SCTP with dynamic address reconfiguration (including UDP =
encapsulation) and also by QUIC.

Best regards
Michael
> expecting multipath to be a facility available as a part of a brand =
new transport seems quite reasonable.
>=20
> Mechanisms for enabling FEC are a bit more experimental, so I'm more =
comfortable moving this item to requiring a re-charter.
>=20
>=20
> On Sun, May 15, 2016 at 12:32 PM, Salvatore Loreto =
 wrote:
> Hi Ted
>=20
> =20
>=20
> I thinks the charter looks OK,
>=20
> However I tend to agree with previous comments
>=20
> that the work at moment should really focused on (narrowed to) the =
first and second parts to the design of QUIC as transport protocol
>=20
> =20
>=20
> for the third focus
>=20
> I have some concerns of the wg doing at same time the work for =
designing the transport protocol and describing
>=20
> =E2=80=9Cmappings between specific applications=E2=80=99 semantics and =
the transport facilities of QUIC=E2=80=9D
>=20
> =20
>=20
> For the fourth focus I don=E2=80=99t think the experimentation has =
showed so far enough interesting results deserving to be standardized.
>=20
> =20
>=20
> Cheers
>=20
> Salvatore
>=20
> =20
>=20
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ted Hardie
> Sent: den 14 maj 2016 01:27
> To: quic@ietf.org; Jana Iyengar; Christian Huitema
> Subject: [QUIC] Draft charter
>=20
> =20
>=20
> Howdy,
>=20
> As part of the BoF preparation, we put together a stab at a draft =
charter.  It's available as html and markdown on github at:
>=20
> https://github.com/IETF-QUIC/Charter
>=20
> I've attached the HTML version as well.=20
>=20
> It would be great to have some of the discussion on the list before =
the BoF.  Comments to the list or issues/pull requests at the github =
repo are welcome.  We will periodically reflect any issues or suggestion =
from the Repo back to the list, but this will be manual, so expect some =
lag.
>=20
> =20
>=20
> regards,
>=20
> Ted
>=20
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic


From nobody Mon May 16 02:32:38 2016
Return-Path: 
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 2286D12B069 for ; Mon, 16 May 2016 02:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 ne0MsG4eHcAd for ; Mon, 16 May 2016 02:32:35 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E459B128E19 for ; Mon, 16 May 2016 02:32:34 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 12CE7FEF for ; Mon, 16 May 2016 11:32:33 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QsWzuwX1fDaN for ; Mon, 16 May 2016 11:32:30 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 16 May 2016 11:32:32 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 726CA20050 for ; Mon, 16 May 2016 11:32:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uqY_u529QfNJ for ; Mon, 16 May 2016 11:32:31 +0200 (CEST)
Received: from exchange.jacobs-university.de (shubcas03.jacobs.jacobs-university.de [10.70.0.153]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id E45B520047 for ; Mon, 16 May 2016 11:32:31 +0200 (CEST)
Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS05.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0279.002; Mon, 16 May 2016 11:32:31 +0200
From: "Bajpai, Vaibhav" 
To: "quic@ietf.org" 
Thread-Topic: graceful fallback to tcp
Thread-Index: AQHRr1XeBPEH7AqQy0SZSM/ZAZ9YaQ==
Date: Mon, 16 May 2016 09:32:30 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.50.203.30]
Content-Type: multipart/signed; boundary="Apple-Mail=_BA4817B7-77CD-42FA-A2D5-1E76B4FC99C6"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: 
Cc: "Bajpai, Vaibhav" 
Subject: [QUIC] graceful fallback to tcp
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 09:32:37 -0000

--Apple-Mail=_BA4817B7-77CD-42FA-A2D5-1E76B4FC99C6
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello,

I have question on draft-tsvwg-quic-protocol-02 [a]

>     When a client receives a Alternate-Protocol header advertising =
QUIC, it can
>     then attempt to use QUIC for future secure connections on that =
domain.  Since
>     middleboxes and/or firewalls can block QUIC and/or UDP =
communication, a client
>     should implement a graceful fallback to TCP when QUIC reachability =
is broken.

This ^ hints towards a scheme similar to HE [RFC 6555] for racing TCP =
and UDP
connections. What timer value is used for a graceful fallback in QUIC
implementations (such as Google Chrome) today?

[a] https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02

Thanks!

Best, Vaibhav

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Vaibhav Bajpai
www.vaibhavbajpai.com

Room 91, Research I
School of Engineering and Sciences
Jacobs University Bremen, Germany
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--Apple-Mail=_BA4817B7-77CD-42FA-A2D5-1E76B4FC99C6
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJXOZOuAAoJEHR3XKwTWKOZ50cH/A+IGYlsSEoabbBsuquEprsG
FqqXQmO6M6iAPHBuHg+0iUe3yLSjNKC8hTF5/u980TUjxUSQokUl/nNaVw+Uupxu
ewuqJMBIanb0oPpxoHkADuEabFAZG/Hj1VOOQOoL+Xyff4TyBFgijH85boByjXqI
xz8aPLZQdNRCB7XsGH2XH5c8mQ/FGNx4u8l4SqUVHH/wTRlML1BAA4feB9MH9AvT
izTc3hPAQBo947fyis5CkqKW4vfqYv/rolyQwtp9DQfCGXMhnmONtmlKtIJFMmW+
dnuZGw6irYBPJIZdoXnhoZskg81U0BDJwIsBQMJLRBpCJIQmFSllorvvUzMXSOc=
=hIsB
-----END PGP SIGNATURE-----

--Apple-Mail=_BA4817B7-77CD-42FA-A2D5-1E76B4FC99C6--


From nobody Mon May 16 09:00:43 2016
Return-Path: 
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 ACD3912D0FA for ; Mon, 16 May 2016 09:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 kn9XA_fheZf9 for ; Mon, 16 May 2016 09:00:40 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 ED58312D124 for ; Mon, 16 May 2016 09:00:26 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id j74so165998811ywg.1 for ; Mon, 16 May 2016 09:00:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=F3HjO0R0kz7pZyzMtuPoLfeZf+RJ4DwSngviy3t5Xto=; b=BBsVmhpJ25lBuD1brBzljarutohyUPey857NYkXxjzZ2xjG8mibSTrjR8z9c4WUAh4 wrbIjMcrGmOFI1Cw/4wnnpmiIwayam8XD06v0+uu3k6tV1WSe5sFQmh2koyZa0wuNTsL bG8RShR+rO0hLOPXiu/l+9eV9lmGrryGGNLPTzqBpog7ufOmM1gwbKVgrQDOnbBkQFS7 QljN1DUI2l3euZQizn4dUxQNtOI+6ApgdTIxQxWdog2sNdXXQWEYV+kAqrO4fowE69UX 7iFMUhqw8qXwT8dcKUdNxsBCUVne/L24y55Ljwa+mjaGl7TaTMrDgbCdIiX2wO1Q7rdq zUCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=F3HjO0R0kz7pZyzMtuPoLfeZf+RJ4DwSngviy3t5Xto=; b=X98P2FCYRR99NaHyTXrIRT+nigl9LaI1XBQqHqh3hpVr373AGZG4g5jSaUtJXCGzBW acSR1GPzcgFQjMLslZKTr3Bw88KvtF9PdKZRvMnDPEpq1y23X5TgldraBeRYwnC2E/jb d2nYW2+tPKAKdVYuvObNOX1HXk6TE4eunhRSAOo2/NMEDukSBkBEQp8FNuUXWjw2Wshr V1mXD5qeQMrO+GYJYMaCuS7XS5GkZLJMCUFrZcPdNHGh/T9Hp1Ad+1H0m515gJq3rGet z79NmmTfyU8TX9GYI0AEQKVYtyZCYY5Lnv9eHJaNd7jNjFgq8cMZ2q4nunVIJdPutBf6 ffCQ==
X-Gm-Message-State: AOPr4FUOkmj9MSiwncnem8WdfKVZiyfbl236Z0rRM4Gq4C62IbyJFqbQjiid22QX5rua+1DybUlZ00HTNSkbUbwO
MIME-Version: 1.0
X-Received: by 10.37.96.130 with SMTP id u124mr12364682ybb.81.1463414426076; Mon, 16 May 2016 09:00:26 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Mon, 16 May 2016 09:00:25 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 16 May 2016 09:00:25 -0700
Message-ID: 
From: Jana Iyengar 
To: =?UTF-8?Q?G=C3=B6ran_Eriksson_AP?= 
Content-Type: multipart/alternative; boundary=001a1143e93007471a0532f7b922
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" 
Subject: Re: [QUIC] Scope of multi-path WAS: Re: Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 16:00:42 -0000

--001a1143e93007471a0532f7b922
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi G=C3=B6ran,

The thinking was to cover the functional equivalent of SCTP or MPTCP
multipath, which is a relatively known scope in the IETF context. I'm happy
to add more text if folks think that being more explicit here is useful.

- jana

On Sun, May 15, 2016 at 3:00 AM, G=C3=B6ran Eriksson AP <
goran.ap.eriksson@ericsson.com> wrote:

> >
> >
> >
> >
> >It would be great to have some of the discussion on the list before the
> >BoF.
>
>
> Hi!
>
> Have a question concerning the scope of =E2=80=9Cmulti-path=E2=80=9D work=
:
>
> The full area of multi-path is rather big, especially if combined with
> mobility and the possibility to migrate some but not all flows the
> =E2=80=9Capplication=E2=80=9D using a =E2=80=9Crich API=E2=80=9D to provi=
de hints to the transport middle
> ware.
>
> The current charter text is not so precise on the scope and ambition on
> multi-path.
>
> Is the scope perhaps implicitly limited to existing multi-path TCP
> realisation/usage?
>
> Regards
> G=C3=B6ran
>
>
>
> >
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>

--001a1143e93007471a0532f7b922
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi=C2=A0G=C3=B6ran,

The thinking was to cover the functional equivalent of S=
CTP or MPTCP multipath, which is a relatively known scope in the IETF conte=
xt. I'm happy to add more text if folks think that being more explicit =
here is useful.

- jana

On Sun, May 15, 2016 =
at 3:00 AM, G=C3=B6ran Eriksson AP <goran.ap.eriksson@ericsso=
n.com> wrote:
>

>

>

>

>It would be great to have some of the discussion on the list before the=


>BoF.





Hi!



Have a question concerning the scope of =E2=80=9Cmulti-path=E2=80=9D work:<=
br>


The full area of multi-path is rather big, especially if combined with

mobility and the possibility to migrate some but not all flows the

=E2=80=9Capplication=E2=80=9D using a =E2=80=9Crich API=E2=80=9D to provide=
 hints to the transport middle

ware.



The current charter text is not so precise on the scope and ambition on

multi-path.



Is the scope perhaps implicitly limited to existing multi-path TCP

realisation/usage?



Regards

G=C3=B6ran







>



_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--001a1143e93007471a0532f7b922--


From nobody Mon May 16 11:52:49 2016
Return-Path: 
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 1A8E912D944 for ; Mon, 16 May 2016 11:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 L7LvaztFuUrD for ; Mon, 16 May 2016 11:52:46 -0700 (PDT)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 714CD12D943 for ; Mon, 16 May 2016 11:52:46 -0700 (PDT)
Received: by mail-io0-x230.google.com with SMTP id i75so216139176ioa.3 for ; Mon, 16 May 2016 11:52:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fglL7gvY7a7yJ8G9YB9VZPeYK9WXvJji16C0k+aAyVE=; b=xa/x/R6u5xXTF787Mx5aD9M8d5WbEP4NKODto9AMnKFm9P/PyLLmX2Db05Qeqjt0Jk iS+RmfXhzNvTLVJ84H2ifa1JZtQluRemvU7oPteNHQI3bOcfkTNztRa8gRQOIHg0f/Nx 1Xp3Y+RvkzegQ0hh9wDezzahJp3uIUbiVx2g/6Ax42vQCwJfe+XjqydkAi40fKD/F6AZ S5/KCVQ7yK17WUe3lz3zV1KtmFh1ZcciIbhM1sysqGRnUxawrDr5uG55eHj6oiAFqHHU NxGmSjzUCd5Y+bm75gRqlnbCi4GchEIYAfqBXWloztV/wEInCUST6GpLT/bAdf7TFlQL mZfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fglL7gvY7a7yJ8G9YB9VZPeYK9WXvJji16C0k+aAyVE=; b=Iu+vxDc3fGAdWQy16poa5uxXwGOqCTGZ3WT9x3R8wb4d+lC+MUfM3w6wtIsrXbKkX/ 9HKBiIiDKHavTFzFGxTGh9FnogpgVn/1ldHRkF5hq4yB+4Lrk9/Dg1d/sdMxEM50w8Ib rYsr2R27xclyBpj2wRCZOHf///mYPdH7jM/37FRelmg8SWeotOAn4mLnUORlJKB1/UY+ n59h3mXB150tQFVBs2yMpJi2nU/33zzBXBlR/rroDyKjhDsbtR1uL6iZ/69eBdlj0umw bIk3gLJsIoY/+++tsPguo6UxQA9VE8F3jagpaTKsG5Co5s0LPjNiLloEfw4xWLBvGSQ1 8LlA==
X-Gm-Message-State: AOPr4FUS9dV5J6izcAJdTefTslafLCgMRVPVUgPQ6RVdu4XQ6svZXh2jyfLYkWFT8C7Zcr/kNdiiFK8EnmkB4A==
MIME-Version: 1.0
X-Received: by 10.107.59.130 with SMTP id i124mr17971732ioa.107.1463424765792;  Mon, 16 May 2016 11:52:45 -0700 (PDT)
Received: by 10.107.8.84 with HTTP; Mon, 16 May 2016 11:52:45 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 16 May 2016 22:52:45 +0400
Message-ID: 
From: "Maxim Proshin [GMAIL]" 
To: Ted Hardie 
Content-Type: multipart/alternative; boundary=001a114f8758521be60532fa2122
Archived-At: 
Cc: Jana Iyengar , quic@ietf.org, Christian Huitema 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 18:52:48 -0000

--001a114f8758521be60532fa2122
Content-Type: text/plain; charset=UTF-8

Hi,

There is nothing about QUIC API in the charter. Will the group work on it?

Best regards,
Maxim

On Sat, May 14, 2016 at 3:26 AM, Ted Hardie  wrote:

> Howdy,
>
> As part of the BoF preparation, we put together a stab at a draft
> charter.  It's available as html and markdown on github at:
>
> https://github.com/IETF-QUIC/Charter
>
> I've attached the HTML version as well.
>
> It would be great to have some of the discussion on the list before the
> BoF.  Comments to the list or issues/pull requests at the github repo are
> welcome.  We will periodically reflect any issues or suggestion from the
> Repo back to the list, but this will be manual, so expect some lag.
>
> regards,
>
> Ted
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>


-- 
BR, Maxim

--001a114f8758521be60532fa2122
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

There is nothing about QUIC API in =
the charter. Will the group work on it?

Best regar=
ds,
Maxim

On Sat, May 14, 2016 at 3:26 AM, Ted Hardie <ted.ietf@gmail=
.com> wrote:
Howdy,

As part of the BoF preparation, =
we put together a stab at a draft charter.=C2=A0 It's available as html=
 and markdown on github at:

https://github.com/IETF-QUIC/Charter

=

I've attached the HTML version as well.=C2=A0 

=
It would be great to have some of the discussion on the list before the BoF=
.=C2=A0 Comments to the list or issues/pull requests at the github repo are=
=20
welcome.=C2=A0 We will periodically reflect any issues or suggestion from t=
he
 Repo back to the list, but this will be manual, so expect some lag.
<=
div>
regards,

Ted


_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





-- 
BR, Maxim



--001a114f8758521be60532fa2122--


From nobody Mon May 16 13:33:12 2016
Return-Path: 
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 0D44512D1D7 for ; Mon, 16 May 2016 13:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 V7Vr0sHAXrWh for ; Mon, 16 May 2016 13:33:10 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 D307212D1C2 for ; Mon, 16 May 2016 13:33:09 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id i75so219572408ioa.3 for ; Mon, 16 May 2016 13:33:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=o1mbFpUyvFDy0YgOYqFbru+WrkzHnSSVxTezf48CbFw=; b=MI/wso9GZxbUZpjV2jNfLtMuPPbJn5f7GU4nTiS2zcKuxpFjwpz4RozWq5iFqP2z3T cyq4fVdgU0rvgKEeyjDvGyhMnPiL+Zsfe8XFy7g6ki//3xoXy1xdfarGuvSbekyhOHXI qAoVIUy7nsqmpwTM/UGVuvvIgTO7Z9sCIlUSYm4YYFrQnSExaBatj93UHDUAXJgoIrY8 cB/GjpNCkLhdfUz+qOt/61U+0RLDX4Luh82wpANL5KwyBlJQYtLtMu7uke6Vtz7pJdQP 42Wq5F/qKQTYuIzElbHuv5rSZXPfIuqPgdYQovJ5N2sXvG9m+0Ne/fHaA7H0ezrtOODG j8hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=o1mbFpUyvFDy0YgOYqFbru+WrkzHnSSVxTezf48CbFw=; b=V4rpfHoRHm95bxsK6dNbsRKXsRr1NNroPHZFixWQuqtFcnF5pclpvGFqxCqjgqyr70 lzYvLT1QOCO/+v3PtUfwryHtf6FQFJTpjBaFqTGWnneYD9q3FzBGarJLN8vulaHU6eIi PB9cAWD7AgpnqCgMXnsVAieFf03cz+/c7tn/wiQyENdTqlXGI8r8/k0pjxSUDSwDKvYv dlfTA6bR00LYsBTo1fEilqlmRGY8HvQ5pqy+J7p2uzMMNz3kX/ZpW8aWGBhLfPw6i4nf 3XAghyavYNQUv1SZEqNakhNWkulqUjPP5fGsFs1lG/7xRRNL28xY2RN/07Z6i/7MQDRc jw7A==
X-Gm-Message-State: AOPr4FXO/FWd4Usm7Smi06TPuSNJrTGDLh0HT5ny05kP7Y4vmaqBrlbBn2BeXmzvIUPp2rpOtih0aMholHLToA==
MIME-Version: 1.0
X-Received: by 10.36.196.11 with SMTP id v11mr10390391itf.49.1463430789179; Mon, 16 May 2016 13:33:09 -0700 (PDT)
Received: by 10.36.43.82 with HTTP; Mon, 16 May 2016 13:33:09 -0700 (PDT)
In-Reply-To: 
References:   
Date: Mon, 16 May 2016 16:33:09 -0400
Message-ID: 
From: Martin Thomson 
To: Jana Iyengar 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Christian Huitema , Ted Hardie , quic@ietf.org
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 20:33:11 -0000

On 16 May 2016 at 01:00, Jana Iyengar  wrote:
> It should be clear  but it's worth clarifying that the FEC item is not about
> FEC schemes, but about identifying and specifying core protocol mechanisms
> that will be required to allow FEC schemes to be used by QUIC. That said,
> I'm on the fence about requiring a re-charter for FEC; and I would very much
> like to hear more voices on this question.

Ack.  I just don't see it as baked.  Maybe you can convince me
otherwise, but I don't want to embark upon this without some amount of
certainty.

> Do you think something should be added to the charter to
> clarify that the wg is expected to map existing TCP CC onto QUIC and not
> define new CC mechanisms?

Yes, that would help a great deal.

> It was supposed to be a placeholder for negotiating QUIC version, in
> addition to any transport extensions (multipath) that may need negotiation.
> How about we change it to just "version negotiation" and deal with other
> negotiation needs as we encounter them?

Yes.

On 16 May 2016 at 01:58, Jana Iyengar  wrote:
> I'd prefer that we keep a tight application-set to start with, which at the
> moment is {HTTP/2}, and then re-charter to add more as the initial specs
> mature.

I would also prefer this.  A narrow scope maximizes chances of success.


From nobody Mon May 16 13:42:36 2016
Return-Path: 
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 F167212D1E0 for ; Mon, 16 May 2016 13:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 hVo9YPFDZyNe for ; Mon, 16 May 2016 13:42:32 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 6098412DA3C for ; Mon, 16 May 2016 13:42:32 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id n129so115687881wmn.1 for ; Mon, 16 May 2016 13:42:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h8fiWdOr7bs9Lty5F8Jr7BTHMmaeJ72YT/6i0PDJKrs=; b=BiCb0k63riG/7HAlPqIPItQuTGwGyb0pKFoWKhzWrsqA2gRWgpMhpVdJnXfS1Ta5nL oW0/I1/DKEy4xCazZSx3uluxiOhRlZJoSdyrM7fpxJZ7y+CRNx/2ijmHXJBdelsByJE/ SrgnLsbGyhYm3J+QpwFIDD96Rt0hYOs2XGYsEl0vmvlCIGVYyzfB2NGvEYPzeSAq+ooo lbAuhYE29Sf1RE3+YLdaTMkVkmLRbzcj0P7+Ss7eh40sZXfZG3hPPJoTz5kXiLQ7y5Xf 6XS3ncJNudJqLANlLSuWqO8WepiGyb7D16IkGxdosWM2GWdCtiILYrXun29aYTtxfjR+ EeNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h8fiWdOr7bs9Lty5F8Jr7BTHMmaeJ72YT/6i0PDJKrs=; b=cDB2sO7KkqaJ62txLad+fc5+6L4SX+5KPfHVa0+Xgzg3GH1Q4ooVTfxJJOHLK0djfL YIG43iY5uzGd2gvTb57NJtU+pypy9ArfLbWR0tz11GTFs75UuS8++Zg5btykhHstvP47 WfdANFaq6jdMa5108xORVzOohGFO4hXgn/3xt0fbK5Z/49hjDE0j5I7mJAtls1k7Ky+C TnFGHn0tBZPHuk8Fw07tVN1Rj7q22q1XBXlCDbWOfDoiyAWs38minDOwCCJRfF+B43vv FKz7eHnkyS4Kmytkz1uBmpYzuDM8uswuVocu3oDyrZHxB4Gkw1HbhMFdG3SSLM5M7oVr G32A==
X-Gm-Message-State: AOPr4FWp1wAIFQKsKvyuE0gx2L8WggRG3/iAYCBNlTQmtsPUEBfQuk2ULPLSX1iLuREhHQ==
X-Received: by 10.28.154.73 with SMTP id c70mr20664317wme.12.1463431350828; Mon, 16 May 2016 13:42:30 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id k1sm3446951wjx.22.2016.05.16.13.42.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 May 2016 13:42:29 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir 
In-Reply-To: 
Date: Mon, 16 May 2016 23:42:26 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <3CECE727-D987-4D99-AB0C-891052FE2EE1@gmail.com>
References:  
To: "Maxim Proshin [GMAIL]" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , Ted Hardie , quic@ietf.org, Christian Huitema 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 20:42:35 -0000

> On 16 May 2016, at 9:52 PM, Maxim Proshin [GMAIL] =
 wrote:
>=20
> Hi,
>=20
> There is nothing about QUIC API in the charter. Will the group work on =
it?

We=E2=80=99re still discussing the charter. Do you want the group to =
work on it?  Are you proposing to write an API draft?  Are you =
volunteering to write it?

The IETF has written APIs before. We mostly avoid it when possible.

Yoav


From nobody Mon May 16 13:45:42 2016
Return-Path: 
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 9A63C12DA45 for ; Mon, 16 May 2016 13:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 92JIvrBXRWYN for ; Mon, 16 May 2016 13:45:40 -0700 (PDT)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 8356312D1C2 for ; Mon, 16 May 2016 13:45:40 -0700 (PDT)
Received: by mail-ig0-x234.google.com with SMTP id qe5so57404840igc.1 for ; Mon, 16 May 2016 13:45:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=7Yy+Uk30dDKugip0onapmqc/3K9XAwwGT6J6nDHBPkk=; b=EUOAoJpWsD/egRX/3CtoMIqllLXCEIgRG7YygSeltTe3PdIejggZu6mQyyOJLiz4Le WrkruOZWt+iIntKj1SJT5QP+ypHvgRsJDfarYiTn+4jJm0akfcm9hJo7mLsRlW/d2LOf Y6irRmTdZ1UGOO8dGp8c/AzBrB2BZ/huBwaWUa/SEwuCKIsZJ5NHIf+0DqU9g32vmfRn AU6WGYDzxMVnYfV94Y/pppCTJrAfcAYVWp7oZ/KeGQ53exDGTz2okTh6xlWPwawVxGWk yetdjewLMt1hm/NF7RjJr9p4VDdC4WBUKqOW7t4K5pt49rB01XiY/rJbPjVP90KNDZPU 4M4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=7Yy+Uk30dDKugip0onapmqc/3K9XAwwGT6J6nDHBPkk=; b=b5/TTRu3Tzlzkdsqyodq12mbzXB4qFufrItilAanyR/5CUfpDv4XQ4Af55a6HTS7DH JgmXI/qB1PxggGmNzHJcYv/sAiID5LMulvPR0BflWFLiF8G56T62TTPgquIGLnNHG37c tcaollfuFJRADRN+J0MvhPAnSHXQ/mAWuc879mquWE35Gr1QVmWJ44GO0d9ZbWtZjYXC LSpBnK3fOAD4ZDaQ77hTZNN0lo6NYpVeWovY3GsoLx3BYH26aJJGXcdsU8tduOO6Vu5u oELSrbwFmUQdFVQB9+/Ibb6AhBW4NIpEZ+V1PRWu7H6qJC7RIWC930uSh4e+04jsIr92 aOig==
X-Gm-Message-State: AOPr4FXb6SHauPIZn5CrmgohdYXIwp7mTsXFya8t53NJqNO53uUvTy66yaPH+9tRtTIizbfzJ7WAsVetUL8jUw==
MIME-Version: 1.0
X-Received: by 10.50.183.7 with SMTP id ei7mr12646228igc.77.1463431539784; Mon, 16 May 2016 13:45:39 -0700 (PDT)
Received: by 10.36.43.82 with HTTP; Mon, 16 May 2016 13:45:39 -0700 (PDT)
In-Reply-To: <3CECE727-D987-4D99-AB0C-891052FE2EE1@gmail.com>
References:   <3CECE727-D987-4D99-AB0C-891052FE2EE1@gmail.com>
Date: Mon, 16 May 2016 16:45:39 -0400
Message-ID: 
From: Martin Thomson 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Jana Iyengar , Ted Hardie , quic@ietf.org, "Maxim Proshin \[GMAIL\]" , Christian Huitema 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 20:45:41 -0000

On 16 May 2016 at 16:42, Yoav Nir  wrote:
>> There is nothing about QUIC API in the charter. Will the group work on i=
t?
>
> We=E2=80=99re still discussing the charter. Do you want the group to work=
 on it?  Are you proposing to write an API draft?  Are you volunteering to =
write it?

The API is exactly the HTTP API if we narrow the scope as has been suggeste=
d.


From nobody Mon May 16 13:52:49 2016
Return-Path: 
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 429FF12DA57 for ; Mon, 16 May 2016 13:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 pWAan-WxyMNY for ; Mon, 16 May 2016 13:52:46 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 A7C7C12DA4F for ; Mon, 16 May 2016 13:52:44 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id n129so115956831wmn.1 for ; Mon, 16 May 2016 13:52:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uD5Fus3cVGUa3RoKBr9dcw8bXzHcnz9h6ZkDfdk8IDQ=; b=sf/vONPMY57wRnr2etSnx3QAA/Ps10RjSZUvPVJOwfu6gO0p2svrA1NbLlD7+h22w/ pmliV7zm5jqtj9sS7XHvqwtMGyQbYz8jJiFy9dM+FVZI2SVSF/XLCufwby3ZnzpX1Zy0 10/sdP4gESD4umg5lnsUHxiQk/gOp0ojr7UG+tBTt5nn7ZMUkTz5+ijmtAFhi5jHcCFq lzQ21C/nzxy9p0anPiSkWu+u21fU1d1KExL5ZgH+y27OFMBVcxoThLa+qke7cV6jBvA9 tzBKoxdYWVneERfNX7da3HQVE5YhaA7DWmng4OX2pAcNPbefgCLjJl4y7hBKCpFBuhcZ TzYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uD5Fus3cVGUa3RoKBr9dcw8bXzHcnz9h6ZkDfdk8IDQ=; b=P7VJDY18o0qoyQoeKHtXXl/NhE5Qt0eQhZbfhGCbmlQLh1AQAwD/nrHqwdUtf1Q8JG mkRpQ2rmNVKmlGwpo0U7FUcie+vILzADv0EGQckmmoIKND9oU/wXxJJYicKU678k2QiV ddioFXcv/1yBJGrRXfakfe38nz5OXgG2i0wzMSA8HkT6yb6bi+ilo0kf4TdEB2shR2bL Xbxliiu/sob2uputVX2k8hi1R9wkhr2wZA/qn+EJPaVtEbL63FJ9ZN/t+7a6zUUt7SgI 29GNJD4iywe6BP6Pg+zZ34Zr7vu7e9eCwdvmJYkJdrvtH/5o+YlEHiNI0DkxpWmF13TH n9tQ==
X-Gm-Message-State: AOPr4FVpiqQnfYIVraKyt9Kbox2z4UjDKeoIRwgTOXOXfLm/Ywf7rD1KKssI2ILCPDjNiA==
X-Received: by 10.194.115.196 with SMTP id jq4mr31494126wjb.1.1463431963271; Mon, 16 May 2016 13:52:43 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id c194sm20235214wme.9.2016.05.16.13.52.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 May 2016 13:52:42 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir 
In-Reply-To: 
Date: Mon, 16 May 2016 23:52:38 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <5EC9DF66-AAC9-40D1-9363-3A3A29E8B23C@gmail.com>
References:   <3CECE727-D987-4D99-AB0C-891052FE2EE1@gmail.com> 
To: Martin Thomson 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , Ted Hardie , quic@ietf.org, "Maxim Proshin \[GMAIL\]" , Christian Huitema 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 20:52:47 -0000

> On 16 May 2016, at 11:45 PM, Martin Thomson  =
wrote:
>=20
> On 16 May 2016 at 16:42, Yoav Nir  wrote:
>>> There is nothing about QUIC API in the charter. Will the group work =
on it?
>>=20
>> We=E2=80=99re still discussing the charter. Do you want the group to =
work on it?  Are you proposing to write an API draft?  Are you =
volunteering to write it?
>=20
> The API is exactly the HTTP API if we narrow the scope as has been =
suggested.

HTTP runs over TCP, so some of the tweaking you can do to TCP is not in =
the HTTP API but in socket options.

QUIC runs over UDP, so many of the flow control attributes have to be =
part of the QUIC API, because UDP doesn=E2=80=99t have flow control. =
This is mostly the stuff in sections 9 and 10 of =
draft-tsvwg-quic-protocol.

Yoav


From nobody Mon May 16 14:22:49 2016
Return-Path: 
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 5D96F12DACB for ; Mon, 16 May 2016 14:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=adobe.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 YQzW7orZGE9c for ; Mon, 16 May 2016 14:22:46 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0696.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:696]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B550112DAC6 for ; Mon, 16 May 2016 14:22:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Fl5Bbm49aAsp+VLP/Pg8pNmxln/6nJzjFjEG+3uZRaY=; b=nlmHHL4Ho2Q56Q/nHsjlFnniqyAPpEV372jr5zAqMlhdpqsA/GHn2LLUIIdq9s7+GFGOjG+7EMlalN0FxK4dr834egq7PjcmbRRwX7jvEFE0zO+HemIcX11BCiUB6AK0wdAibMro2+af75Epd/nVnEtl1azq5HDjBX9o8uZbrAE=
Received: from BLUPR0201MB1554.namprd02.prod.outlook.com (10.163.119.29) by BLUPR0201MB1554.namprd02.prod.outlook.com (10.163.119.29) with Microsoft SMTP Server (TLS) id 15.1.497.12; Mon, 16 May 2016 21:22:28 +0000
Received: from BLUPR0201MB1554.namprd02.prod.outlook.com ([10.163.119.29]) by BLUPR0201MB1554.namprd02.prod.outlook.com ([10.163.119.29]) with mapi id 15.01.0497.017; Mon, 16 May 2016 21:22:28 +0000
From: Michael Thornburgh 
To: Martin Thomson , Jana Iyengar ,  "quic@ietf.org" 
Thread-Topic: [QUIC] Draft charter
Thread-Index: AQHRrXAL/0lsDLdvvkCdbC4FdP0sQ5+6NsuAgADOFACAAQSSgIAABu6A
Date: Mon, 16 May 2016 21:22:28 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=adobe.com;
x-originating-ip: [192.150.10.204]
x-ms-office365-filtering-correlation-id: e279e809-e980-4ae6-a9ef-08d37dd02ef8
x-microsoft-exchange-diagnostics: 1; BLUPR0201MB1554; 5:/crj/w6zlD6jbVko3rd+DAzFoQFhlQwd2gaOy61rBuRnkj02uYJEgYiCDxZNlv968SlX94cQAslZ4v3iZyr27K7PeVhB7XChgRboXlOJXKmHR7bohVULeifCUvvxgCVKj6T9BI41EDyhstySMdPuBA==; 24:V2hPJTv9ZKjDKSZUF5+oQlRLw7oyTORp9QxU6vAXy/rHS124un8CRQeGMoIdaAeyKqL4n2ZQoLu5uYnwiKTdi/QoYs/U5g8q8+i2+p4sx/w=; 7:C9cx/rtvJey4T/Dr3JiiZUbyNDML6Uv58PYbTInfS1h3mE++JH5+7V237gl5sOAhG59EDawPE/EBaIDahLhiLK5cVIDhqvKGxGApQUvDyKXR9nPw+2wSDE+V5xyz/7PkdrZe9ZSMkY4hQo0JddM6pmMiI5ZON5t7ZS1GKBIzynvJVatUkC2+m03NnLdNrud5
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0201MB1554;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BLUPR0201MB1554; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0201MB1554; 
x-forefront-prvs: 09443CAA7E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(377454003)(2501003)(11100500001)(99286002)(106116001)(8990500004)(19580395003)(19580405001)(5001770100001)(54356999)(2900100001)(5004730100002)(76576001)(50986999)(76176999)(2950100001)(10090500001)(66066001)(5008740100001)(9686002)(10400500002)(8936002)(93886004)(33656002)(122556002)(81166006)(189998001)(2906002)(5002640100001)(3846002)(4326007)(102836003)(6116002)(92566002)(3280700002)(77096005)(87936001)(586003)(1220700001)(3660700001)(8676002)(74316001)(86362001)(5003600100002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0201MB1554; H:BLUPR0201MB1554.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2016 21:22:28.3308 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0201MB1554
Archived-At: 
Cc: Christian Huitema , Ted Hardie 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 21:22:48 -0000

> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson
> Sent: Monday, May 16, 2016 1:33 PM
[...]
>=20
> On 16 May 2016 at 01:58, Jana Iyengar  wrote:
> > I'd prefer that we keep a tight application-set to start with, which at=
 the
> > moment is {HTTP/2}, and then re-charter to add more as the initial spec=
s
> > mature.
>=20
> I would also prefer this.  A narrow scope maximizes chances of success.

i agree; however, other potential uses should be kept in mind (ideally ever=
ybody's minds) so that the design isn't painted into an unfortunate corner.

if the eventual goal is to also support real-time media, partial reliabilit=
y, and other things, there are things in draft-tsvwg-quic-protocol that i w=
ould do very differently (and did do very differently, see RFC 7016, in par=
ticular Section 1.1).

-mike


From nobody Mon May 16 14:40:17 2016
Return-Path: 
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 50ECA12DACF for ; Mon, 16 May 2016 14:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 qwu0fNV-KBD0 for ; Mon, 16 May 2016 14:40:08 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D2612D162 for ; Mon, 16 May 2016 14:40:07 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-eb-573a3e35c2f2
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8B.43.12516.53E3A375; Mon, 16 May 2016 23:40:06 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Mon, 16 May 2016 23:40:05 +0200
From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= 
To: Jana Iyengar 
Thread-Topic: [QUIC] Scope of multi-path WAS: Re: Draft charter
Thread-Index: AQHRr4wQUahMae7V6EaJpFFBu2L7/5+8F+sA
Date: Mon, 16 May 2016 21:40:05 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.3.160329
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="utf-8"
Content-ID: <2C0BEB146D8F7E45B46990BDE59B32C7@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyM2K7ga6ZnVW4Qc9Jdoumz32MFpOOLmSx 6FnAbdE4186BxWPnrLvsHgs2lXosWfKTyaN1x1/2AJYoLpuU1JzMstQifbsErozWjXtYC05w Vsx/8JS9gXEFZxcjJ4eEgInEpFsbGCFsMYkL99azdTFycQgJHGGUeP1lPTOEs4RR4uPHJ+wg VWwC3hJtLYdZQGwRAUWJpz+/gsWZBQolXn9/zAxiCwvYScxv3AFkcwDV2EtMXeUHUW4ksbh1 JhOIzSKgKnHu8R92kBJeAWuJ1afiIVY1MUps2P+BFaSGUyBQYnXfBrB6RgFZifvf77FArBKX uPVkPhPE0QISS/acZ4awRSVePv4H1isqoCex78V5qMeUJBqXPGEF2cUsoCmxfpc+xBhriblf HzFB2IoSU7ofgn3CKyAocXLmE5YJjBKzkGybhdA9C0n3LCTds5B0L2BkXcUoWpxaXJybbmSs l1qUmVxcnJ+nl5dasokRGKUHt/zW3cG4+rXjIUYBDkYlHt4FmpbhQqyJZcWVuYcYJTiYlUR4 V5pahQvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpgDK/6 0q8ZfHpKpUqxyYz5O1VPeeo9ZLSIiMiY5t7/8chbB6uV6raTX6eaia+6lVf2Ll+Q8+6UiDKm uoBHjxY2Bd7bIyTYlfAtq8ivbpP5xNi3HzJ2J/6yS6t6LsQq7fLrZqDSfs2e7hmmTSl/qw/N 2tpoffXd70z31lJp86X+3CeNf+fuXVKoxFKckWioxVxUnAgAMiAVic4CAAA=
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" 
Subject: Re: [QUIC] Scope of multi-path WAS: Re: Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 21:40:09 -0000

DQo+VGhlIHRoaW5raW5nIHdhcyB0byBjb3ZlciB0aGUgZnVuY3Rpb25hbCBlcXVpdmFsZW50IG9m
IFNDVFAgb3IgTVBUQ1ANCj5tdWx0aXBhdGgsIHdoaWNoIGlzIGEgcmVsYXRpdmVseSBrbm93biBz
Y29wZSBpbiB0aGUgSUVURiBjb250ZXh0LiBJJ20NCj5oYXBweSB0byBhZGQgbW9yZSB0ZXh0IGlm
IGZvbGtzIHRoaW5rIHRoYXQgYmVpbmcgbW9yZSBleHBsaWNpdCBoZXJlIGlzDQo+dXNlZnVsLg0K
DQpIaSBKYW5hLA0KDQpTb3VuZHMgbGlrZSBhIGdvb2Qgc2NvcGUgZm9yIGEgZm9jdXNlZCBmaXJz
dCBwaGFzZS4gVGhlcmUgbWF5IGJlIHNvbWUgdXNlDQpjYXNlcyBmb3IgSFRUUC8yIGluIGEgbXVs
dGktaG9tZWQgZGV2aWNlIHRoYXQgZ29lcyBiZXlvbmQgdGhlIGN1cnJlbnQNCk1QVENQIGltcGxl
bWVudGF0aW9ucyBidXQgbGV0IG1lIGdldCBiYWNrIG9uIHRoYXQgb25lIGxhdGVyIChuZWVkIHRv
DQpub29kbGUgdGhhdCBwcm9ibGVtIHNvbWUgbW9yZSkuDQoNClBlcnNvbmFsbHkgbGVhbmluZyB0
b3dhcmRzIGFsc28gZGVzY3JpYmluZyB0aGUgc2NvcGUgaW4gdGV4dCBidXQgSSBhbSBvcGVuDQp0
byBvdGhlciB2aWV3cywgOi0pLg0KDQpBbmQgYXMgd2UgcmVmZXIgdG8gU0NUUCBhbmQgTVBUQ1As
IHRoZW4gcG9zc2libHkgQVBJIGNvbnNpZGVyYXRpb25zIHNob3VsZA0KYmUgYSBkZWxpdmVyYWJs
ZSBhcyB3ZWxsIGFzIHRoZXNlIGFyZSBhdmFpbGFibGUgZm9yIE1QVENQIGlmIEkgYW0gbm90DQpt
aXN0YWtlbiAoUkZDNjg5NyByaWdodD8pLg0KDQpCZXN0IHJlZ2FyZHMNCkfDtnJhbg0KDQpQUy4g
Q2hhcnRlciB0ZXh0IGlzIGdvb2QuIE5vdCBjb25zaWRlcmluZyB0aGUgbXVsdGktcGF0aCBxdWVz
dGlvbiBhIG1ham9yDQppc3N1ZS4NCg0KDQoNCg0KDQoNCg0KDQo=


From nobody Mon May 16 14:57:55 2016
Return-Path: 
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 AD6DC12D539 for ; Mon, 16 May 2016 14:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 pbzQc28xvzqz for ; Mon, 16 May 2016 14:57:53 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 C46DF12D1BC for ; Mon, 16 May 2016 14:57:52 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id e201so117198432wme.0 for ; Mon, 16 May 2016 14:57:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=WlpT7xdrXEC7RQROioo+RRwhnAv84J+s1wcdVmQjrHI=; b=Ot2OI/JkN6yU9bU1syQ32VWag5EYzqCBsIGe4zOh9VA2F6NyIKkgsmofs0LeRWK9+g fEN8S/r9+P9gcGzXJr9DjUinUCUHpiNpx35X+LHN1xKP6vG1Op7hrSU8KixqcfiU5ku8 XkZAuZL/cUKldknYxCbFLRXTYZ0kDfgS5OKaUj5pwJH4eZpZGT/lBbJ3xqVXKqheYPFx YeAfhlVwi63y90ljnbc1a4pTvynqruP4zqH11NZiqThgXkgdAWIk8P3YRN+gOdOKKM6+ R8xY0w0U2VL7dQEYIMS1oV4mJ946Q4qf+1gA2+N8vKCV/A/E7lNrRicFUoivxKQE1Sbb nRMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=WlpT7xdrXEC7RQROioo+RRwhnAv84J+s1wcdVmQjrHI=; b=bIb1kfYflGN/YajRoXgNOe6nET4lVwo1eEkvbHSbpJ52L316vLOAPW93yUROhrqiaJ uKemudsrEYNTh7vSJTsplMHopKIQysDq7ZmkjU1rS2bVWq60KR1J8HcMrMZkHcBmXkp7 Ve0Z+W15xij2o+mhxN1o8/NYFDCqyugs+OJeoBsB/gYJwu1lKREdp6t/gBwJwMrWniyC 4lyyCgyeSd/klLm8fqMcdy/Pu6j43J7oIdVy5BDoW6S+aURfNR2Ixx9Ppc/hZXQM1bVB I9AcQWLI7ztcJIDiBaAEqlxxE9rnyDHA6jBDjrLKkOPLmPF6szHFdlhj9WoTvuZVdUCl WccQ==
X-Gm-Message-State: AOPr4FUrKtqei12eJvq2vEqsOWgIrmHZOCnjBUL2Z7Xpb6JVlimlmZL8N6lMdSdqqcrGirGEh6wamoeCiVAvO6KmsV2NtCy5CV1fhop3pUy2N/Y0GE/Gnfv/
X-Received: by 10.28.52.75 with SMTP id b72mr19869011wma.98.1463435871357; Mon, 16 May 2016 14:57:51 -0700 (PDT)
Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be. [78.129.6.94]) by smtp.gmail.com with ESMTPSA id b124sm21215152wmb.1.2016.05.16.14.57.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 14:57:50 -0700 (PDT)
To: =?UTF-8?Q?G=c3=b6ran_Eriksson_AP?= , Jana Iyengar 
References:   
From: Olivier Bonaventure 
Message-ID: <59f8ddb3-8cd3-6cbe-19c1-07c88264a8c8@tessares.net>
Date: Mon, 16 May 2016 23:57:49 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" 
Subject: Re: [QUIC] Scope of multi-path WAS: Re: Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2016 21:57:55 -0000

Goran,
>
> Sounds like a good scope for a focused first phase. There may be some use
> cases for HTTP/2 in a multi-homed device that goes beyond the current
> MPTCP implementations but let me get back on that one later (need to
> noodle that problem some more).
>
> Personally leaning towards also describing the scope in text but I am open
> to other views, :-).
>
> And as we refer to SCTP and MPTCP, then possibly API considerations should
> be a deliverable as well as these are available for MPTCP if I am not
> mistaken (RFC6897 right?).

Well, although the title of RFC6897 contains the word API, it is very 
minimalist and cannot be considered as an API that allows to control 
MPTCP. If RFC6897 is used as an example to specify an API for QUIC, then 
it means that the WG will not really produce an API...

If QUIC focuses on the HTTP/2 like use case, I'm not sure that an API 
would be required. Maybe some QUIC parameters could be exposed and 
possibly tuned by the applications using QUIC.


Olivier

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.


From nobody Mon May 16 18:13:44 2016
Return-Path: 
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 27CEB12DB3D for ; Mon, 16 May 2016 18:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.426
X-Spam-Level: 
X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 2zNK3FKRXOz2 for ; Mon, 16 May 2016 18:13:40 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 D782012DB3C for ; Mon, 16 May 2016 18:13:38 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id x189so1370962ywe.3 for ; Mon, 16 May 2016 18:13:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4wBcjIIvsYu/xd8NBY7CqITbaKNdHrDTybBV1nmXEVI=; b=d9MnaOWM0DHqiFgst2X8ovmnPd1mfuamj5B9VGHrDQ4FBKpFKfnGDv42N3harq3jVL rCia7TnHse+x1I9QpcZjzVZKLtKIqMsXhuE6q+NRjW/9n5wNiB2VSK/a2yPu5htDBete pER27MIVyro4xHFYy4yIAIOQWHiW8RgdrJRV4R/OK2Pwo2CZyKbVZKMTE7YEZdGhGwNh RmR6+MXX3zIf8oxsOocTlsJkRfoDaLvJcRKYvs0Rbxz48GORImKlpz2CD2dh5sm5I6Yh LkRA/CbEyvcsJyxPPfvSUAJaBfvc5yOcJmTOyqneFrDCernpbMdCrLYg/qxuzgr/8kDT j0XQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4wBcjIIvsYu/xd8NBY7CqITbaKNdHrDTybBV1nmXEVI=; b=juya+9dJWpE5kzqjJTbYcpPQOSJJeask63QRC81a52XmJlGRtk9C1QxvL4QYmD4XDl RNXOxzmJZyhYa3UyUD9pq/L3kSRVh/cI0qgLNaPswwK1MuiP4Sj4m7CjfdhS8gpfE+nt Kx30s9zhvAYj6yT2MBTWZAHeg4ycaEgz7BYpL6kjOouzuQaCnMh/H8mBfGvdSlhgpDWO 5BxcNytqbBBjjhvQ/g4T8wdzb4c5tjQCLUv7WJfO/jtyqHHrnaFWqHuYai3/mnSgmHgK yeoQu6NKMnUJr1P6Ul0wHb8oU2RzUsdtbIv5mVc7MKA/+ngTrZ5U6FxD9ZDsr24aS2/l RblQ==
X-Gm-Message-State: AOPr4FWQqZRKgj/Wmko/2HNPah+bErVpGgJY20BNzfjmyxe9VabFZ66NMHCHEDjGq3aEaLhk1QhZlLh9mZrOP0rM
MIME-Version: 1.0
X-Received: by 10.13.251.4 with SMTP id l4mr17448683ywf.265.1463447618069; Mon, 16 May 2016 18:13:38 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Mon, 16 May 2016 18:13:37 -0700 (PDT)
In-Reply-To: <2B9B48179856DC4FA00C93C79EB7E64A60D98DEC@ESESSMB109.ericsson.se>
References:  <2B9B48179856DC4FA00C93C79EB7E64A60D94ED9@ESESSMB109.ericsson.se>  <2B9B48179856DC4FA00C93C79EB7E64A60D98DEC@ESESSMB109.ericsson.se>
Date: Mon, 16 May 2016 18:13:37 -0700
Message-ID: 
From: Jana Iyengar 
To: Salvatore Loreto 
Content-Type: multipart/alternative; boundary=94eb2c07e55c6cad740532ff7359
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 01:13:42 -0000

--94eb2c07e55c6cad740532ff7359
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, May 16, 2016 at 2:18 AM, Salvatore Loreto <
salvatore.loreto@ericsson.com> wrote:

>
>
> Thru
>
> but with the difference that the work been done so far in TSVAREA (i.e.
> SCTP and Multipath TCP) is for connection oriented
>
> transport protocols.
>
> don=E2=80=99t get me wrong I do think a brand new transport protocol shou=
ld
> (actually has to) include the multipath facility and have it
>
> actually as a native one.  Indeed I would like to see the multipath item
> expanded and explained more in the charter.
>

I don't think the multipath work would be much different since QUIC is
connection-oriented as well.

My comment was mainly for FEC, and moving this item to requiring a
> re-charter would make me more comfortable with
>
> the charter for the BoF
>

Got it. That seems to be the emerging view at this point, so we may well
end up there.

- jana


>
>
>
>
>
>
> *From:* Jana Iyengar [mailto:jri@google.com]
> *Sent:* den 16 maj 2016 07:19
> *To:* Salvatore Loreto
> *Cc:* Ted Hardie; quic@ietf.org; Christian Huitema
> *Subject:* Re: [QUIC] Draft charter
>
>
>
> To concerns about multipath in the fourth area: TSVAREA has done multipat=
h
> in SCTP and in MPTCP. MPTCP is seeing deployment -- albeit slowly and in
> limited quarters -- and I would argue that expecting multipath to be a
> facility available as a part of a brand new transport seems quite
> reasonable.
>
>
>
> Mechanisms for enabling FEC are a bit more experimental, so I'm more
> comfortable moving this item to requiring a re-charter.
>
>
>
> On Sun, May 15, 2016 at 12:32 PM, Salvatore Loreto <
> salvatore.loreto@ericsson.com> wrote:
>
> Hi Ted
>
>
>
> I thinks the charter looks OK,
>
> However I tend to agree with previous comments
>
> that the work at moment should really focused on (narrowed to) the first
> and second parts to the design of QUIC as transport protocol
>
>
>
> for the third focus
>
> I have some concerns of the wg doing at same time the work for designing
> the transport protocol and describing
>
> =E2=80=9Cmappings between specific applications=E2=80=99 semantics and th=
e transport
> facilities of QUIC=E2=80=9D
>
>
>
> For the fourth focus I don=E2=80=99t think the experimentation has showed=
 so far
> enough interesting results deserving to be standardized.
>
>
>
> Cheers
>
> Salvatore
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ted Hardie
> *Sent:* den 14 maj 2016 01:27
> *To:* quic@ietf.org; Jana Iyengar; Christian Huitema
> *Subject:* [QUIC] Draft charter
>
>
>
> Howdy,
>
> As part of the BoF preparation, we put together a stab at a draft
> charter.  It's available as html and markdown on github at:
>
> https://github.com/IETF-QUIC/Charter
>
> I've attached the HTML version as well.
>
> It would be great to have some of the discussion on the list before the
> BoF.  Comments to the list or issues/pull requests at the github repo are
> welcome.  We will periodically reflect any issues or suggestion from the
> Repo back to the list, but this will be manual, so expect some lag.
>
>
>
> regards,
>
> Ted
>
>
>

--94eb2c07e55c6cad740532ff7359
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 16, 2016 at 2:18 AM, Salvatore Loreto <salvatore.loret=
o@ericsson.com> wrote:











=C2=A0


Thru



but with the difference t=
hat the work been done so far in TSVAREA (i.e. SCTP and Multipath TCP) is f=
or connection oriented



transport protocols.


don=E2=80=99t get me wron=
g I do think a brand new transport protocol should (actually has to) includ=
e the multipath facility and have it


actually as a native one.=
=C2=A0 Indeed I would like to see the multipath item expanded and explained=
 more in the charter.

I don't think the multipath work would be much different since QUIC i=
s connection-oriented as well.



My comment was mainly for=
 FEC, and moving this item to requiring a re-charter would make me more com=
fortable with



the charter for the BoF

Got it. That seems to be th=
e emerging view at this point, so we may well end up there.

<=
/div>
- jana
=C2=A0
<=
span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size=
:11pt">=C2=A0


=C2=A0


=C2=A0


From: Jana Iye=
ngar [mailto:jri@google=
.com]


Sent: den 16 maj 2016 07:19

To: Salvatore Loreto

Cc: Ted Hardie; q=
uic@ietf.org; Christian Huitema

Subject: Re: [QUIC] Draft charter


=C2=A0






To concerns about multipath in the fourth area: TSVA=
REA has done multipath in SCTP and in MPTCP. MPTCP is seeing deployment -- =
albeit slowly and in limited quarters -- and I would argue that expecting m=
ultipath to be a facility available
 as a part of a brand new transport seems quite reasonable.





=C2=A0










Mechanisms for enabli=
ng FEC are a bit more experimental, so I'm more comfortable moving this=
 item to requiring a re-charter.












=C2=A0




On Sun, May 15, 2016 at 12:32 PM, Salvatore Loreto &=
lt;salva=
tore.loreto@ericsson.com> wrote:






Hi Ted


=C2=A0


I thinks the charter look=
s OK,


However I tend to agree w=
ith previous comments



that the work at moment s=
hould really focused on (narrowed to) the first and second parts to the
 design of QUIC as transport protocol


=C2=A0


for the third focus


I have some concerns of t=
he wg doing at same time the work for designing the transport protocol and
 describing 


=E2=80=9Cmappings between=
 specific applications=E2=80=99 semantics and the transport facilities of Q=
UIC=E2=80=9D


=C2=A0


For the fourth focus I do=
n=E2=80=99t think the experimentation has showed so far enough interesting =
results
 deserving to be standardized.


=C2=A0


Cheers


Salvatore


=C2=A0


From: QUIC [ma=
ilto:quic-bounce=
s@ietf.org]
On Behalf Of Ted Hardie

Sent: den 14 maj 2016 01:27

To: quic@ietf.org=
; Jana Iyengar; Christian Huitema

Subject: [QUIC] Draft charter






=C2=A0












Howdy,<=
/p>



As part of the BoF pr=
eparation, we put together a stab at a draft charter.=C2=A0 It's availa=
ble as html and markdown on github at:



https://=
github.com/IETF-QUIC/Charter




I've attached the=
 HTML version as well.=C2=A0







It would be great to have some of the discussion on =
the list before the BoF.=C2=A0 Comments to the list or issues/pull requests=
 at the github repo are welcome.=C2=A0 We will periodically
 reflect any issues or suggestion from the Repo back to the list, but this =
will be manual, so expect some lag.






=C2=A0




regards,




Ted














=C2=A0












--94eb2c07e55c6cad740532ff7359--


From nobody Mon May 16 18:57:22 2016
Return-Path: 
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 15D1512DB4B for ; Mon, 16 May 2016 18:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 YTGXFAZH6zvl for ; Mon, 16 May 2016 18:57:19 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 A7B0112DB47 for ; Mon, 16 May 2016 18:57:19 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id j74so2178929ywg.1 for ; Mon, 16 May 2016 18:57:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=LaFqQpTrWf0WHNnnrVMZBnFH5jTNRE8iAST6vq4Hcdw=; b=GaHoOtZgH+T37ZJvG+nXlEtzJhdhxoO0qW1YXoDJVDzYR2DCMb3egz/NDLsvNBbU13 XBbzkCqa+WCtqzzvAEJh1Th65oyvZ1+5OexlWtFz8KWJksvLnU2GHZGVujTJAe0BS7dE rTFGkOvILWiNDwvEsTWPzzfJ7s4jMikEwNhYFtZhQSGmTuJdzhqhF8mM/dUNVygmZmXh 0loomtLVEQQgmGK0rllyHRSd1yA4tyeqHqr4Con5lX9W2A9zM6EC5G8ZXvcHIW64VueZ 26EshpeyDptruGxWZcQPrDjtJ2IoS+1Rq1d5q8ZwPNXqaAodDURp/O2/o0PCapyvhvV6 Y2iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LaFqQpTrWf0WHNnnrVMZBnFH5jTNRE8iAST6vq4Hcdw=; b=kZSvNPhmcGWq7VztqXSABQ/hffYXHJlFQiwcA2dCOFn0mAmZLsjqIXlHv2HhqBfhzK UWmlfPV8Nl1UqfvDdphQPLCh4vKoHtXWlOAO0mSNwibAOUXkKLwayZsKmPSOXwSvKlVT W1bdkwLK7rK4QRTuwCQenIpla/YROCThUKOpcFpJHJJ3zKDUymNgou3RjQHd1aQg1IYP nm4YxNgJyf4aP20CLxL3bHQHdB9pxFuRFGbncJ4MrAzSZ7+sF/YWuFPvhwUS3K2+yTY7 vyZrqQYT0oA4h88PbyJfT0T2wN9JxtUDWF0GHJmvMKr7d5HR8pVPAPa/C5gmisVxeoB1 5Owg==
X-Gm-Message-State: AOPr4FULpqQR3X1O3tAZ3mGUvNi8aiW8a5LWTkRJRR2kXoawZ7v4568N9ZRwruYbEZa/opI+wBrtOjWE95ri/+SN
MIME-Version: 1.0
X-Received: by 10.13.218.65 with SMTP id c62mr9331836ywe.36.1463450238801; Mon, 16 May 2016 18:57:18 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Mon, 16 May 2016 18:57:18 -0700 (PDT)
In-Reply-To: <3CECE727-D987-4D99-AB0C-891052FE2EE1@gmail.com>
References:   <3CECE727-D987-4D99-AB0C-891052FE2EE1@gmail.com>
Date: Mon, 16 May 2016 18:57:18 -0700
Message-ID: 
From: Jana Iyengar 
To: Yoav Nir 
Content-Type: multipart/alternative; boundary=94eb2c080508a1dd8f0533000ffa
Archived-At: 
Cc: Christian Huitema , Ted Hardie , quic@ietf.org, "Maxim Proshin \[GMAIL\]" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 01:57:21 -0000

--94eb2c080508a1dd8f0533000ffa
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, May 16, 2016 at 1:42 PM, Yoav Nir  wrote:

>
> > On 16 May 2016, at 9:52 PM, Maxim Proshin [GMAIL] 
> wrote:
> >
> > Hi,
> >
> > There is nothing about QUIC API in the charter. Will the group work on
> it?
>
> We=E2=80=99re still discussing the charter. Do you want the group to work=
 on it?
> Are you proposing to write an API draft?  Are you volunteering to write i=
t?
>
> The IETF has written APIs before. We mostly avoid it when possible.


+1. I'm comfortable leaving it out for now, and re-chartering to include it
if the wg has a burning desire to work on it.

- jana


>
> Yoav
>
>

--94eb2c080508a1dd8f0533000ffa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 16, 2016 at 1:42 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:


> On 16 May 2016, at 9:52 PM, Maxim Proshin [GMAIL] <mvproshin@gmail.com> wrote:

>

> Hi,

>

> There is nothing about QUIC API in the charter. Will the group work on=
 it?



We=E2=80=99re still discussing the charter. Do you want the group to=
 work on it?=C2=A0 Are you proposing to write an API draft?=C2=A0 Are you v=
olunteering to write it?



The IETF has written APIs before. We mostly avoid it when possible.

+1. I'm comfortable leaving it out for now, an=
d re-chartering to include it if the wg has a burning desire to work on it.=


- jana
=C2=A0


Yoav







--94eb2c080508a1dd8f0533000ffa--


From nobody Mon May 16 19:13:34 2016
Return-Path: 
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 8973E12D9F3 for ; Mon, 16 May 2016 19:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 OiV1yoQNGRze for ; Mon, 16 May 2016 19:13:31 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 1CBCE12B018 for ; Mon, 16 May 2016 19:13:31 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id 190so6349809iow.1 for ; Mon, 16 May 2016 19:13:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=dbdmBfsEkIP5/S4VnP4FqnPNEhACOuCQCSVeG8xRc1U=; b=VAH5k2lNsUenq6lUNqKEBSeX5WkSouQJIzIWt2MBNuSnKDDwG04WAm0bGuNfcoNFfL I/UbWU6609BEGPPM8j2FLvuVvKSBdGp1Upryuwu1ef+DNnIxRIXvkCpOh9NmCzEAHt/o 0+TQ+HLT0Elqh5Lhn/vxN5e8kYoW9+W5MlJpfPrvdGsDQOqtxmEam9gFLFKYb7flnOc2 Q9W6vCfAHTggP4bJIbfarh3O86MV4NnYidgh9gvLyxkptTy6ZGzVzWg4wPt+7mg/sjtA ltKOLvt8JykrwLCfdSafEXe9lz/s/FD2ZiNuJv1dpGkClPo1RtEPbBHUwQYd28mCYpkn 2mtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=dbdmBfsEkIP5/S4VnP4FqnPNEhACOuCQCSVeG8xRc1U=; b=NJPTr+YLDhY7Ng5xS17BD6FUdtkW6ZJHf75ssWinF3tqnqRkG9OyPWjhL+2BAv8Oot RwNh5AKo/KESDDw1R1mLCOr7/IkWbvOVLZFDkgfSr5mNzFIBoibLe+384GTnVmCEnSmF JuuINfPYCDco3N5PqpULki+T57U3+nOR/iu63BS9fwXlw7iziaVnjB5KL91P5LfdR16I lf5ZJuv2MctIwkmbtXI4K3zXKqMfFbhCt5u6wCpHxF71sPOrOw78iM1UUfFazRToaasv ALB175VIvfymSH92bDqQENb44AuMs7L1dFd0TNQaKD+iUxSRMfzxfSu2QzmhO0ORx1Zo F0AA==
X-Gm-Message-State: AOPr4FVwe47qlcguMg15VL9y7LadYywJG3csjg4oeuF78uWLQnSFwP6dt3gTmlIlZaocUk4jpKohqeb3ZUYvvg==
MIME-Version: 1.0
X-Received: by 10.36.44.200 with SMTP id i191mr11492256iti.99.1463451210339; Mon, 16 May 2016 19:13:30 -0700 (PDT)
Sender: nygren@gmail.com
Received: by 10.107.200.81 with HTTP; Mon, 16 May 2016 19:13:30 -0700 (PDT)
In-Reply-To: 
References:     
Date: Mon, 16 May 2016 22:13:30 -0400
X-Google-Sender-Auth: x7ggskwq8CP9MB5y75lPUFrfSOE
Message-ID: 
From: Erik Nygren 
To: Michael Thornburgh 
Content-Type: multipart/alternative; boundary=001a113f9f6c89e00d053300496a
Archived-At: 
Cc: Jana Iyengar , Ted Hardie , "quic@ietf.org" , Martin Thomson , Christian Huitema 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 02:13:32 -0000

--001a113f9f6c89e00d053300496a
Content-Type: text/plain; charset=UTF-8

On Mon, May 16, 2016 at 5:22 PM, Michael Thornburgh 
wrote:

>
> i agree; however, other potential uses should be kept in mind (ideally
> everybody's minds) so that the design isn't painted into an unfortunate
> corner.
>
> if the eventual goal is to also support real-time media, partial
> reliability, and other things, there are things in
> draft-tsvwg-quic-protocol that i would do very differently (and did do very
> differently, see RFC 7016, in particular Section 1.1).


I agree, and I think it's worth keeping "considering extensibility to
enable future FEC and partial reliability" in the charter even if they are
explicitly not work items initially.  Having the extensibility hooks to
enable them in the future will be important as if we don't consider hooks
for them in the future, it may be hard to retrofit the back in.  I think
many of the interesting future benefits from QUIC will come from being able
to add things like this in down the road.

    Erik

--001a113f9f6c89e00d053300496a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 16, 2016 at 5:22 PM, Michael Thornburgh <mthornbu@adobe.com&g=
t; wrote:


i agree; however, other potential uses should be kept in mind (ideal=
ly everybody's minds) so that the design isn't painted into an unfo=
rtunate corner.



if the eventual goal is to also support real-time media, partial reliabilit=
y, and other things, there are things in draft-tsvwg-quic-protocol that i w=
ould do very differently (and did do very differently, see RFC 7016, in par=
ticular Section 1.1).

I agree, and I think =
it's worth keeping "considering extensibility to enable future FEC=
 and partial reliability" in the charter even if they are explicitly n=
ot work items initially.=C2=A0 Having the extensibility hooks to enable the=
m in the future will be important as if we don't consider hooks for the=
m in the future, it may be hard to retrofit the back in.=C2=A0 I think many=
 of the interesting future benefits from QUIC will come from being able to =
add things like this in down the road.

=C2=A0=C2=A0=C2=A0=
 Erik




--001a113f9f6c89e00d053300496a--


From nobody Mon May 16 19:24:45 2016
Return-Path: 
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 48D1C12D8B5 for ; Mon, 16 May 2016 19:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Cn-tyDS1Eoxr for ; Mon, 16 May 2016 19:24:41 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 1A3E912D8B1 for ; Mon, 16 May 2016 19:24:41 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id g133so2634980ywb.2 for ; Mon, 16 May 2016 19:24:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=JoamkRbxU8ZM8eOkdINY0LWAY7AXiE1XsoUpoIqa9xA=; b=j1tMBvaM8lA1ZuTwJFCtFmW8kE/jnhNWyT18ERRB5Dm7pX9Y3FpqVUdyiWg2AO1b+U Y3/xOdg/yu4hgi9jh5/aCPLlotkQ64WNR1/VJeQZ/0+g2vEDDqDbR3yx//JuhNQ0pWM3 m0CCu2967m4vks51KU2aGsNlQtpH/7vqSXNWmigWjzgMf+7lAlGv6yByFnM2c82/E1kJ XuAZYbL79Py2TLX9gQqF/6Qt6rgFwGP5XN1vh2vz6GAKc71f7huRagvnL8WKl8s14n+P aiGXM2+6WCaYrPKHcnlFi5YpptBE1vcXugdz5fBQ6CUZCXH72GQFxAv44wdC4EqYaKkn 6uHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JoamkRbxU8ZM8eOkdINY0LWAY7AXiE1XsoUpoIqa9xA=; b=jFwCPTkRgF5dWIU7OXXFZURBqz3FotZLbXW4PBtJOrseFLYkP2EnlRDRga4WeiSwku zBdjJlypf4ZQwZwI3b6Ql/3dcj1+zz1tn/58ntaig76ABXKNMAkl6juW0bvNd6RiT08g a9yr+qlAepwcRFfyHdzgBJm8sfMoiKdiQ0HEfiqFxqQH3bSC5WNHvU34u89Q5afT6jWy 6GZiGNffnWBw1XPmOjWZm7Ws5/dt/WDK1QZ7aS04oJnmHOlqPximAJw3CdNWWJk2/1hC GONsWRWjY0gf+LNzfxEGdldUQOmESA+udZGkW5g6fEbikkwohsOUJNVOUFI1i3Db8eJ1 bkOg==
X-Gm-Message-State: AOPr4FVk7oHRGicalx/rWNae6WJ6XmmucEHlSofj+zVoC9Oxl0HuJ25XcIYsNC1fNiwiLBB1k/G0wMjo5x8qwRsK
MIME-Version: 1.0
X-Received: by 10.37.58.198 with SMTP id h189mr14746511yba.165.1463451880235;  Mon, 16 May 2016 19:24:40 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Mon, 16 May 2016 19:24:39 -0700 (PDT)
In-Reply-To: <5EC9DF66-AAC9-40D1-9363-3A3A29E8B23C@gmail.com>
References:   <3CECE727-D987-4D99-AB0C-891052FE2EE1@gmail.com>  <5EC9DF66-AAC9-40D1-9363-3A3A29E8B23C@gmail.com>
Date: Mon, 16 May 2016 19:24:39 -0700
Message-ID: 
From: Jana Iyengar 
To: Yoav Nir 
Content-Type: multipart/alternative; boundary=001a114bc1367835c50533007183
Archived-At: 
Cc: Christian Huitema , Ted Hardie , quic@ietf.org, Martin Thomson , "Maxim Proshin \[GMAIL\]" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 02:24:44 -0000

--001a114bc1367835c50533007183
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, May 16, 2016 at 1:52 PM, Yoav Nir  wrote:

>
> > On 16 May 2016, at 11:45 PM, Martin Thomson 
> wrote:
> >
> > On 16 May 2016 at 16:42, Yoav Nir  wrote:
> >>> There is nothing about QUIC API in the charter. Will the group work o=
n
> it?
> >>
> >> We=E2=80=99re still discussing the charter. Do you want the group to w=
ork on
> it?  Are you proposing to write an API draft?  Are you volunteering to
> write it?
> >
> > The API is exactly the HTTP API if we narrow the scope as has been
> suggested.
>

As Yoav alludes, there is the question of the transport API to HTTP ---
basically the QUIC equivalent of the socket API for TCP or SCTP. That said,
the socket API is usually Informational (see RFC 6458
 as an example), since most
traditional transport implementations live in the kernel. Since the
expectation is that QUIC will mostly have userspace implementations, the
interaction model (sync/async, push/pull) will depend on the specific
implementations of both QUIC and the application. Given that we don't even
have a sockets framework (which defines a very specific interaction model)
to operate in, I'm not sure how specific this API between QUIC and the
application can be.

My instinct is to deal with it if/when the need arises. I'm willing to be
convinced otherwise... I suppose we could do a functional API in the spirit
of what was defined for TCP in RFC 793
.

- jana

HTTP runs over TCP, so some of the tweaking you can do to TCP is not in the
> HTTP API but in socket options.
>
> QUIC runs over UDP, so many of the flow control attributes have to be par=
t
> of the QUIC API, because UDP doesn=E2=80=99t have flow control. This is m=
ostly the
> stuff in sections 9 and 10 of draft-tsvwg-quic-protocol.
>
> Yoav
>
>

--001a114bc1367835c50533007183
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 16, 2016 at 1:52 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:


> On 16 May 2016, at 11:45 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

>

> On 16 May 2016 at 16:42, Yoav Nir <ynir.ietf@gmail.com> wrote:

>>> There is nothing about QUIC API in the charter. Will the group=
 work on it?

>>

>> We=E2=80=99re still discussing the charter. Do you want the group =
to work on it?=C2=A0 Are you proposing to write an API draft?=C2=A0 Are you=
 volunteering to write it?

>

> The API is exactly the HTTP API if we narrow the scope as has been sug=
gested.

As Yoav alludes, th=
ere is the question of the transport API to HTTP --- basically the QUIC equ=
ivalent of the socket API for TCP or SCTP. That said, the socket API is usu=
ally Informational (see RFC=
 6458 as an example), since most traditional transport implementations =
live in the kernel. Since the expectation is that QUIC will mostly have use=
rspace implementations, the interaction model (sync/async, push/pull) will =
depend on the specific implementations of both QUIC and the application. Gi=
ven that we don't even have a sockets framework (which defines a very s=
pecific interaction model) to operate in, I'm not sure how specific thi=
s API between QUIC and the application can be.

My =
instinct is to deal with it if/when the need arises. I'm willing to be =
convinced otherwise... I suppose we=C2=A0could do a functional API in the s=
pirit of what was defined for TCP in=C2=A0RFC 793.

- jana



HTTP runs over TCP, so some of the tweaking you can do to TCP i=
s not in the HTTP API but in socket options.



QUIC runs over UDP, so many of the flow control attributes have to be part =
of the QUIC API, because UDP doesn=E2=80=99t have flow control. This is mos=
tly the stuff in sections 9 and 10 of draft-tsvwg-quic-protocol.



Yoav







--001a114bc1367835c50533007183--


From nobody Mon May 16 19:50:12 2016
Return-Path: 
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 293D012D585 for ; Mon, 16 May 2016 19:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ztYHbOC8aBmw for ; Mon, 16 May 2016 19:50:09 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 604CE12D1AC for ; Mon, 16 May 2016 19:50:09 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id x189so3001683ywe.3 for ; Mon, 16 May 2016 19:50:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Ax3UKeiWowZ0BJJFpqasHDZvszbNnDimZSgLIJSts4s=; b=Ofs6KTyvznFByyiA7NaIk9LGHgrY+RKhpsfeupMtvKAOTwxKjMBjHHcVsbtg/Rxa1d ZjC3afmr+sVge1QO65o0dok/U7hB+7XgJzvPvdNEZADcHcx4mfMPriPwNJTjoHrYmS0P GA3K64sf8LPRTO9CW4Ja8pL8yJwgfWfGUCsAz2A6gDO1kY4zC/6oQyK85BDLi9j6Vb7f P8t8zkZEBQW/Uf2xcn2xESx6GI3skKa+k5UTdiDrRDtIasD1R2tNwtm/jfvLoQqLKMPb iYgizbcXg2sEp+jWeHVm0eV+HB6N+Nx39RkxeFVmaH9DwmSwCCJLAthL6NTSQ0cUhrDm hvMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Ax3UKeiWowZ0BJJFpqasHDZvszbNnDimZSgLIJSts4s=; b=dJMlNaFxIg1rHu5s+XLzPoMaY3HAlc3zDju8MfPB/BmkXwavtOpEK2oZxMpTBqA5Hs u7J3v/Y+BkbEUec7uu5inBeUhY2D+x7WIJSPFjr6VYaxPguVHVGf1/AWlfK3tfckj3vx 1ixgc0w7XyRytNk26+d5rC5b4ot80DHz6gAK1lioAKxhVJH2w9Ak0eAH7CAvwaPO+4Qo eCe9hXJHBco1AKg7wDHVYh8+/JKUWWAz5M8k3iYNLf88wTdj6MZmqLe1qTqGfKlSoo3V R6UM1tMHTaRKGYrhsO33YjGJlYOeTl3sBhHf5FBHg6ylI+Xjeqc8r5p1GsWZEMpP2Jjk pYCQ==
X-Gm-Message-State: AOPr4FUiDAZQECKJiwgsi2GY5A9HFdFKMr7qmzNstWztZ08+kUOPmFPiTY3VngYro12MYCdI+hN8ny3YJR4zcb7U
MIME-Version: 1.0
X-Received: by 10.37.49.193 with SMTP id x184mr6170764ybx.57.1463453408516; Mon, 16 May 2016 19:50:08 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Mon, 16 May 2016 19:50:08 -0700 (PDT)
In-Reply-To: 
References:      
Date: Mon, 16 May 2016 19:50:08 -0700
Message-ID: 
From: Jana Iyengar 
To: Erik Nygren 
Content-Type: multipart/alternative; boundary=001a1148af188fe812053300cc7d
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" , Martin Thomson , Michael Thornburgh 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 02:50:11 -0000

--001a1148af188fe812053300cc7d
Content-Type: text/plain; charset=UTF-8

On Mon, May 16, 2016 at 7:13 PM, Erik Nygren  wrote:

> On Mon, May 16, 2016 at 5:22 PM, Michael Thornburgh 
> wrote:
>
>>
>> i agree; however, other potential uses should be kept in mind (ideally
>> everybody's minds) so that the design isn't painted into an unfortunate
>> corner.
>>
>> if the eventual goal is to also support real-time media, partial
>> reliability, and other things, there are things in
>> draft-tsvwg-quic-protocol that i would do very differently (and did do very
>> differently, see RFC 7016, in particular Section 1.1).
>
>
> I agree, and I think it's worth keeping "considering extensibility to
> enable future FEC and partial reliability" in the charter even if they are
> explicitly not work items initially.  Having the extensibility hooks to
> enable them in the future will be important as if we don't consider hooks
> for them in the future, it may be hard to retrofit the back in.  I think
> many of the interesting future benefits from QUIC will come from being able
> to add things like this in down the road.
>

I definitely agree with the general sentiment. I had hoped that having
multipath (as an extension) in the charter allows us to specify these
"extensibility mechanisms", which can be exercised later for other features
such as FEC and partial reliability.  If you think it's helpful to call out
extensibility explicitly, can you suggest text?

- jana



>
>     Erik
>
>
>

--001a1148af188fe812053300cc7d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, May 16, 2016 at 7:13 PM, Erik Nygren <erik+ietf@nygren.org<=
/a>> wrote:
On Mon=
, May 16, 2016 at 5:22 PM, Michael Thornburgh <mthornbu@adobe.com>=
 wrote:


i agree; however, other potential uses should be kept in mind (ideal=
ly everybody's minds) so that the design isn't painted into an unfo=
rtunate corner.



if the eventual goal is to also support real-time media, partial reliabilit=
y, and other things, there are things in draft-tsvwg-quic-protocol that i w=
ould do very differently (and did do very differently, see RFC 7016, in par=
ticular Section 1.1).

I agree, and I=
 think it's worth keeping "considering extensibility to enable fut=
ure FEC and partial reliability" in the charter even if they are expli=
citly not work items initially.=C2=A0 Having the extensibility hooks to ena=
ble them in the future will be important as if we don't consider hooks =
for them in the future, it may be hard to retrofit the back in.=C2=A0 I thi=
nk many of the interesting future benefits from QUIC will come from being a=
ble to add things like this in down the road.

I definitely agree with the general sentiment. I=
 had hoped that having multipath (as an extension) in the charter allows us=
 to specify these "extensibility mechanisms", which can be exerci=
sed later for other features such as FEC and partial reliability.=C2=A0 If =
you think it's helpful to call out extensibility explicitly, can you su=
ggest text?

- jana

=C2=A0=


=C2=A0=C2=A0=C2=A0 Erik







--001a1148af188fe812053300cc7d--


From nobody Mon May 16 20:03:47 2016
Return-Path: 
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 E458E12D786 for ; Mon, 16 May 2016 20:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Rd5AWfCYYcQr for ; Mon, 16 May 2016 20:03:44 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 7A27B12D7D9 for ; Mon, 16 May 2016 20:03:44 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id x194so3299571ywd.0 for ; Mon, 16 May 2016 20:03:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=w1I7RBVxuQrid3QjBoMgeFJ6zTRqQ0Qj9h6i04u6E0M=; b=XdvFe4KxgxMaxI/+cqgJ6E0llN4ow341cukWhpDlYDVerLguxOKbcdqpYxX71lFY2j YHKop6BH/+4nK/g9KuJetmbl7etAi13nMZjaeB1KQaoisPoTtGbPscsDZ/44pwCJkPY2 qy615EfJVCHKlvpb73DckpN5cLdUroe9nuco9eRNJr3xKopk+wsvmqlMz53jwNJNZuh/ tQCV09szLCpt10uQXRlCgSmVv1Jyo3jzO5C9LlHC/5ugTvVDFl9cHykhUoUN9m7cN8rY Lc+4Ev4YbdmEPWPI6p26OxeTI8+mIYKgizTX+xCwoDDrqTYQJSs1CrQR3JC9BHM2DGHw zlxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=w1I7RBVxuQrid3QjBoMgeFJ6zTRqQ0Qj9h6i04u6E0M=; b=POtqBet1wgHUOMvmCNnZl/t5zt9ESXkhwnrw727ZEH+KYu0Llk0gy+IWidYzGA+zEJ jImNTopZXtoyOGro0kHKK+J0ADIj6J6wy7LNZOgns4WSDSENHRtfYZ6OZ+SEQuJNcTpq 4TLzfbJ56RZm3YDCwttOMJlOEf+8q1HYKwqkEjQ0Az38vQInR4sEaCNIpfTrgnQtw5Yb 5sMVrMjOQXopsFlY2TWU44I1xH9PqRfxU7JxzChxZD3GgRs86CCYNKLqNvYEo7ehakFF Q0z/LDdCevljtGsF1qOvwDr0VD6v76yOp87G/Tm/tMsGHEj8IlNGRANDGv0FfkqgS4vo EH6g==
X-Gm-Message-State: AOPr4FVs2Y1mRlo2si1BmGZ33Gbx1YnZ/OrRnhhJh/fZhoPnNKk275U675r6Q3t/pJMkbVtLA1IDRZ+T9M6SHIuO
MIME-Version: 1.0
X-Received: by 10.13.218.65 with SMTP id c62mr9416356ywe.36.1463454223710; Mon, 16 May 2016 20:03:43 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Mon, 16 May 2016 20:03:43 -0700 (PDT)
In-Reply-To: 
References:     
Date: Mon, 16 May 2016 20:03:43 -0700
Message-ID: 
From: Jana Iyengar 
To: Michael Thornburgh 
Content-Type: multipart/alternative; boundary=94eb2c08050826a6b1053300fd64
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" , Martin Thomson 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 03:03:46 -0000

--94eb2c08050826a6b1053300fd64
Content-Type: text/plain; charset=UTF-8

On Mon, May 16, 2016 at 2:22 PM, Michael Thornburgh 
wrote:

> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson
> > Sent: Monday, May 16, 2016 1:33 PM
> [...]
> >
> > On 16 May 2016 at 01:58, Jana Iyengar  wrote:
> > > I'd prefer that we keep a tight application-set to start with, which
> at the
> > > moment is {HTTP/2}, and then re-charter to add more as the initial
> specs
> > > mature.
> >
> > I would also prefer this.  A narrow scope maximizes chances of success.
>
> i agree; however, other potential uses should be kept in mind (ideally
> everybody's minds) so that the design isn't painted into an unfortunate
> corner.
>

I agree... though I find it hard to word this into the charter.


> if the eventual goal is to also support real-time media, partial
> reliability, and other things, there are things in
> draft-tsvwg-quic-protocol that i would do very differently (and did do very
> differently, see RFC 7016, in particular Section 1.1).
>

QUIC running code and deployment experience is limited to HTTP/2 at this
point, which is why early focus is limited to the initial application-set.
I think this wg will need to walk the fine line between over-engineering
for the initial application-set and becoming a kitchen sink for any/all
applications. We may well learn later that to support a new application
(real-time media, say) we may need to modify mechanisms in the core
protocol spec, but that still seems like a better process for keeping the
wg coherent.

- jana



> -mike
>

--94eb2c08050826a6b1053300fd64
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 16, 2016 at 2:22 PM, Michael Thornburgh <mthornbu@adobe.com> wrote:
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson

> Sent: Monday, May 16, 2016 1:33 PM

[...]

>

> On 16 May 2016 at 01:58, Jana Iyengar <jri@google.com> wrote:

> > I'd prefer that we keep a tight application-set to start with=
, which at the

> > moment is {HTTP/2}, and then re-charter to add more as the initia=
l specs

> > mature.

>

> I would also prefer this.=C2=A0 A narrow scope maximizes chances of su=
ccess.



i agree; however, other potential uses should be kept in mind (ideal=
ly everybody's minds) so that the design isn't painted into an unfo=
rtunate corner.

I agree... though I fin=
d it hard to word this into the charter.
=C2=A0

if the eventual goal is to also support real-time media, partial reliabilit=
y, and other things, there are things in draft-tsvwg-quic-protocol that i w=
ould do very differently (and did do very differently, see RFC 7016, in par=
ticular Section 1.1).

QUIC running code=
 and deployment experience is limited to HTTP/2 at this point, which is why=
 early focus is limited to the initial application-set. I think this wg wil=
l need to walk the fine line between over-engineering for the initial appli=
cation-set and becoming a kitchen sink for any/all applications. We may wel=
l learn later that to support a new application (real-time media, say) we m=
ay need to modify mechanisms in the core protocol spec, but that still seem=
s like a better process for keeping the wg coherent.

- jana

=C2=A0

-mike





--94eb2c08050826a6b1053300fd64--


From nobody Mon May 16 20:31:19 2016
Return-Path: 
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 4C57812D504 for ; Mon, 16 May 2016 20:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 t9gDOIG8yHS0 for ; Mon, 16 May 2016 20:31:15 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB6412D591 for ; Mon, 16 May 2016 20:31:15 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9C05F22E1F3; Mon, 16 May 2016 23:31:08 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Tue, 17 May 2016 13:31:06 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <1977F512-A341-400B-B7F9-E64C8E2E6786@mnot.net>
References: 
To: Ted Hardie 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , quic@ietf.org, Christian Huitema 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 03:31:18 -0000

Hi Ted,

Thanks for proposing a draft charter early.

A few comments:

> The first of these is the core transport work, which will describe the =
wire format, along with the mechanisms for connection establishment, =
stream multiplexing, data reliability, loss detection and recovery, =
congestion control, and negotiation.

What is "negotiation" in this context? Is it just QUIC versioning, or is =
it also a functional equivalent to ALPN (i.e., negotiation of the =
application protocol carried), or is it more like HTTP/2 SETTINGS (which =
is not really a negotiation mechanism, it's more like a configuration =
advertisement)?


> The third focus area will describe mappings between specific =
applications=E2=80=99 semantics and the transport facilities of QUIC. =
The first mapping will be a description of HTTP/2 semantics using QUIC, =
specifically with the goal of minimizing web latency using QUIC. Upon =
completion of that mapping, additional protocols may be added by =
updating this charter to include them.


Defining application protocols in the Transport area is a pretty big =
change around here, even if it is just mapping existing semantics to a =
new transport.=20

As everyone knows, such mappings are "leaky" -- changes under the hood =
can and will affect how people use the application. We had numerous =
examples of this in H2, and while QUIC appears to be a more =
straightforward change in this respect, it's still easy enough to have =
unintended side effects. HTTP is especially fragile in this regard, =
because of its complexity, history and breadth of use.

Note that I'm not saying I'm firmly against this approach, just =
concerned; this WG is obviously going to be very deep in transport =
discussions, and it would be easy to lose the application perspective in =
it.=20

So, can you speak to why you chose to propose this avenue, rather than =
doing the application mappings in ART groups? In other words, HTTP and =
other TCP-based protocols have been successfully defined in APPS (later =
ART) WGs until now; why is QUIC different?

Also, if this WG *is* to do the HTTP/2 mapping, more text about what =
semantics are being mapped would avoid a lot of argument down the road; =
if you say it's "all of them", that includes running HTTP without TLS.


> Milestones

It would be helpful to also propose the timing of the milestones, =
perhaps in the form of "date of chartering + n months."

HTTP/2 was chartered to ship to the IESG in two years, and we only =
overshot that goal by sixteen days (if memory serves correctly).=20

I don't think QUIC will go so... speedily? However, it's good to have =
goals, and to get consensus within the group as to how seriously it =
takes them. Getting experienced engineers to commit to an unbounded =
timeline (or one that everyone knows isn't serious) is hard, and IMO =
effects the quality of the work.=20

Cheers,

--
Mark Nottingham   https://www.mnot.net/


From nobody Mon May 16 23:39:36 2016
Return-Path: 
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 A0DD312D59B for ; Mon, 16 May 2016 23:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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=microsoft.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 lvvHvpk3zuDH for ; Mon, 16 May 2016 23:39:33 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A75212D59A for ; Mon, 16 May 2016 23:39:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9PYs58qdESmFanmR8cAyGzAFvYMDVx0QMJZuhCha8xk=; b=oSpdfAgP797ub0jdcX6j+7Qs5QK/B5ZHYF18o/YRsUPElQm2sX52cmkzmgGkUFc7cej47ugdkQC6AeYRpSkrWdD0II9dGxJRwRGPoB37xCIj+GQf8alJ3E3CT7AiDDHz6QF/gwS6xzaMR8Y+Rn48nYGK+BdbpolhZXnT4DM1QZI=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.492.11; Tue, 17 May 2016 06:39:31 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0492.020; Tue, 17 May 2016 06:39:31 +0000
From: Christian Huitema 
To: Mark Nottingham , Ted Hardie 
Thread-Topic: [QUIC] Draft charter
Thread-Index: AQHRrW/Sb0NYcU1DiUO0Xn0RTsSsY5+8fjcAgAAzxDA=
Date: Tue, 17 May 2016 06:39:31 +0000
Message-ID: 
References:  <1977F512-A341-400B-B7F9-E64C8E2E6786@mnot.net>
In-Reply-To: <1977F512-A341-400B-B7F9-E64C8E2E6786@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: mnot.net; dkim=none (message not signed) header.d=none;mnot.net; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [72.235.151.78]
x-ms-office365-filtering-correlation-id: 4297814c-8811-4b6f-c3e1-08d37e1e00c2
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 5:CmyZI2EMO2vpg1T+Xsq0+HOAVsLdHPKLVyu/U786UO84jXlX0tkaOADXppUZkEIeXZUdxLst5eqT6c7sdrtFqB9Zsx45YUDXnWktsaIbvlmasOCBbcw7AifiFmvF/h/PqszlkEyybxe5vRqm3MIwWQ==; 24:nI5RqzMDa09NCMb13D7sz0++I5riNmqozCFKPZ7qFgpS9VTpiixppDz6lTw2OYuP+InirO7z6ukdZ/XfxWderYSVIi8PKuvjxk1aVr5yaGE=; 7:t3tVyiSkjgjGZG0QVsa6Z68YrhXs7yeOSXv4OnqsoQU7MxRRGOl2cXBvTtDdmDgqdNanAW+KCwcg3yVL0pqfomVk73FwbDLE5ojWQykVNvyzfZqgoH7Mv9YvfGsw9qUpmhq6iE21nNjsVAYRu0lv6z1Cw0jIdg0maCbfYzt5tn3XioXUFQ6c6HqQadqbqwwGORMv61trVrBSxaLd7PUG+g==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0655;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; 
x-forefront-prvs: 0945B0CC72
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(24454002)(377454003)(5003600100002)(92566002)(8676002)(81166006)(10290500002)(10400500002)(5002640100001)(586003)(1220700001)(5001770100001)(5004730100002)(86362001)(2950100001)(122556002)(4326007)(102836003)(189998001)(3846002)(2900100001)(8936002)(77096005)(99286002)(2906002)(6116002)(3280700002)(74316001)(5008740100001)(11100500001)(66066001)(87936001)(33656002)(86612001)(9686002)(50986999)(8990500004)(106116001)(76576001)(3660700001)(5005710100001)(10090500001)(76176999)(54356999)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 06:39:31.3598 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655
Archived-At: 
Cc: Jana Iyengar , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 06:39:34 -0000

T24gTW9uZGF5LCBNYXkgMTYsIDIwMTYgNTozMSBQTSwgTWFyayBOb3R0aW5naGFtIHdyb3RlOiAN
Cj4gLi4uDQo+IFdoYXQgaXMgIm5lZ290aWF0aW9uIiBpbiB0aGlzIGNvbnRleHQ/IElzIGl0IGp1
c3QgUVVJQyB2ZXJzaW9uaW5nLCBvciBpcyBpdCBhbHNvIGENCj4gZnVuY3Rpb25hbCBlcXVpdmFs
ZW50IHRvIEFMUE4gKGkuZS4sIG5lZ290aWF0aW9uIG9mIHRoZSBhcHBsaWNhdGlvbiBwcm90b2Nv
bA0KPiBjYXJyaWVkKSwgb3IgaXMgaXQgbW9yZSBsaWtlIEhUVFAvMiBTRVRUSU5HUyAod2hpY2gg
aXMgbm90IHJlYWxseSBhIG5lZ290aWF0aW9uDQo+IG1lY2hhbmlzbSwgaXQncyBtb3JlIGxpa2Ug
YSBjb25maWd1cmF0aW9uIGFkdmVydGlzZW1lbnQpPw0KDQpUaGVyZSBpcyB2ZXJzaW9uaW5nLCBi
dXQgdGhhdCdzIGEgYmx1bnQgaW5zdHJ1bWVudC4gTXkgcGVyc29uYWwgbW9kZWwgaXMgbW9yZSBh
Ym91dCBUQ1AgT3B0aW9uLCB3aGljaCBvdmVyIHRpbWUgYWxsb3dlZCB0aGUgaW50cm9kdWN0aW9u
IG9mIHRpbWUgc3RhbXBzLCBzZWxlY3RpdmUgYWNrbm93bGVkZ2VtZW50cywgb3IgbXVsdGlwYXRo
IHBhcmFtZXRlcnMsIEFuIGVxdWl2YWxlbnQgZm9yIFFVSUMgd291bGQgYmUgZXhwZXJpbWVudGF0
aW9uIHdpdGggb3B0aW9ucyBmb3IgZm9yd2FyZCBlcnJvciBjb3JyZWN0aW9uIG9yIG11bHRpcGF0
aC4NCg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0KDQo=


From nobody Tue May 17 01:21:33 2016
Return-Path: 
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 F0C7012B041 for ; Tue, 17 May 2016 01:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 3PmLCyV_NaF4 for ; Tue, 17 May 2016 01:21:29 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D500912B02D for ; Tue, 17 May 2016 01:21:28 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 255F164B651D6; Tue, 17 May 2016 08:21:25 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4H8LQu6028767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 May 2016 08:21:27 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4H8LPX2016111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 May 2016 10:21:25 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 17 May 2016 10:21:25 +0200
From: "Scharf, Michael (Nokia - DE)" 
To: EXT Jana Iyengar , Martin Thomson 
Thread-Topic: [QUIC] Draft charter
Thread-Index: AQHRrXAOOvmdPtKyVEaQLm8DYQDa0J+6FUOAgADOFQCAAedZ4A==
Date: Tue, 17 May 2016 08:21:24 +0000
Message-ID: <655C07320163294895BBADA28372AF5D488543AB@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:   
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D488543ABFR712WXCHMBA15z_"
MIME-Version: 1.0
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 08:21:31 -0000

--_000_655C07320163294895BBADA28372AF5D488543ABFR712WXCHMBA15z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

T24gY29uZ2VzdGlvbiBjb250cm9sICg8bXM+KeKApg0KDQpXaGF0LCBpZiBhbnksIGVmZm9ydCBp
cyB0aGlzIGdyb3VwIGdvaW5nIHRvIHB1dCBpbnRvIGRlZmluaW5nIGENCmNvbmdlc3Rpb24gY29u
dHJvbCBtZWNoYW5pc20gYXMgb3Bwb3NlZCB0byBqdXN0IHBpY2tpbmcgb25lIChvciBtb3JlKQ0K
ZXhpc3RpbmcgbWVjaGFuaXNtcz8gIENhbiB3ZSBwdXNoIHRoaXMgbW9yZSB0b3dhcmQganVzdCBw
aWNraW5nDQpzb21ldGhpbmcsIG1heWJlIGFsbG93aW5nIGZvciBhIGZldyB0d2Vha3M/DQoNCkF0
IHRoZSBtb21lbnQsIHRoZSBjaGFydGVyIGRlbGliZXJhdGVseSBkb2VzIG5vdCBtZW50aW9uIGRl
ZmluaW5nIG9yIG5lZ290aWF0aW5nIGEgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbS4gTXkg
c3BlY2lmaWMgZXhwZWN0YXRpb24gd2FzIHRoYXQgd2UnZCBlbmQgdXAgZGVmaW5pbmcgYSBOZXdS
ZW5vLXN0eWxlIENDIGFzIGEgKG5vbi1tYW5kYXRvcnkpIGRlZmF1bHQsIHNpbmNlIGl0IGlzIG9u
ZSBDQyB0aGF0IHdpbGwgcHJvYmFibHkgbmVlZCB0byBiZSBzcGVjaWZpZWQgZm9yIFFVSUMuIFRo
YXQgc2FpZCwgQ0MgaXMgbGFyZ2VseSBhIHNlbmRlci1zaWRlIGNvbmNlcm4sIGFuZCB3aXRoIGEg
cmVhc29uYWJsZSBhY2sgbWVjaGFuaXNtLCBhIHNlbmRlciBjYW4gdW5pbGF0ZXJhbGx5IGltcGxl
bWVudCBxdWl0ZSBhIGRpdmVyc2Ugc2V0IG9mIENDIG1lY2hhbmlzbXMuIEZvbGtzIHdpbGwgdWx0
aW1hdGVseSB1c2Ugd2hhdGV2ZXIgQ0MgdGhleSB3YW50IHdpdGggUVVJQywganVzdCBhcyB0aGV5
IGRvIHdpdGggVENQIC0tIEkgZXhwZWN0IENDIGluIFFVSUMgZGVwbG95bWVudHMgdG8gYmUgYXQg
bGVhc3QgYXMgZGl2ZXJzZSBhcyBpdCBpcyBmb3IgVENQIG5vdy4gRG8geW91IHRoaW5rIHNvbWV0
aGluZyBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGNoYXJ0ZXIgdG8gY2xhcmlmeSB0aGF0IHRoZSB3
ZyBpcyBleHBlY3RlZCB0byBtYXAgZXhpc3RpbmcgVENQIENDIG9udG8gUVVJQyBhbmQgbm90IGRl
ZmluZSBuZXcgQ0MgbWVjaGFuaXNtcz8NCg0KPG1zPiBJ4oCZZCBsaWtlIHRvIHNlZSBzb21lIHN0
YXRlbWVudCBsaWtlIHRoaXMgaW4gdGhlIGNoYXJ0ZXIsIGkuZS4sIHRoYXQgbmV3IENDIG1lY2hh
bmlzbXMgYXJlIG5vdCBpbiBzY29wZSAob3IgcmVxdWlyZSByZS1jaGFydGVyaW5nKS4NCg0KPG1z
PiBJbiBnZW5lcmFsLCBJIHRoaW5rIHRoZSBjaGFydGVyIGhhcyB0byBiZSBhIGJpdCBtb3JlIGV4
cGxpY2l0IGFib3V0IGNvbmdlc3Rpb24gY29udHJvbCBhbmQg4oCcVENQLWZyaWVuZGxpbmVzc+KA
nS4gRXhwZXJpbWVudGluZyB3aXRoIENDIHNob3VsZCBiZSBzaW1wbGVyIGluIGEgdXNlci1zcGFj
ZSBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbi4gVGhpcyBpcyBib3RoIGEgcmVzZWFyY2ggb3Bwb3J0
dW5pdHksIGJ1dCBhbHNvIGFuIG9wZXJhdGlvbmFsIHJpc2suIFJlLXVzZSBvZiBUQ1AgYWxnb3Jp
dGhtcywgYXMgZmFyIGFzIGFwcGxpY2FibGUsIGNvdWxkIHJlZHVjZSB0aGUgbGF0dGVyLg0KDQpN
aWNoYWVsDQoNCg==

--_000_655C07320163294895BBADA28372AF5D488543ABFR712WXCHMBA15z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu
MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh
bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+T24gY29uZ2VzdGlvbiBjb250cm9sICgmbHQ7bXMmZ3Q7KeKApjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0
O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0
OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0LCBpZiBhbnksIGVmZm9ydCBpcyB0aGlz
IGdyb3VwIGdvaW5nIHRvIHB1dCBpbnRvIGRlZmluaW5nIGE8YnI+DQpjb25nZXN0aW9uIGNvbnRy
b2wgbWVjaGFuaXNtIGFzIG9wcG9zZWQgdG8ganVzdCBwaWNraW5nIG9uZSAob3IgbW9yZSk8YnI+
DQpleGlzdGluZyBtZWNoYW5pc21zPyZuYnNwOyBDYW4gd2UgcHVzaCB0aGlzIG1vcmUgdG93YXJk
IGp1c3QgcGlja2luZzxicj4NCnNvbWV0aGluZywgbWF5YmUgYWxsb3dpbmcgZm9yIGEgZmV3IHR3
ZWFrcz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkF0IHRoZSBtb21lbnQsIHRoZSBjaGFydGVyIGRlbGliZXJhdGVseSBkb2VzIG5v
dCBtZW50aW9uIGRlZmluaW5nIG9yIG5lZ290aWF0aW5nIGEgY29uZ2VzdGlvbiBjb250cm9sIG1l
Y2hhbmlzbS4gTXkgc3BlY2lmaWMgZXhwZWN0YXRpb24gd2FzIHRoYXQgd2UnZCBlbmQgdXAgZGVm
aW5pbmcgYSBOZXdSZW5vLXN0eWxlIENDIGFzIGEgKG5vbi1tYW5kYXRvcnkpIGRlZmF1bHQsIHNp
bmNlIGl0IGlzIG9uZSBDQyB0aGF0DQogd2lsbCBwcm9iYWJseSBuZWVkIHRvIGJlIHNwZWNpZmll
ZCBmb3IgUVVJQy4gVGhhdCBzYWlkLCBDQyBpcyBsYXJnZWx5IGEgc2VuZGVyLXNpZGUgY29uY2Vy
biwgYW5kIHdpdGggYSByZWFzb25hYmxlIGFjayBtZWNoYW5pc20sIGEgc2VuZGVyIGNhbiB1bmls
YXRlcmFsbHkgaW1wbGVtZW50IHF1aXRlIGEgZGl2ZXJzZSBzZXQgb2YgQ0MgbWVjaGFuaXNtcy4g
Rm9sa3Mgd2lsbCB1bHRpbWF0ZWx5IHVzZSB3aGF0ZXZlciBDQyB0aGV5IHdhbnQgd2l0aA0KIFFV
SUMsIGp1c3QgYXMgdGhleSBkbyB3aXRoIFRDUCAtLSZuYnNwO0kgZXhwZWN0IENDIGluIFFVSUMg
ZGVwbG95bWVudHMgdG8gYmUgYXQgbGVhc3QgYXMgZGl2ZXJzZSBhcyBpdCBpcyBmb3IgVENQIG5v
dy4gRG8geW91IHRoaW5rIHNvbWV0aGluZyBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGNoYXJ0ZXIg
dG8gY2xhcmlmeSB0aGF0IHRoZSB3ZyBpcyBleHBlY3RlZCB0byBtYXAgZXhpc3RpbmcgVENQIEND
IG9udG8gUVVJQyBhbmQgbm90IGRlZmluZSBuZXcgQ0MNCiBtZWNoYW5pc21zPzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+Jmx0O21zJmd0OyBJ4oCZZCBsaWtlIHRvIHNlZSBzb21lIHN0YXRlbWVu
dCBsaWtlIHRoaXMgaW4gdGhlIGNoYXJ0ZXIsIGkuZS4sIHRoYXQgbmV3IENDIG1lY2hhbmlzbXMg
YXJlIG5vdCBpbiBzY29wZSAob3IgcmVxdWlyZSByZS1jaGFydGVyaW5nKS48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZs
dDttcyZndDsgSW4gZ2VuZXJhbCwgSSB0aGluayB0aGUgY2hhcnRlciBoYXMgdG8gYmUgYSBiaXQg
bW9yZSBleHBsaWNpdCBhYm91dCBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIOKAnFRDUC1mcmllbmRs
aW5lc3PigJ0uIEV4cGVyaW1lbnRpbmcgd2l0aCBDQyBzaG91bGQgYmUgc2ltcGxlcg0KIGluIGEg
dXNlci1zcGFjZSBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbi4gVGhpcyBpcyBib3RoIGEgcmVzZWFy
Y2ggb3Bwb3J0dW5pdHksIGJ1dCBhbHNvIGFuIG9wZXJhdGlvbmFsIHJpc2suIFJlLXVzZSBvZiBU
Q1AgYWxnb3JpdGhtcywgYXMgZmFyIGFzIGFwcGxpY2FibGUsIGNvdWxkIHJlZHVjZSB0aGUgbGF0
dGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+TWljaGFlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_655C07320163294895BBADA28372AF5D488543ABFR712WXCHMBA15z_--


From nobody Tue May 17 12:23:32 2016
Return-Path: 
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 60D6312D50F for ; Tue, 17 May 2016 12:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 LoagZCN_nTRt for ; Tue, 17 May 2016 12:23:28 -0700 (PDT)
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 2AC2E12D836 for ; Tue, 17 May 2016 12:23:28 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id x189so25941273ywe.3 for ; Tue, 17 May 2016 12:23:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jwozG5DOr/JpUKDlmKIl9+802ey56OovZQpJ4CvXuEs=; b=WYHCym3ToZ9bHLvIYw9FgI1YAv1+RxV+BIlVaymrHYJAczvFZyAR7EzcJMUVmLq74Q OXdFKJDLZrUKV7BMAJCoTCt7hcz5SjaXwjk7fKQSFiwfhRfD28qxkxZke2aLCMpL3qMt tGFtAe4b77JPxfM5wLRse0d7dWVSINKhua65JSPOjmYNZf1Pb4ts2A80y4mxSbDlv43o Tpe9rtH4t57OYwgJetZC79di10sZKNuMiypKxL8Et5wZJ4NLfdzEs3JXaaqtSEBo0eaD 49JBicblHXmuJDpgEYlSHn+XamucCF552ll0wn47OrRlSDuMvMObEYsTR/nDLo9dYrID kSAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jwozG5DOr/JpUKDlmKIl9+802ey56OovZQpJ4CvXuEs=; b=FaXQ6JHP4weWi/gFtqt6NsE4fltnCUYhHECpJbeYvav1lkYD5sqTmMcLvEqOGrLdGA BmviCTLgdNKT4Z5GM2Sv/H7LnsvEgjCfmYTNzwoCuxFDafO7PBtXilCEA6VTrglLXX0p nyyBGdQnOflrkUv4f0DLmQHxD1hzsXpX3loLUYJOEfySoMQLZf2UdI+NLwi964F1kKrk 8YTyggxRR4mpGgKli9UgVeiRr8GsRiEmpbOVG4G5dhQpHbOluwjYdjS9zJfJ2PGvGQWd 1AJvAvFdnQk8XzoIoD79uyYUeOOFVc9aMfZ3EGHSBoo7/5t/LmKti4njnGgWxJz/rE79 mceA==
X-Gm-Message-State: AOPr4FVrtX0S/XvrX1yaxKRdeuAVoo1o11T50soVLFDax0C3AJ4nJJQB95LqEnEra0J9BaAfU0PVXd4fzrRxv7N7
X-Received: by 10.129.121.81 with SMTP id u78mr1594691ywc.239.1463513007328; Tue, 17 May 2016 12:23:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Tue, 17 May 2016 12:23:25 -0700 (PDT)
In-Reply-To: <1977F512-A341-400B-B7F9-E64C8E2E6786@mnot.net>
References:  <1977F512-A341-400B-B7F9-E64C8E2E6786@mnot.net>
From: Jana Iyengar 
Date: Tue, 17 May 2016 12:23:25 -0700
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=94eb2c0a7b68eda63105330eac6a
Archived-At: 
Cc: Christian Huitema , Ted Hardie , quic@ietf.org
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 19:23:31 -0000

--94eb2c0a7b68eda63105330eac6a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks, Mark. Responses inline:

On Mon, May 16, 2016 at 8:31 PM, Mark Nottingham  wrote:

> Hi Ted,
>
> Thanks for proposing a draft charter early.
>
> A few comments:
>
> > The first of these is the core transport work, which will describe the
> wire format, along with the mechanisms for connection establishment, stre=
am
> multiplexing, data reliability, loss detection and recovery, congestion
> control, and negotiation.
>
> What is "negotiation" in this context? Is it just QUIC versioning, or is
> it also a functional equivalent to ALPN (i.e., negotiation of the
> application protocol carried), or is it more like HTTP/2 SETTINGS (which =
is
> not really a negotiation mechanism, it's more like a configuration
> advertisement)?
>

This was supposed to be just QUIC versions. I'm changing the charter text
to say "version negotiation."
(HTTP/2 SETTINGS, though orthogonal to the negotiation described in the
charter, is useful, and is something that may be worth having in QUIC.)

> The third focus area will describe mappings between specific
> applications=E2=80=99 semantics and the transport facilities of QUIC. The=
 first
> mapping will be a description of HTTP/2 semantics using QUIC, specificall=
y
> with the goal of minimizing web latency using QUIC. Upon completion of th=
at
> mapping, additional protocols may be added by updating this charter to
> include them.
>
>
> Defining application protocols in the Transport area is a pretty big
> change around here, even if it is just mapping existing semantics to a ne=
w
> transport.
>
> As everyone knows, such mappings are "leaky" -- changes under the hood ca=
n
> and will affect how people use the application. We had numerous examples =
of
> this in H2, and while QUIC appears to be a more straightforward change in
> this respect, it's still easy enough to have unintended side effects. HTT=
P
> is especially fragile in this regard, because of its complexity, history
> and breadth of use.
>
> Note that I'm not saying I'm firmly against this approach, just concerned=
;
> this WG is obviously going to be very deep in transport discussions, and =
it
> would be easy to lose the application perspective in it.
>
> So, can you speak to why you chose to propose this avenue, rather than
> doing the application mappings in ART groups? In other words, HTTP and
> other TCP-based protocols have been successfully defined in APPS (later
> ART) WGs until now; why is QUIC different?
>

I can share my thinking, I'm sure Ted will share his too. My first reason
was that having application(s) that intend to use the transport in the same
wg helps guide transport conversations, and helps define scope. It wasn't
to take the work out of ART as much as it was to bring in a guide to the
TSVAREA work. That said, ART, perhaps specifically HTTPBIS, should be
strongly involved in the mapping document for all the reasons you point
out. If the right way to do this is to move the doc to a home in ART, I'm
not strongly opposed to it. I would still want to have HTTP/2 in the QUIC
charter for the TSV work.

My second reason was to have ART mindshare present in the wg discussions.
The work you point out as having been done in ART largely uses a
pre-fabricated transport (TCP for HTTP, SCTP for WebRTC). QUIC is about to
be defined, and that does make it different from this past work, since the
mapping document will evolve as QUIC in the wg does.

I'm not against moving the mapping doc to a different home in ART.
Alternatively, we could also consider an ART liaison to this wg, just as we
are proposing a SAAG liaison for the TLS1.3 mapping document.

Also, if this WG *is* to do the HTTP/2 mapping, more text about what
> semantics are being mapped would avoid a lot of argument down the road; i=
f
> you say it's "all of them", that includes running HTTP without TLS.
>

Fair point. (I was going to say "all of them" :-)) Since QUIC itself is
being proposed as an encrypted transport, the proposed mapping is limited
to HTTPS (I can add some text to this effect.) Are you looking for other
specificity in terms of HTTP/2 semantics?


> > Milestones
>
> It would be helpful to also propose the timing of the milestones, perhaps
> in the form of "date of chartering + n months."
>
> HTTP/2 was chartered to ship to the IESG in two years, and we only
> overshot that goal by sixteen days (if memory serves correctly).
>
> I don't think QUIC will go so... speedily? However, it's good to have
> goals, and to get consensus within the group as to how seriously it takes
> them. Getting experienced engineers to commit to an unbounded timeline (o=
r
> one that everyone knows isn't serious) is hard, and IMO effects the quali=
ty
> of the work.


Agreed. I love that HTTP/2 delivered so close to the originally proposed
timeline. As you point out though, QUIC is a much deeper cut, which tends
to increase both the the length and variance of expected completion times.
Nevertheless, your point is  taken. We can come up with some milestones,
and have the list bash them.

- jana

Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>

--94eb2c0a7b68eda63105330eac6a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks, Mark. Responses inline:

On Mon, May 16, 2016 at 8:31 PM, Mark No=
ttingham <mnot@mnot.n=
et> wrote:
Hi Ted,



Thanks for proposing a draft charter early.



A few comments:



> The first of these is the core transport work, which will describe the=
 wire format, along with the mechanisms for connection establishment, strea=
m multiplexing, data reliability, loss detection and recovery, congestion c=
ontrol, and negotiation.



What is "negotiation" in this context? Is it just QUIC versioning=
, or is it also a functional equivalent to ALPN (i.e., negotiation of the a=
pplication protocol carried), or is it more like HTTP/2 SETTINGS (which is =
not really a negotiation mechanism, it's more like a configuration adve=
rtisement)?

This was supposed to be jus=
t QUIC versions. I'm changing the charter text to say "version neg=
otiation."
(HTTP/2 SETTINGS, though orthogonal to the negoti=
ation described in the charter, is useful, and is something that may be wor=
th having in QUIC.)


> The third focus area will describe mappings between specific applicati=
ons=E2=80=99 semantics and the transport facilities of QUIC. The first mapp=
ing will be a description of HTTP/2 semantics using QUIC, specifically with=
 the goal of minimizing web latency using QUIC. Upon completion of that map=
ping, additional protocols may be added by updating this charter to include=
 them.





Defining application protocols in the Transport area is a pretty big change=
 around here, even if it is just mapping existing semantics to a new transp=
ort.



As everyone knows, such mappings are "leaky" -- changes under the=
 hood can and will affect how people use the application. We had numerous e=
xamples of this in H2, and while QUIC appears to be a more straightforward =
change in this respect, it's still easy enough to have unintended side =
effects. HTTP is especially fragile in this regard, because of its complexi=
ty, history and breadth of use.



Note that I'm not saying I'm firmly against this approach, just con=
cerned; this WG is obviously going to be very deep in transport discussions=
, and it would be easy to lose the application perspective in it.



So, can you speak to why you chose to propose this avenue, rather than doin=
g the application mappings in ART groups? In other words, HTTP and other TC=
P-based protocols have been successfully defined in APPS (later ART) WGs un=
til now; why is QUIC different?

I can s=
hare my thinking, I'm sure Ted will share his too. My first reason was =
that having application(s) that intend to use the transport in the same wg =
helps guide transport conversations, and helps define scope. It wasn't =
to take the work out of ART as much as it was to bring in a guide to the TS=
VAREA work. That said, ART, perhaps specifically HTTPBIS, should be strongl=
y involved in the mapping document for all the reasons you point out. If th=
e right way to do this is to move the doc to a home in ART, I'm not str=
ongly opposed to it. I would still want to have HTTP/2 in the QUIC charter =
for the TSV work.

My second reason was to have ART=
 mindshare present in the wg discussions. The work you point out as having =
been done in ART largely uses a pre-fabricated transport (TCP for HTTP, SCT=
P for WebRTC). QUIC is about to be defined, and that does make it different=
 from this past work, since the mapping document will evolve as QUIC in the=
 wg does.

I'm not against moving the mapping d=
oc to a different home in ART. Alternatively, we could also consider an ART=
 liaison to this wg, just as we are proposing a SAAG liaison for the TLS1.3=
 mapping document.


Also, if this WG *is* to do the HTTP/2 mapping, more text about what semant=
ics are being mapped would avoid a lot of argument down the road; if you sa=
y it's "all of them", that includes running HTTP without TLS.=


Fair point. (I was going to say "=
all of them" :-)) Since QUIC itself is being proposed as an encrypted =
transport, the proposed mapping is limited to HTTPS (I can add some text to=
 this effect.) Are you looking for other specificity in terms of HTTP/2 sem=
antics?
=C2=A0

> Milestones



It would be helpful to also propose the timing of the milestones, perhaps i=
n the form of "date of chartering + n months."



HTTP/2 was chartered to ship to the IESG in two years, and we only overshot=
 that goal by sixteen days (if memory serves correctly).



I don't think QUIC will go so... speedily? However, it's good to ha=
ve goals, and to get consensus within the group as to how seriously it take=
s them. Getting experienced engineers to commit to an unbounded timeline (o=
r one that everyone knows isn't serious) is hard, and IMO effects the q=
uality of the work.

Agreed. I love that HTT=
P/2 delivered so close to the originally proposed timeline. As you point ou=
t though, QUIC is a much deeper cut, which tends to increase both the the l=
ength and variance of expected completion times. Nevertheless, your point i=
s =C2=A0taken. We can come up with some milestones, and have the list bash =
them.

- jana

=


Cheers,



--

Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/







--94eb2c0a7b68eda63105330eac6a--


From nobody Tue May 17 12:31:37 2016
Return-Path: 
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 2BEEE12DD69 for ; Tue, 17 May 2016 12:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 wCzekHOGiEBX for ; Tue, 17 May 2016 12:31:34 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 733EC12D92D for ; Tue, 17 May 2016 12:31:26 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id x189so26160503ywe.3 for ; Tue, 17 May 2016 12:31:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WTW0cGN8gRxhtvYOmufX/n3PJlQ6Nki4NV81parg2Ag=; b=Y1tvL5NQN+s/xpgOEy8ICsGgjbcmMysO53zF8rrVLSadX1iBG4twyAVYzQWde5aGXh F/hRcqEOfkJKbEwfeeh4XZzQ3usayxESt083pYc0nRky7yz8U7MjJ97TbZrz4BZ+uel9 kewIO3Zcqhtnc388faZrEqhj5TJZVtzy08YO6vxqr1vFoF3qK0QkawFEcXquhiqOKHYY Q+1C+6a1b9D6R6N0C0sWdCdSDRMcqn9nDBvOjR40U2lR9VYr0Ok+G5QaJ5tJe2+HXfKg jGMM4Ny5eJLhOlN+SsRTGJudLIk5oIOpK+emz4l8cif3g9kIg6z7lfIoKuRPf7Qd2sdo 8iig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WTW0cGN8gRxhtvYOmufX/n3PJlQ6Nki4NV81parg2Ag=; b=Ema3LjyY8yYIUutzB3DSTQzrPJGUr9M/lgnq0e9ZW1MD8qd7xlbM+AVU31MPBl5HAM csuWPl7eUi1/jspim+pREcmmFk+XGqJWiVOzws+kCsa3jj4ByFLc867+JlNt67+dHCa1 jg/haO5tR3ZQLwrUyvHjqXABzGmCIUEBjDSAjC+kzV4roWPb1yweEWB8dEqhAKPGLaiF 7bdL/Fa/HA52jpKQ92HECEDU8oRUPPdqZqrjCle7zqS9qBRTvytNwxOwarn+aqIV9Gml gBFeWETMuO1QD+dL96AkKBUFysmRwS7AJ95RpnFf4+4nYO57lsWh1OhQkgXytnPa269K oMeQ==
X-Gm-Message-State: AOPr4FVjyrpSc7dJqtuNXKAf7Sq1fpfO3177IjDRJqxQ7DCI5RqSZ9K3nDc26rv6TNQNYEJKKPOCalr5EVMEd4ZE
X-Received: by 10.37.58.198 with SMTP id h189mr1584992yba.165.1463513485665; Tue, 17 May 2016 12:31:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Tue, 17 May 2016 12:31:23 -0700 (PDT)
In-Reply-To: 
References:  <1977F512-A341-400B-B7F9-E64C8E2E6786@mnot.net> 
From: Jana Iyengar 
Date: Tue, 17 May 2016 12:31:23 -0700
Message-ID: 
To: Christian Huitema 
Content-Type: multipart/alternative; boundary=001a114bc13670652d05330ec99c
Archived-At: 
Cc: Mark Nottingham , "quic@ietf.org" , Ted Hardie 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 19:31:35 -0000

--001a114bc13670652d05330ec99c
Content-Type: text/plain; charset=UTF-8

On Mon, May 16, 2016 at 11:39 PM, Christian Huitema 
wrote:

> On Monday, May 16, 2016 5:31 PM, Mark Nottingham wrote:
> > ...
> > What is "negotiation" in this context? Is it just QUIC versioning, or is
> it also a
> > functional equivalent to ALPN (i.e., negotiation of the application
> protocol
> > carried), or is it more like HTTP/2 SETTINGS (which is not really a
> negotiation
> > mechanism, it's more like a configuration advertisement)?
>
> There is versioning, but that's a blunt instrument. My personal model is
> more about TCP Option, which over time allowed the introduction of time
> stamps, selective acknowledgements, or multipath parameters, An equivalent
> for QUIC would be experimentation with options for forward error correction
> or multipath.


These are two different things in my mental model, and they're both useful.
The version tells you how to interpret the basic wire format, and
importantly allows you to change the wire format; options is for feature
negotiation. I think it's important for us to have an options negotiation
mechanism as well. Do you think this is worth calling out explicitly
("version negotiation, and feature negotiation")?

- jana


> -- Christian Huitema
>
>
>

--001a114bc13670652d05330ec99c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 16, 2016 at 11:39 PM, Christian Huitema <huitema@microsoft.com=
> wrote:
On Monday, May 16,=
 2016 5:31 PM, Mark Nottingham wrote:

> ...

> What is "negotiation" in this context? Is i=
t just QUIC versioning, or is it also a

> functional equivalent to ALPN (i.e., negotiation of the application pr=
otocol

> carried), or is it more like HTTP/2 SETTINGS (which is not really a ne=
gotiation

> mechanism, it's more like a configuration advertisement)?



There is versioning, but that's a blunt instrument. My personal =
model is more about TCP Option, which over time allowed the introduction of=
 time stamps, selective acknowledgements, or multipath parameters, An equiv=
alent for QUIC would be experimentation with options for forward error corr=
ection or multipath.

These are two differen=
t things in my mental model, and they're both useful. The version tells=
 you how to interpret the basic wire format, and importantly allows you to =
change the wire format; options is for feature negotiation. I think it'=
s important for us to have an options negotiation mechanism as well. Do you=
 think this is worth calling out explicitly ("version negotiation, and=
 feature negotiation")?
=C2=A0
- jana


-- Christian Huitema









--001a114bc13670652d05330ec99c--


From nobody Tue May 17 12:40:15 2016
Return-Path: 
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 6B9DA12DD68 for ; Tue, 17 May 2016 12:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 lx74Q9fTNHmM for ; Tue, 17 May 2016 12:40:11 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 B42D312D9E5 for ; Tue, 17 May 2016 12:40:11 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id g133so26469986ywb.2 for ; Tue, 17 May 2016 12:40:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aqg6gMj3lzcdJVjSqJta38kMphXR4VspYqw4Ftvb+tw=; b=Zhrbf8AAi+yVtWvTTclncMDjsdc4zHCJuzwgHQ/hLtEUFIJ99eeG9uFEcmbDWfAjiU A505HG8mz6Sz33Z0AxXEevpxHW0bjRV3hJOzZDbqU7+2tdde3z8bUAjzQSVFwIWP6oHJ y3hACNMq0uNsJ/Vogb92LicNj2hvKNiKaWebv6PQIBk2jLh7FrC20OVLpCnhsuObB1Zm 25gzd9a7QtXHVRbFyzyYwVJ2Ps/54/osFx/BZ218pM5m0Hu85JGZlaA2Fh28mAFBe8fd OfJ9jKJFGPC7Doww93LWd3pGPaYH4agOHnSL1RlC5M34uzHfcRHVXUcsUSwJVMTFNYph gxVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aqg6gMj3lzcdJVjSqJta38kMphXR4VspYqw4Ftvb+tw=; b=kTzNUyfYlLDkVmn8Npad0bulY8oNNAbB/NnPvVW1bSZvoxNGrkJGZ1YpIudHuj71vb YN1uwdwP7eSYe6uTLmKFqG8JCGbPZohWeWqZMit3AX7lMe3Pz+q2iWszPKMn90z4CWkI 6GlrrYb6CYPLU1LoZCGCvN5b16NSvJesHBiFdsbteUYw31jyzVzGwiRrQxfw5oePLxhJ vKYsyytEhn8xJ0Zs8ZV6tHkjQLiORVS2k12nyoT24nP9sjOeJ8O9Hgd8P6HhszyYSqe8 MbyvpQUL/k8AF3iq1DW0MkWypOEXgLz5oVRbewqD73632pcrPykr3fS8hGke4C/7QmmF JMcg==
X-Gm-Message-State: AOPr4FXnmlYm3fjYb/832XGuF4H0FeTS8nACuoOuKd79CoQErmNVpd+Oo7s4IjyPmNPgieiKpB6YrynfcI98X8Y3
X-Received: by 10.13.237.1 with SMTP id w1mr1703547ywe.62.1463514010881; Tue, 17 May 2016 12:40:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Tue, 17 May 2016 12:40:09 -0700 (PDT)
In-Reply-To: <655C07320163294895BBADA28372AF5D488543AB@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:    <655C07320163294895BBADA28372AF5D488543AB@FR712WXCHMBA15.zeu.alcatel-lucent.com>
From: Jana Iyengar 
Date: Tue, 17 May 2016 12:40:09 -0700
Message-ID: 
To: "Scharf, Michael (Nokia - DE)" 
Content-Type: multipart/alternative; boundary=94eb2c0864a8be66cd05330ee859
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" , Martin Thomson 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 19:40:15 -0000

--94eb2c0864a8be66cd05330ee859
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 17, 2016 at 1:21 AM, Scharf, Michael (Nokia - DE) <
michael.scharf@nokia.com> wrote:

> On congestion control ()=E2=80=A6
>
>
>
> What, if any, effort is this group going to put into defining a
> congestion control mechanism as opposed to just picking one (or more)
> existing mechanisms?  Can we push this more toward just picking
> something, maybe allowing for a few tweaks?
>
>
>
> At the moment, the charter deliberately does not mention defining or
> negotiating a congestion control mechanism. My specific expectation was
> that we'd end up defining a NewReno-style CC as a (non-mandatory) default=
,
> since it is one CC that will probably need to be specified for QUIC. That
> said, CC is largely a sender-side concern, and with a reasonable ack
> mechanism, a sender can unilaterally implement quite a diverse set of CC
> mechanisms. Folks will ultimately use whatever CC they want with QUIC, ju=
st
> as they do with TCP -- I expect CC in QUIC deployments to be at least as
> diverse as it is for TCP now. Do you think something should be added to t=
he
> charter to clarify that the wg is expected to map existing TCP CC onto QU=
IC
> and not define new CC mechanisms?
>
>
>
>  I=E2=80=99d like to see some statement like this in the charter, i.e=
., that
> new CC mechanisms are not in scope (or require re-chartering).
>

Thanks -- I'm adding text to the charter to say this.


>  In general, I think the charter has to be a bit more explicit about
> congestion control and =E2=80=9CTCP-friendliness=E2=80=9D. Experimenting =
with CC should be
> simpler in a user-space protocol implementation. This is both a research
> opportunity, but also an operational risk. Re-use of TCP algorithms, as f=
ar
> as applicable, could reduce the latter.
>

I think this probably belongs in the protocol spec where we define a basic
default CC for QUIC (which I expect will be a mapping of major parts RFC
5681 to QUIC.) I don't think this belongs in the charter, since the plan is
to not have new CC be defined in this wg.

- jana


>
>
> Michael
>
>
>

--94eb2c0864a8be66cd05330ee859
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, May 17, 2016 at 1:21 AM, Scharf, Michael (Nokia - DE) <michael.=
scharf@nokia.com> wrote:











On congestion control (&l=
t;ms>)=E2=80=A6












=C2=A0






What, if any, effort is this group going to put into=
 defining a

congestion control mechanism as opposed to just picking one (or more)

existing mechanisms?=C2=A0 Can we push this more toward just picking

something, maybe allowing for a few tweaks?






=C2=A0






At the moment, the charter deliberately does not men=
tion defining or negotiating a congestion control mechanism. My specific ex=
pectation was that we'd end up defining a NewReno-style CC as a (non-ma=
ndatory) default, since it is one CC that
 will probably need to be specified for QUIC. That said, CC is largely a se=
nder-side concern, and with a reasonable ack mechanism, a sender can unilat=
erally implement quite a diverse set of CC mechanisms. Folks will ultimatel=
y use whatever CC they want with
 QUIC, just as they do with TCP --=C2=A0I expect CC in QUIC deployments to =
be at least as diverse as it is for TCP now. Do you think something should =
be added to the charter to clarify that the wg is expected to map existing =
TCP CC onto QUIC and not define new CC
 mechanisms?






=C2=A0


<ms> I=E2=80=99d li=
ke to see some statement like this in the charter, i.e., that new CC mechan=
isms are not in scope (or require re-chartering).

Thanks -- I'=
;m adding text to the charter to say this.
=C2=A0<=
/div>


<ms> In general, I =
think the charter has to be a bit more explicit about congestion control an=
d =E2=80=9CTCP-friendliness=E2=80=9D. Experimenting with CC should be simpl=
er
 in a user-space protocol implementation. This is both a research opportuni=
ty, but also an operational risk. Re-use of TCP algorithms, as far as appli=
cable, could reduce the latter.

I think this probably belongs in =
the protocol spec where we define a basic default CC for QUIC (which I expe=
ct will be a mapping of major parts RFC 5681 to QUIC.) I don't think th=
is belongs in the charter, since the plan is to not have new CC be defined =
in this wg.

- jana
=C2=A0
=C2=A0

Michael


=C2=A0




















--94eb2c0864a8be66cd05330ee859--


From nobody Tue May 17 13:03:07 2016
Return-Path: 
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 ABFA712DDC2 for ; Tue, 17 May 2016 13:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 ctrx_CtBaK_6 for ; Tue, 17 May 2016 13:02:58 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 B767712DDAE for ; Tue, 17 May 2016 13:02:56 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id r12so4739034wme.0 for ; Tue, 17 May 2016 13:02:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=lU6pYQuJLb/P1FoWkDHqslXERvVRH9BOSkK236hnFUU=; b=LL52Mglhub1zuVbtQr2m7mJuY5STFN7UJLMjXlebysHJNv0TtZLRfg5ITjmP0+5h5J UFkE7TMabipY4zfuwlRFGijtvXEHcXwgOJhw2ElcPBraOfvsGrGT6aCikPDw5+3BEQyI YlBnZ1YA2Amjsgqe5HT+O5cOYC6U+QXzpezskbBwjxAgEE+8nIEa+MfAGj6KEpQqYJIH FMTG9Gy6erWS41qxv/aWiU2StgUguXaJJ1h+Jqlz4OdHqJmb4WO2fkRn6FJGj8TFUaXm G8v+l6ZghpEK0oJKYZEX1bDu0oPxd7H0Yf+XiSbmvVVtymrTLt4YGrEJV+Hh9+Bguxcs 8Kaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lU6pYQuJLb/P1FoWkDHqslXERvVRH9BOSkK236hnFUU=; b=czdbyKECjBiKwafqKiUX6YohC6v7YdD/cGFmzFKedXOpE1K4Wjo94Z3AHDjHAa7fvy NgrTVKb+BV179eiCUF4P3nN8VQuqNk8H6LYJaI/g/SfbRAbLEnnzr6ACEYablU58ylFP fyJcjw7CQegCIEX7q4HXfy+B7/+azzHaTNQGES3nNqFDkxUu36IEzQs5gd7Hmd6oi9GN oZ+ntAbT9fYlyLgHs2UiDNjejudenv3RbMiZeEYQEJfRi+ff8s+LqChdgtT8VSeHf8lK TSyIuhmAGjD5yGbwCjKw/KnpXlS26V0OPxZkXLv4gfVf2M63HdVTHe/HX9TlP0Ub0/yN M90A==
X-Gm-Message-State: AOPr4FWN9lf+H4Sx8c8v83csxLI3hEZewW2/AFlvmUu5UJ2FGg8u0poc2LuQNYU790qGasGMFWY/SHt8GSvZO18Go7OnaM93EVVUA8ICpO+4LY7jdq/JC6By
X-Received: by 10.28.154.73 with SMTP id c70mr3551822wme.12.1463515375257; Tue, 17 May 2016 13:02:55 -0700 (PDT)
Received: from mbpobo.local ([87.66.241.94]) by smtp.gmail.com with ESMTPSA id g132sm5334731wme.0.2016.05.17.13.02.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 13:02:54 -0700 (PDT)
To: Jana Iyengar , "Scharf, Michael (Nokia - DE)" 
References:    <655C07320163294895BBADA28372AF5D488543AB@FR712WXCHMBA15.zeu.alcatel-lucent.com> 
From: Olivier Bonaventure 
Message-ID: 
Date: Tue, 17 May 2016 22:02:52 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" , Martin Thomson 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 20:03:07 -0000

Jana,
>
>      In general, I think the charter has to be a bit more explicit
>     about congestion control and =93TCP-friendliness=94. Experimenting wi=
th
>     CC should be simpler in a user-space protocol implementation. This
>     is both a research opportunity, but also an operational risk. Re-use
>     of TCP algorithms, as far as applicable, could reduce the latter.
>
>
> I think this probably belongs in the protocol spec where we define a
> basic default CC for QUIC (which I expect will be a mapping of major
> parts RFC 5681 to QUIC.) I don't think this belongs in the charter,
> since the plan is to not have new CC be defined in this wg.

I think that it is useful to mention in the charter that the WG will not=20
design a new Congestion Control scheme but simply adapt the existing TCP=20
and Multipath TCP congestion control schemes to QUIC.

Olivier


--=20

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended=
=20
solely for the use of the individual or entity to whom they are addressed.=
=20
If you have received this email in error please notify the system manager.=
=20
This message contains confidential information and is intended only for the=
=20
individual named. If you are not the named addressee you should not=20
disseminate, distribute or copy this e-mail. Please notify the sender=20
immediately by e-mail if you have received this e-mail by mistake and=20
delete this e-mail from your system. If you are not the intended recipient=
=20
you are notified that disclosing, copying, distributing or taking any=20
action in reliance on the contents of this information is strictly=20
prohibited.


From nobody Tue May 17 15:14:53 2016
Return-Path: 
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 59D2A12DAA4 for ; Tue, 17 May 2016 15:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 H0JpwP0iX_OE for ; Tue, 17 May 2016 15:14:48 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 8E95C12DAA9 for ; Tue, 17 May 2016 15:14:48 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id k142so48480719oib.1 for ; Tue, 17 May 2016 15:14:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:cc; bh=T6wMrlxeWfq4yvN8ye8miKMV98STdjFgbzFlk2slUp8=; b=0s6u97gwo8n7gWV1tvY5H6YHFW5wpejlNZEKuFP/havOcS7td1hkKfNBBieGtCTA7t 87gm+2QAIz6JHzt1PEoda5e/KoHaNlmlfWsQbCu9dcp17DFuFXGxGIomYMf7LQCqcrks xyRz0YPUw+ZrUDspXOgcNcNv1pzzG+RUZWKOBb51cLHUiHiO48k2peXInUsdVw6x3Y6H b2eRe+ucUAkLFk1JOMvsaoVrrUs82hrdrC3mCkS2dKcGEBHbYjUmF2r+H/nDB26wEOqK sYalYjRt8dtskHHRaZzDxIbNUnd26HTfTLRTInY89q4HTBAr7qSpfy7haRKw1K2K3dxT zumg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=T6wMrlxeWfq4yvN8ye8miKMV98STdjFgbzFlk2slUp8=; b=Tpxo15ZnJ+/tYE8hzEjunPLP3RNrM9t4fP9BeCN6/U5he0qOgrlvVYiH4YGTR6etpX URvy1HO0zhomIC3PhiSgR2adz/nonFpe/bsjqWDhh0+PbEoGjRhrXfINiESup0d+ctZj PmBT5vdMXuvayCoJU1eaGmw2+dYD01TmaG6mJ7J9Pd0ND7ytOwhpTwdEmLOK9oggG9B2 nT3/tuiaPGqwo289yjg6JHYpFtddVO9DeAbsZVJl2uhl1IlbDM/7caGrtOz0IyCdwOy7 /PHLFy7WN48nMdWhkzaQp6ESafCa6v1A19+hZrFRXsy8h15xLCm8Zw+LwSNinhXKdwsT r3kg==
X-Gm-Message-State: AOPr4FWeywuuOctP1x/WeJ3AjPN0dvKeLxHrghcvn7Pga1fVvlOIAT1Y7BmN6JQjzu2mVjIcM5G7FXA7wGCEpg==
X-Received: by 10.202.240.68 with SMTP id o65mr2282185oih.0.1463523287918; Tue, 17 May 2016 15:14:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.213.210 with HTTP; Tue, 17 May 2016 15:14:28 -0700 (PDT)
From: Ted Hardie 
Date: Tue, 17 May 2016 15:14:28 -0700
Message-ID: 
To: Jana Iyengar 
Content-Type: multipart/alternative; boundary=94eb2c08fa66b27381053311114e
Archived-At: 
Cc: Christian Huitema , Mark Nottingham , quic@ietf.org
Subject: [QUIC] Choice of area
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 22:14:50 -0000

--94eb2c08fa66b27381053311114e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I've changed the subject on this, since I want to focus on a particular
topic.

Comments in-line:

On Tue, May 17, 2016 at 12:23 PM, Jana Iyengar  wrote:

> Thanks, Mark. Responses inline:
>
>>  The third focus area will describe mappings between specific
>> applications=E2=80=99 semantics and the transport facilities of QUIC. Th=
e first
>> mapping will be a description of HTTP/2 semantics using QUIC, specifical=
ly
>> with the goal of minimizing web latency using QUIC. Upon completion of t=
hat
>> mapping, additional protocols may be added by updating this charter to
>> include them.
>>
>>
>> Defining application protocols in the Transport area is a pretty big
>> change around here, even if it is just mapping existing semantics to a n=
ew
>> transport.
>>
>> As everyone knows, such mappings are "leaky" -- changes under the hood
>> can and will affect how people use the application. We had numerous
>> examples of this in H2, and while QUIC appears to be a more straightforw=
ard
>> change in this respect, it's still easy enough to have unintended side
>> effects. HTTP is especially fragile in this regard, because of its
>> complexity, history and breadth of use.
>>
>> Note that I'm not saying I'm firmly against this approach, just
>> concerned; this WG is obviously going to be very deep in transport
>> discussions, and it would be easy to lose the application perspective in=
 it.
>>
>>
I think you're right that this is a serious concern, but my thinking is
that we have this concern either way.  You could avoid that by serializing
the transport work to finish before any mapping started, but that would be
slow.  It would also risk the transport developing without the driving use
case focus that has helped the pre-standards work progress.

If we try to do the mapping work in a different/area working group while
the transport work is still ongoing, we need a very tight coordination
between the two groups throughout the work.  Basically, everyone interested
will have to be in both; given that it will not be the only topic in either
group, that's going to be distracting as well as logistically difficult.

If you're not willing to serialize,  in other words, I think you have to
pick one to have the work.  Given that QUIC will eventually have more than
one mapping, I think it makes sense to do it in a working group focused on
QUIC.  There is no question that a QUIC working group with this charter
would need the eyes of an HTTP-focused set of contributors for this
mapping.  To some extent, that means we're asking the indulgence of the
HTTP-focused community for splitting their attention for a time;
ultimately, though, I think they would have had to do that anyway.

>
> Also, if this WG *is* to do the HTTP/2 mapping, more text about what
> semantics are being mapped would avoid a lot of argument down the road; i=
f
> you say it's "all of them", that includes running HTTP without TLS.
>


I think the intent is to cover HTTP/2 semantics for an encrypted transport,
but further assistance in conveying that would be gratefully received.

> Milestones
>
> It would be helpful to also propose the timing of the milestones, perhaps
> in the form of "date of chartering + n months."
>
> That's a great idea; I didn't want to put in dates when I didn't have a
start date in hand, but we'll try to put a strawman together with that
approach.

regards,

Ted

--94eb2c08fa66b27381053311114e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I've changed the subject on this, since I want to=
 focus on a particular topic.

Comments in-line:
<=
div class=3D"gmail_extra">
On Tue, May 17, 20=
16 at 12:23 PM, Jana Iyengar <jri@google.com> wrote:
Thanks, Mark. R=
esponses inline:
=C2=A0The third focus area will desc=
ribe mappings between specific applications=E2=80=99 semantics and the tran=
sport facilities of QUIC. The first mapping will be a description of HTTP/2=
 semantics using QUIC, specifically with the goal of minimizing web latency=
 using QUIC. Upon completion of that mapping, additional protocols may be a=
dded by updating this charter to include them.





Defining application protocols in the Transport area is a pretty big change=
 around here, even if it is just mapping existing semantics to a new transp=
ort.



As everyone knows, such mappings are "leaky" -- changes under the=
 hood can and will affect how people use the application. We had numerous e=
xamples of this in H2, and while QUIC appears to be a more straightforward =
change in this respect, it's still easy enough to have unintended side =
effects. HTTP is especially fragile in this regard, because of its complexi=
ty, history and breadth of use.



Note that I'm not saying I'm firmly against this approach, just con=
cerned; this WG is obviously going to be very deep in transport discussions=
, and it would be easy to lose the application perspective in it.



I thin=
k you're right that this is a serious concern, but my thinking is that =
we have this concern either way.=C2=A0 You could avoid that by serializing =
the transport work to finish before any mapping started,=20
but that would be slow.=C2=A0 It would also risk the transport developing=
=20
without the driving use case focus that has helped the pre-standards=20
work progress.=C2=A0 

If we try to do the mapping work in a differen=
t/area working group while the transport work is still ongoing, we need a v=
ery tight coordination between the two groups throughout the work.=C2=A0 Ba=
sically, everyone interested will have to be in both; given that it will no=
t be the only topic in either group, that's going to be distracting as =
well as logistically difficult.=C2=A0 

If you're not willing to serialize,=C2=A0 in other words, I think y=
ou have to pick one to have the work.=C2=A0 Given that QUIC will eventually=
 have more than one mapping, I think it makes sense to do it in a working g=
roup focused on QUIC.=C2=A0 There is no question that a QUIC working group =
with this charter would need the eyes of an HTTP-focused set of contributor=
s for this mapping.=C2=A0 To some extent, that means we're asking the i=
ndulgence of the HTTP-focused community for splitting their attention for a=
 time; ultimately, though, I think they would have had to do that anyway.=C2=A0

Also, if this WG *is* to do the HTTP/2 mapping, more text about what semant=
ics are being mapped would avoid a lot of argument down the road; if you sa=
y it's "all of them", that includes running HTTP without TLS.=


=C2=A0
I think the intent is to cover HTTP/2 semantics for an encrypted tra=
nsport, but further assistance in conveying that would be gratefully receiv=
ed.


> Milestones



It would be helpful to also propose the timing of the milestones, perhaps i=
n the form of "date of chartering + n months."


That's a great idea; I didn't want to put in =
dates when I didn't have a start date in hand, but we'll try to put=
 a strawman together with that approach.
=C2=A0
regards,=


Ted


--94eb2c08fa66b27381053311114e--


From nobody Tue May 17 15:20:35 2016
Return-Path: 
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 E842F12DA82 for ; Tue, 17 May 2016 15:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 4cRMabC51MVo for ; Tue, 17 May 2016 15:20:31 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 244F212B046 for ; Tue, 17 May 2016 15:10:45 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id x194so30323963ywd.0 for ; Tue, 17 May 2016 15:10:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9qgC8ksTZdpm/ujc+rx6wuaYdwOD/Yr3EWK/hRzjdlw=; b=MD8KFFwA5qgMdd/deEQSjQnvtH3Q/OPB2x71S1p68wNPo+kjJRY9SCt+BZK8VUZrkH A8hXTd+mFx5m7+HPSfJ72flNEqrfbPqjjf/B1qatHh8hrCLVcUtmAbScS/ahCXNsmQnC wG/9eUBg3M3XLbhW3BLovfe2SrjnTHdNGoyJ/gt5Q4jKTWZp4A0Fy0p74gQ9uq3mdB5J vsT1hmPDmtLX1KkYQwZC/Y4T26Ug2eIzMi6Lt6anWqIwcA7Z3AZamembh3C1WmLN3E2w XTMwGSwq2clz3hsMwGkZonhSHPWSevBjAtKFpltFOuIHlLViqHTPmVstGPLKsz22akon zkXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9qgC8ksTZdpm/ujc+rx6wuaYdwOD/Yr3EWK/hRzjdlw=; b=EVji432mNhFZ4EIKRKIN9Cwxm038QZy/0Vcijc4yA/qefFPu5quw1WbAGwi2oimPBO 00rMuzYWOPVKct4Np9zmITotBtlsFXAEfX1+StdwzJk27J0+85oOoW6q0pj0rxhOhZ8H vpCuiSnjjKS3hN/eil0PVHBLlCJJePNhtIelkRsXWXOAUPlcb+6oYcEzlwKE+0+aV8ns BC9avW5mEHoTVpD8Xz/kSugx2s0IBIZdkY35byaASwuCzW/mhDp/R38ORtJWz8UGagJ3 upnb7r76l3n9JL84WByPZf9/AesQL5CXZJb3d2+zCVTXPr24MWIMZh5GW/c28Q/F+1Dr I9EQ==
X-Gm-Message-State: AOPr4FUb62Vr/XYTr6D4jiLfbPGyCYfATURCJJStITIZwLT24HOMAXv3zNPd4Q8zmxRHPT9Zj/e6H4BLGupkdQCQ
X-Received: by 10.129.121.81 with SMTP id u78mr2022947ywc.239.1463523044142; Tue, 17 May 2016 15:10:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Tue, 17 May 2016 15:10:42 -0700 (PDT)
In-Reply-To: 
References:    <655C07320163294895BBADA28372AF5D488543AB@FR712WXCHMBA15.zeu.alcatel-lucent.com>  
From: Jana Iyengar 
Date: Tue, 17 May 2016 15:10:42 -0700
Message-ID: 
To: Olivier Bonaventure 
Content-Type: multipart/alternative; boundary=94eb2c0a7b682b26b2053311039b
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "Scharf, Michael \(Nokia - DE\)" , Martin Thomson , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 22:20:33 -0000

--94eb2c0a7b682b26b2053311039b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Olivier,

On Tue, May 17, 2016 at 1:02 PM, Olivier Bonaventure <
olivier.bonaventure@tessares.net> wrote:

> Jana,
>
>>
>>      In general, I think the charter has to be a bit more explicit
>>     about congestion control and =E2=80=9CTCP-friendliness=E2=80=9D. Exp=
erimenting with
>>     CC should be simpler in a user-space protocol implementation. This
>>     is both a research opportunity, but also an operational risk. Re-use
>>     of TCP algorithms, as far as applicable, could reduce the latter.
>>
>>
>> I think this probably belongs in the protocol spec where we define a
>> basic default CC for QUIC (which I expect will be a mapping of major
>> parts RFC 5681 to QUIC.) I don't think this belongs in the charter,
>> since the plan is to not have new CC be defined in this wg.
>>
>
> I think that it is useful to mention in the charter that the WG will not
> design a new Congestion Control scheme but simply adapt the existing TCP
> and Multipath TCP congestion control schemes to QUIC.


Agreed. I was specifically speaking to not saying anything about
"TCP-friendliness" since this wg will not be defining new CC algorithms.

- jana


>
> Olivier
>
>
> --
>
> ------------------------------
> DISCLAIMER.
> This email and any files transmitted with it are confidential and intende=
d
> solely for the use of the individual or entity to whom they are addressed=
.
> If you have received this email in error please notify the system manager=
.
> This message contains confidential information and is intended only for t=
he
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. If you are not the intended recipien=
t
> you are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this information is strictly
> prohibited.
>

--94eb2c0a7b682b26b2053311039b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Olivier,

On Tue, May 17, 2016 at 1:02 PM, Olivier Bonaventure <olivier.bonaventure@tessares.net> wrote:
Jana,





=C2=A0 =C2=A0 <ms> In general, I think the charter has to be a bit mo=
re explicit

=C2=A0 =C2=A0 about congestion control and =E2=80=9CTCP-friendliness=E2=80=
=9D. Experimenting with

=C2=A0 =C2=A0 CC should be simpler in a user-space protocol implementation.=
 This

=C2=A0 =C2=A0 is both a research opportunity, but also an operational risk.=
 Re-use

=C2=A0 =C2=A0 of TCP algorithms, as far as applicable, could reduce the lat=
ter.





I think this probably belongs in the protocol spec where we define a

basic default CC for QUIC (which I expect will be a mapping of major

parts RFC 5681 to QUIC.) I don't think this belongs in the charter,

since the plan is to not have new CC be defined in this wg.





I think that it is useful to mention in the charter that the WG will not de=
sign a new Congestion Control scheme but simply adapt the existing TCP and =
Multipath TCP congestion control schemes to QUIC.

Agreed. I was specifically speaking to not saying anything about &qu=
ot;TCP-friendliness" since this wg will not be defining new CC algorit=
hms.

- jana
=C2=A0


Olivier





-- 



------------------------------

DISCLAIMER.

This email and any files transmitted with it are confidential and intended =
solely for the use of the individual or entity to whom they are addressed. =
If you have received this email in error please notify the system manager. =
This message contains confidential information and is intended only for the=
 individual named. If you are not the named addressee you should not dissem=
inate, distribute or copy this e-mail. Please notify the sender immediately=
 by e-mail if you have received this e-mail by mistake and delete this e-ma=
il from your system. If you are not the intended recipient you are notified=
 that disclosing, copying, distributing or taking any action in reliance on=
 the contents of this information is strictly prohibited.





--94eb2c0a7b682b26b2053311039b--


From nobody Tue May 17 16:41:07 2016
Return-Path: 
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 4496312D10F for ; Tue, 17 May 2016 16:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 moAuPeZ99p4f for ; Tue, 17 May 2016 16:41:04 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F8512D0DF for ; Tue, 17 May 2016 16:41:04 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 81E8D22E259; Tue, 17 May 2016 19:40:53 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 18 May 2016 09:40:51 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <8381AA04-961F-4026-9806-A8891F636527@mnot.net>
References:    <655C07320163294895BBADA28372AF5D488543AB@FR712WXCHMBA15.zeu.alcatel-lucent.com>   
To: Jana Iyengar 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Olivier Bonaventure , "Scharf, Michael \(Nokia - DE\)" , Ted Hardie , Christian Huitema , "quic@ietf.org" , Martin Thomson 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 23:41:06 -0000

> On 18 May 2016, at 8:10 AM, Jana Iyengar  wrote:
>=20
> Agreed. I was specifically speaking to not saying anything about =
"TCP-friendliness" since this wg will not be defining new CC algorithms.

Along those lines, it's often good to have an explicit "Out of Scope" =
section in the charter, listing the various potential ratholes / =
diversions that the WG shouldn't go down.

Cheers,

--
Mark Nottingham   https://www.mnot.net/


From nobody Tue May 17 16:42:51 2016
Return-Path: 
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 B998312D105 for ; Tue, 17 May 2016 16:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xTL9Q3H38XpL for ; Tue, 17 May 2016 16:42:47 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 1028A12D10F for ; Tue, 17 May 2016 16:42:47 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id x194so32097943ywd.0 for ; Tue, 17 May 2016 16:42:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FV7lLrt3daeWqZpzvuh9tShJxJhObTBERgKiWLtOBzo=; b=LfJ6EmE/rOOAZheLq8tS3M2fwXESCW65Y0mN7yHdEyGD/aX3yazUfrF93IbrWVIfgB MuSPMjcZ0cKs3eZ7H7vfIAeuuqMuFv+k+U0JR13JCZCTXEFM7hFmMDcWMGs5nka2BgBT po/jtNEgFGZppsxh6TfLaEHDHS0hCspikaNx321TV/7AXQ0UQHrjMGJY5FQYy6uHTKkV s2IS1sCMpiKW55kgmCj6vMjJeKsH4U4mz5EbpD9d9r7/aGO9lzeBVK5/1gnplI5SWxXq /R6oHQTAqOY0rOBSPOf/MrrgKsGFnCXGMA74PReU8WBZ2/Bg4AWQfnlcP/d4jnZFvAm/ +CPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FV7lLrt3daeWqZpzvuh9tShJxJhObTBERgKiWLtOBzo=; b=fHGasoXJyD7dcRcLqWSjEf/aFGw3OCUKtpsFxtD5JwMwfw6dEyH8c437NR2Sv9sTZl 6tzZa58md+RYRO931kxesvQ7kx8jODPlO253g+t09YbEMQyyCHoM0ur4vkxuFm0nrOm2 m6jdFmZQXScu4Pg+YoWvPV8rGiNM/OO49KtJSPu7xYRDzfk0JNUFfYir/iQO8K1VFcoQ XHgV0RvoJLqxoqvwFTGFeI/YNTip4sQlsz+2pR+fgNQIw1aSAk/hdRWtUNTdIhkRxCX5 A9RxHxK32Q2MF48sCWm4aRYwoDus1Ju2KjhM9NalxMcid+cdhIierF2yLFoT18ctqPnD nW+A==
X-Gm-Message-State: AOPr4FUchINacmYXHWMTG074E6w1JAgWeYnUM+Rx1JY2Vsx01lw0W/jh9LD5dtOrDYL2V1TNtjKT2qZRqCUe6eAa
X-Received: by 10.13.237.1 with SMTP id w1mr2307313ywe.62.1463528566187; Tue, 17 May 2016 16:42:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Tue, 17 May 2016 16:42:44 -0700 (PDT)
In-Reply-To: <8381AA04-961F-4026-9806-A8891F636527@mnot.net>
References:    <655C07320163294895BBADA28372AF5D488543AB@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <8381AA04-961F-4026-9806-A8891F636527@mnot.net>
From: Jana Iyengar 
Date: Tue, 17 May 2016 16:42:44 -0700
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=94eb2c0864a84ed8710533124cc9
Archived-At: 
Cc: Olivier Bonaventure , "Scharf, Michael \(Nokia - DE\)" , Ted Hardie , Christian Huitema , "quic@ietf.org" , Martin Thomson 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 May 2016 23:42:49 -0000

--94eb2c0864a84ed8710533124cc9
Content-Type: text/plain; charset=UTF-8

On Tue, May 17, 2016 at 4:40 PM, Mark Nottingham  wrote:

>
> > On 18 May 2016, at 8:10 AM, Jana Iyengar  wrote:
> >
> > Agreed. I was specifically speaking to not saying anything about
> "TCP-friendliness" since this wg will not be defining new CC algorithms.
>
> Along those lines, it's often good to have an explicit "Out of Scope"
> section in the charter, listing the various potential ratholes / diversions
> that the WG shouldn't go down.


Great suggestion. I'll give it a shot.

- jana


Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>

--94eb2c0864a84ed8710533124cc9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, May 17, 2016 at 4:40 PM, Mark Nottingham <mnot@mnot.net> wr=
ote:


> On 18 May 2016, at 8:10 AM, Jana Iyengar <jri@google.com> wrote:

>

> Agreed. I was specifically speaking to not saying anything about "=
;TCP-friendliness" since this wg will not be defining new CC algorithm=
s.



Along those lines, it's often good to have an explicit "Out=
 of Scope" section in the charter, listing the various potential ratho=
les / diversions that the WG shouldn't go down.

Great suggestion. I'll give it a shot.

- jana


=


Cheers,



--

Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/







--94eb2c0864a84ed8710533124cc9--


From nobody Tue May 17 17:04:32 2016
Return-Path: 
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 EF3D312DAD8 for ; Tue, 17 May 2016 17:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=microsoft.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 n3AfVBAgrNsN for ; Tue, 17 May 2016 17:04:24 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFCA12D544 for ; Tue, 17 May 2016 17:04:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EPCmauqovGXfLX5HetMzQGPwZWF1ETT4f3W2N3kIhc0=; b=PO1NA3OV4l4YqGmwB6uQ7EYGj1wxtDW9xK2RsKPdm15wCechFT8SU/RebTd8dkdqU1FIS9ryg4MEAPXyp1uNgbq0vtPlhvQVWSIiWQ0CL78QFMstswCv7QXFLTnGXnedz3QCa3yGfAyEa/aO/XwWC4j+t8c6RaW6qizJXYrY1uY=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 18 May 2016 00:04:05 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0492.020; Wed, 18 May 2016 00:04:04 +0000
From: Christian Huitema 
To: Jana Iyengar 
Thread-Topic: [QUIC] Draft charter
Thread-Index: AQHRrW/Sb0NYcU1DiUO0Xn0RTsSsY5+8fjcAgAAzxDCAANiJgIAAS0pA
Date: Wed, 18 May 2016 00:04:04 +0000
Message-ID: 
References:  <1977F512-A341-400B-B7F9-E64C8E2E6786@mnot.net>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [72.235.151.78]
x-ms-office365-filtering-correlation-id: 5ef49ff1-176a-4f58-4df4-08d37eafecff
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:BgZ18Pf2HBOFLjG8O/CpzNESvYxgpyf54iOKkByKPUvBzcy32jPG7kkGuE1HoiFtah3xa3etvOAddROA30I5s9P7xMiJ5yzhAgO1mjUarQdy7z1+r0wJcvmVPjxk/3LbvmLqRjtE1T+Cr18hphlMKA==; 24:MKcS6D7qDAnxVIDIBbVajfEXBtoei3ZCGVYISVl6jDGZ4089P26WHjLGsP+S1GRTeMUnDYsDmKjiKhCPihYxTyOhyGytglTUOgRxOBbPH8w=; 7:SRI7ED+c+IEvwuDnABTlPryje1ray1nc07g2W/irnx/uTjvupTBgNcNHwwWAR/Pq0Ruid5S2F5xQ++CRf2849f4ABCuGDoPLkQc+Ls+pf4ycxzCLpVFcY4qacLmIQeDN+rCPThiGPqBEtMtmF3sj6KnxFizSNL9VRUGFOX35u36FfJnx5FE5Cj3LoXWk+FHfkRe5e54cY0vlx0SYG/dg1g==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; 
x-forefront-prvs: 0946DC87A1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(1220700001)(2900100001)(2950100001)(77096005)(2906002)(4326007)(10400500002)(8936002)(5008740100001)(10290500002)(5005710100001)(3846002)(5003600100002)(76576001)(66066001)(110136002)(81166006)(586003)(8676002)(5002640100001)(9686002)(189998001)(6116002)(106116001)(19580405001)(19580395003)(93886004)(86362001)(87936001)(102836003)(54356999)(76176999)(50986999)(5004730100002)(10090500001)(122556002)(33656002)(92566002)(99286002)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2016 00:04:04.8340 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653
Archived-At: 
Cc: Mark Nottingham , "quic@ietf.org" , Ted Hardie 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 00:04:27 -0000

T24gVHVlc2RheSwgTWF5IDE3LCAyMDE2IDk6MzEgQU0sIEphbmEgSXllbmdhciB3cm90ZToNCj4g
T24gTW9uLCBNYXkgMTYsIDIwMTYgYXQgMTE6MzkgUE0sIENocmlzdGlhbiBIdWl0ZW1hIDxtYWls
dG86aHVpdGVtYUBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4+IE9uIE1vbmRheSwgTWF5IDE2LCAy
MDE2IDU6MzEgUE0sIE1hcmsgTm90dGluZ2hhbSB3cm90ZToNCj4+PiAuLi4NCj4+PiBXaGF0IGlz
ICJuZWdvdGlhdGlvbiIgaW4gdGhpcyBjb250ZXh0PyBJcyBpdCBqdXN0IFFVSUMgdmVyc2lvbmlu
Zywgb3IgaXMgaXQgYWxzbyBhDQo+Pj4gZnVuY3Rpb25hbCBlcXVpdmFsZW50IHRvIEFMUE4gKGku
ZS4sIG5lZ290aWF0aW9uIG9mIHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbA0KPj4+IGNhcnJpZWQp
LCBvciBpcyBpdCBtb3JlIGxpa2UgSFRUUC8yIFNFVFRJTkdTICh3aGljaCBpcyBub3QgcmVhbGx5
IGEgbmVnb3RpYXRpb24NCj4+PiBtZWNoYW5pc20sIGl0J3MgbW9yZSBsaWtlIGEgY29uZmlndXJh
dGlvbiBhZHZlcnRpc2VtZW50KT8NCj4+DQo+PiBUaGVyZSBpcyB2ZXJzaW9uaW5nLCBidXQgdGhh
dCdzIGEgYmx1bnQgaW5zdHJ1bWVudC4gTXkgcGVyc29uYWwgbW9kZWwgaXMgbW9yZSANCj4+IGFi
b3V0IFRDUCBPcHRpb24sIHdoaWNoIG92ZXIgdGltZSBhbGxvd2VkIHRoZSBpbnRyb2R1Y3Rpb24g
b2YgdGltZSBzdGFtcHMsIA0KPj4gc2VsZWN0aXZlIGFja25vd2xlZGdlbWVudHMsIG9yIG11bHRp
cGF0aCBwYXJhbWV0ZXJzLCBBbiBlcXVpdmFsZW50IGZvciBRVUlDIA0KPj4gd291bGQgYmUgZXhw
ZXJpbWVudGF0aW9uIHdpdGggb3B0aW9ucyBmb3IgZm9yd2FyZCBlcnJvciBjb3JyZWN0aW9uIG9y
IG11bHRpcGF0aC4NCj4NCj4gVGhlc2UgYXJlIHR3byBkaWZmZXJlbnQgdGhpbmdzIGluIG15IG1l
bnRhbCBtb2RlbCwgYW5kIHRoZXkncmUgYm90aCB1c2VmdWwuIFRoZSB2ZXJzaW9uDQo+IHRlbGxz
IHlvdSBob3cgdG8gaW50ZXJwcmV0IHRoZSBiYXNpYyB3aXJlIGZvcm1hdCwgYW5kIGltcG9ydGFu
dGx5IGFsbG93cyB5b3UgdG8gY2hhbmdlDQo+IHRoZSB3aXJlIGZvcm1hdDsgb3B0aW9ucyBpcyBm
b3IgZmVhdHVyZSBuZWdvdGlhdGlvbi4gSSB0aGluayBpdCdzIGltcG9ydGFudCBmb3IgdXMgdG8g
aGF2ZSBhbiANCj4gb3B0aW9ucyBuZWdvdGlhdGlvbiBtZWNoYW5pc20gYXMgd2VsbC4gRG8geW91
IHRoaW5rIHRoaXMgaXMgd29ydGggY2FsbGluZyBvdXQgZXhwbGljaXRseQ0KPiAoInZlcnNpb24g
bmVnb3RpYXRpb24sIGFuZCBmZWF0dXJlIG5lZ290aWF0aW9uIik/DQoNCkl0IHByb2JhYmx5IHdv
dWxkIG5vdCBodXJ0LCBpZiB0aGF0IGlzIG5vdCB0b28gdW53aWVsZHkuIA0KDQotLSBDaHJpc3Rp
YW4gSHVpdGVtYQ0KDQoNCg==


From nobody Tue May 17 17:06:44 2016
Return-Path: 
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 3E9A912D544 for ; Tue, 17 May 2016 17:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 aI3osYbUM6_I for ; Tue, 17 May 2016 17:06:42 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 0809E12D094 for ; Tue, 17 May 2016 17:06:42 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id g133so32547355ywb.2 for ; Tue, 17 May 2016 17:06:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p+n9Qz9bybkK3EUbWJCuPf5BnrXKoHmHVyFTxWqoHus=; b=NUTkitr7Uh4VTCsUBThg9vBkGRdHb3Hlca0SkrbuqFhmS7z0f99so69J/cgJ4o1WE6 EVrnqvQWTogGjmZvUnfCqdjbvg4z2gLBmu2yAroZ82VaUrpMlvmPFLQJ5vNYNHEgvMi6 1FBzy/GJJVBI10OKffEsTSW/XZDZn5L2w3r2ounHqI941ScPMQzDOLtYnudUjJLXkTco VGOlFEKjQd/FjRFITM6jZDq1Di9Rwr5rBdXTufr94ZGK3adsm0JyK1S9a0GOV9slWTmf Vj+UsOQZeAmZ75E/bqxxAeGEikBUG4L91C7b2G9TG41Zo6ixNcnBC2l2J+NnIRDULjPy 5rGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p+n9Qz9bybkK3EUbWJCuPf5BnrXKoHmHVyFTxWqoHus=; b=LITyB5+g4zTW8G2hQ4XN3P126znxhrPPthxk3MoYmWbMRa3n+4pMg1XeLdH09jg/JL kNnDXm1lV0MKVIJAgXPdKD2Bfzn80vP9QexUCF3J6+AmuGH0jq5qzqFc93x/NT8e90Bp Ho1zsDDduMXw7nzOKAwVzMvUeGcwd/bD/62wYJlbq0NkZzZW54ey6GGMrxww1ROGD0et o4vavjucfT2GDvn/IDll43sEgCCXYG0omzHU+0c3mDB3Nrx38g60lVofrIzRujyFmDCN 6tsMbGjsXwx5k8TbMjWvrJty8SXe2x7C7P0ar56/IMPZoD3VjOb+1T5+DxLj45W9G/G5 BexA==
X-Gm-Message-State: AOPr4FWIUnv3hkO9BWJ9FJ3QWrgUElX8XC2Y3dQVeqRa/Dy3IrGZWud95aNM+c3qLn1EZ+kOCYo0bhI7ekDnFTeQ
X-Received: by 10.13.218.65 with SMTP id c62mr2403605ywe.36.1463530001203; Tue, 17 May 2016 17:06:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Tue, 17 May 2016 17:06:39 -0700 (PDT)
In-Reply-To: 
References:  <1977F512-A341-400B-B7F9-E64C8E2E6786@mnot.net>   
From: Jana Iyengar 
Date: Tue, 17 May 2016 17:06:39 -0700
Message-ID: 
To: Christian Huitema 
Content-Type: multipart/alternative; boundary=94eb2c080508d77f89053312a105
Archived-At: 
Cc: Mark Nottingham , "quic@ietf.org" , Ted Hardie 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 00:06:43 -0000

--94eb2c080508d77f89053312a105
Content-Type: text/plain; charset=UTF-8

On Tue, May 17, 2016 at 5:04 PM, Christian Huitema 
wrote:

> On Tuesday, May 17, 2016 9:31 AM, Jana Iyengar wrote:
> > On Mon, May 16, 2016 at 11:39 PM, Christian Huitema  huitema@microsoft.com> wrote:
> >> On Monday, May 16, 2016 5:31 PM, Mark Nottingham wrote:
> >>> ...
> >>> What is "negotiation" in this context? Is it just QUIC versioning, or
> is it also a
> >>> functional equivalent to ALPN (i.e., negotiation of the application
> protocol
> >>> carried), or is it more like HTTP/2 SETTINGS (which is not really a
> negotiation
> >>> mechanism, it's more like a configuration advertisement)?
> >>
> >> There is versioning, but that's a blunt instrument. My personal model
> is more
> >> about TCP Option, which over time allowed the introduction of time
> stamps,
> >> selective acknowledgements, or multipath parameters, An equivalent for
> QUIC
> >> would be experimentation with options for forward error correction or
> multipath.
> >
> > These are two different things in my mental model, and they're both
> useful. The version
> > tells you how to interpret the basic wire format, and importantly allows
> you to change
> > the wire format; options is for feature negotiation. I think it's
> important for us to have an
> > options negotiation mechanism as well. Do you think this is worth
> calling out explicitly
> > ("version negotiation, and feature negotiation")?
>
> It probably would not hurt, if that is not too unwieldy.


Ack.


> -- Christian Huitema
>
>
>

--94eb2c080508d77f89053312a105
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, May 17, 2016 at 5:04 PM, Christian Huitema <huitema@microsoft.com<=
/a>> wrote:
On Tuesday, May 17,=
 2016 9:31 AM, Jana Iyengar wrote:

> On Mon, May 16, 2016 at 11:39 PM, Christian Huitema &=
lt;mailto:huitema@microsoft.com> wrote:

>> On Monday, May 16, 2016 5:31 PM, Mark Nottingham wrote:

>>> ...

>>> What is "negotiation" in this context? Is it just QU=
IC versioning, or is it also a

>>> functional equivalent to ALPN (i.e., negotiation of the applic=
ation protocol

>>> carried), or is it more like HTTP/2 SETTINGS (which is not rea=
lly a negotiation

>>> mechanism, it's more like a configuration advertisement)?<=
br>
>>

>> There is versioning, but that's a blunt instrument. My persona=
l model is more

>> about TCP Option, which over time allowed the introduction of time=
 stamps,

>> selective acknowledgements, or multipath parameters, An equivalent=
 for QUIC

>> would be experimentation with options for forward error correction=
 or multipath.

>

> These are two different things in my mental model, and they're bot=
h useful. The version

> tells you how to interpret the basic wire format, and importantly allo=
ws you to change

> the wire format; options is for feature negotiation. I think it's =
important for us to have an

> options negotiation mechanism as well. Do you think this is worth call=
ing out explicitly

> ("version negotiation, and feature negotiation")?



It probably would not hurt, if that is not too unwieldy.

Ack.



-- Christian Huitema









--94eb2c080508d77f89053312a105--


From nobody Tue May 17 17:37:17 2016
Return-Path: 
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 C889A12D543 for ; Tue, 17 May 2016 17:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 XNhBCILRQwBe for ; Tue, 17 May 2016 17:37:14 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 D6B7812D5EE for ; Tue, 17 May 2016 17:37:13 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id x194so33060155ywd.0 for ; Tue, 17 May 2016 17:37:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=ePz5a9x9lfeKSVc6jagDAsYlnCcxt3vmy85ibnV7nus=; b=GT1hXNDJq1vXK21Secd178j4onz2zvDTmPk1+jEK+ImTU0MrgQCuzb7Xvdr15EfKyS I9BbUtUVkwHWcMHm5VFoHAdceh8RzDIAaI362paSumGJRiG3DP85mh923lbHFufQMZe7 38CSQ/NrSnOtyJqAWWlKZKnbGwZxK8j7zRjI+eA26MoqCIN1SrwlNFFvkU1ttfWGTNf0 GaL0WqfLQmT1PsS4abovFziyElThbj7NLnnhofQ7hRP0CQtwwq5gf8HjrKbX2/td5nt1 TbvzNOxcOiXmmheGaIA65f1C4YeKOKEz2V7oFU4Nh91afyt90dkj43GNgWlOh6a7AHFZ XBMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ePz5a9x9lfeKSVc6jagDAsYlnCcxt3vmy85ibnV7nus=; b=V4PHchDYlvzstDxwCtRyidYe6ZY2iyTn0gLh6gVxz5CAnTMXAm1mZALcrg/DQxfkii xK8mR/2IopWCI/no0m5gWP0YAhtvNK6IEQs6ahFTnRCCt/JDG3xRmUqvDNenKcHHaLvB EEieH7eCcXTuliS5BCdEreXeHLQ1/3wv4nP+DrvUjEl3BGHQa53fMocua/7APmw1gcL2 GoCM2yuXXQfv0ujjD/iFtG3guLTbi7A9qNVAYtofRkvsGV2gbpwUTK1ZNpQ5h4i/pSG2 MV2pfLAgp+LyiJ/3gh3smeMziEbD9l/gzSf1ZKMUt4xWKlzGFikOTTPdNLIEmaOJ8N1Z FyPg==
X-Gm-Message-State: AOPr4FWIbD+0RIaxMdvDAnSr7Kr5QULS1eWRfSAIRrOgOFsmGb+CvmnBf5ldlha1f8G44t3Aq3vwBmV0CCLYD1ge
X-Received: by 10.13.218.65 with SMTP id c62mr2466852ywe.36.1463531833060; Tue, 17 May 2016 17:37:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Tue, 17 May 2016 17:37:12 -0700 (PDT)
From: Jana Iyengar 
Date: Tue, 17 May 2016 17:37:12 -0700
Message-ID: 
To: quic@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c0805080789b20533130fd3
Archived-At: 
Subject: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 00:37:16 -0000

--94eb2c0805080789b20533130fd3
Content-Type: text/plain; charset=UTF-8

Greetings,

I am modifying the charter text that currently says "loss detection and
recovery, congestion control, and negotiation" to say "loss detection and
recovery, congestion control, version negotiation, and option negotiation",
and I wanted to clarify the roles of version negotiation and option
negotiation in the current version of QUIC, since it may be a source of a
bit of confusion.

Version negotiation is used for determining how to read and parse a QUIC
packet. Any "on-the-wire" change to the core protocol or generally any
change that impacts interoperability results in a version change. Version
negotiation, as described in Section 7.1 of draft-tsvwg-quic-protocol-02
,
allows the two ends to agree on the version to use for communication. This
is, as Christian puts it, a "blunt" instrument, and it should be treated as
such. Versioning is not generally intended to be used for negotiating the
equivalent of TCP options. The expectation is that versioning will also
allow continued experimentation with QUIC.

I believe that no current IETF transport has versioning.

In addition to versioning, QUIC currently exchanges transport parameters --
the equivalent of TCP options -- during the handshake. This is described,
though not in much detail, in Section 9 of draft-quic-protocol-02
.
Examples of things that may be negotiated via these parameters include max
open streams, among other things. This mechanism may be used for
negotiating features as well, such as use of multipath.

The initial drafts will contain both of these mechanisms.

- jana

--94eb2c0805080789b20533130fd3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Greetings,

I am modifying the charter t=
ext that currently says "loss detection and recovery, congestion contr=
ol, and negotiation" to say "loss detection and recovery, congest=
ion control, version negotiation, and option negotiation", and I wante=
d to clarify the roles of version negotiation and option negotiation in the=
 current version of QUIC, since it may be a source of a bit of confusion.

Version negotiation is used for determining how to =
read and parse a QUIC packet. Any "on-the-wire" change to the cor=
e protocol or generally any change that impacts interoperability results in=
 a version change. Version negotiation, as described in Section 7.1 o=
f draft-tsvwg-quic-protocol-02, allows the two ends to agree on the ver=
sion to use for communication. This is, as Christian puts it, a "blunt=
" instrument, and it should be treated as such. Versioning is not gene=
rally intended to be used for negotiating the equivalent of TCP options. Th=
e expectation is that versioning will also allow continued experimentation =
with QUIC.

I believe that no current IETF transpor=
t has versioning.

In addition to versioning, QUIC =
currently exchanges transport parameters -- the equivalent of TCP options -=
- during the handshake. This is described, though not in much detail, in Section 9 of draft-quic-protocol-02. Examples of things that may be n=
egotiated via these parameters include max open streams, among other things=
. This mechanism may be used for negotiating features as well, such as use =
of multipath.

The initial drafts will contain both=
 of these mechanisms.

- jana


--94eb2c0805080789b20533130fd3--


From nobody Tue May 17 20:21:32 2016
Return-Path: 
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 B48FC12D1CE for ; Tue, 17 May 2016 20:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 1sp5JEheGZxo for ; Tue, 17 May 2016 20:21:29 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 B747F12D1D0 for ; Tue, 17 May 2016 20:21:28 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id a17so58707085wme.0 for ; Tue, 17 May 2016 20:21:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nehiHrd62qQ9MwmZe88PHma4Z2P2sb8CLHPm8y1ZvXQ=; b=ftqeej+N8S28OmGhj+/W0u1PKSdY+3ChPyIAjUcEqFttm3cG2DU97BdL9JLMqAbLHq v84NxDwYGqWXJ8/V/aqt7bND0P/O/hr88kIxFMs00mPCgOzFu2xlTl5cUaVY4VyfRru0 fNFry7Pujl+SCttUPXVP3OJaIiGk0e4Y+q7asGeQZm/vtb3umYpIDTD1e37Xj3LbIFsA dqHGYSQTNRkMPd8ZZ0IEr3E/PMqg2TGXpMOI9N6dIB5NkmM2vZNMhtSuZen5DGtp1kkM UVjSQILlZbFmQdxbyuuWbWzWDT7pWkHwieks3bhne6kBp9j0LyntLcntjOR2OsjBKBTi dgPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nehiHrd62qQ9MwmZe88PHma4Z2P2sb8CLHPm8y1ZvXQ=; b=Ah1qCVpDwbj5OPCk1CqWGyQUeTSN7JTu78I+arzoW0yzLEV7XTIQb2FAhqXoE/6NZl HySLNYaakMr1xLE3WFey5zh4s7tC9yoMNXwasGYhPXZSZEM6uCUluJ9xonG5w/t7Fh6l ItTuqjjUNC7W4FfStTwUySi9WSt9VRE188j3MUB12eP0Ek6iUlKz6haS44grow8v6Nus ycD+9DqcCvdtjow/oEXMj/NOTjDhgBF4ezCMyoRtbh9aHJSCjC9H6qqTWQQW9SONoBFd vf466D55XrSgVsKVlPpVLUbZ4ZIuKmXaN8vzYv1YReVx9a8Kijon7iEIGewNDxxU8pgV X8Sw==
X-Gm-Message-State: AOPr4FX6RJXzPopooqdzH6uuFigH34Hp1LtG6cTOJn/AJXKcMgexlq7R14UNuLVPrJfCXxSFWdXjpkRqVLwhUi/b
X-Received: by 10.28.168.76 with SMTP id r73mr25792131wme.44.1463541687026; Tue, 17 May 2016 20:21:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.46.151 with HTTP; Tue, 17 May 2016 20:21:26 -0700 (PDT)
In-Reply-To: 
References: 
From: Ryan Hamilton 
Date: Tue, 17 May 2016 20:21:26 -0700
Message-ID: 
To: "Bajpai, Vaibhav" 
Content-Type: multipart/alternative; boundary=001a114ccd565edee30533155abd
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] graceful fallback to tcp
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 03:21:31 -0000

--001a114ccd565edee30533155abd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, May 16, 2016 at 2:32 AM, Bajpai, Vaibhav <
v.bajpai@jacobs-university.de> wrote:

> Hello,
>
> I have question on draft-tsvwg-quic-protocol-02 [a]
>
> >     When a client receives a Alternate-Protocol header advertising QUIC=
,
> it can
> >     then attempt to use QUIC for future secure connections on that
> domain.  Since
> >     middleboxes and/or firewalls can block QUIC and/or UDP
> communication, a client
> >     should implement a graceful fallback to TCP when QUIC reachability
> is broken.
>
> This ^ hints towards a scheme similar to HE [RFC 6555] for racing TCP and
> UDP
> connections. What timer value is used for a graceful fallback in QUIC
> implementations (such as Google Chrome) today?
>
> [a] https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02


=E2=80=8BWe don't have a timeout specifically for falling back to TCP, per =
se. The
logic for handling fallback in the face of broken QUIC reachability is
roughly as follows:=E2=80=8B
* If a server is known to speak QUIC, Chrome will race a TCP connection
with a QUIC connection. Whichever connection finishes first will be used
for the request.
* If a QUIC connection is unable to be established, QUIC is marked as
broken for that server for a period of 5 minutes (subject to exponential
backoff) and while QUIC is marked as broken, Chrome will not attempt to
speak QUIC to a server.
* If it happens that Chrome attempts a QUIC 0-RTT connection to a server
and that connection happens to fail (perhaps due to the handshake timeout)
QUIC will be marked as broken, and the request will fall back to TCP.

Hope that helps!

--001a114ccd565edee30533155abd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Mon, May 1=
6, 2016 at 2:32 AM, Bajpai, Vaibhav <v.bajpai@jacobs-university.de>=
 wrote:
Hello,



I have question on draft-tsvwg-quic-protocol-02 [a]



>=C2=A0 =C2=A0 =C2=A0When a client receives a Alternate-Protocol header =
advertising QUIC, it can

>=C2=A0 =C2=A0 =C2=A0then attempt to use QUIC for future secure connecti=
ons on that domain.=C2=A0 Since

>=C2=A0 =C2=A0 =C2=A0middleboxes and/or firewalls can block QUIC and/or =
UDP communication, a client

>=C2=A0 =C2=A0 =C2=A0should implement a graceful fallback to TCP when QU=
IC reachability is broken.



This ^ hints towards a scheme similar to HE [RFC 6555] for racing TCP and U=
DP

connections. What timer value is used for a graceful fallback in QUIC

implementations (such as Google Chrome) today?



[a] https://tools.ietf.org/=
html/draft-tsvwg-quic-protocol-02

=E2=80=8BWe don't have a timeout specifically for falling back to =
TCP, per se. The logic for handling fallback in the face of broken QUIC rea=
chability is roughly as follows:=E2=80=8B
* If a server is k=
nown to speak QUIC, Chrome will race a TCP connection with a QUIC connectio=
n. Whichever connection finishes first will be used for the request.
<=
div class=3D"gmail_default" style=3D"font-family:'trebuchet ms',san=
s-serif">* If a QUIC connection is unable to be established, QUIC is marked=
 as broken for that server for a period of 5 minutes (subject to exponentia=
l backoff) and while QUIC is marked as broken, Chrome will not attempt to s=
peak QUIC to a server.
* If it happens that Chrome attempts =
a QUIC 0-RTT connection to a server and that connection happens to fail (pe=
rhaps due to the handshake timeout) QUIC will be marked as broken, and the =
request will fall back to TCP.

Hope that=
 helps!=C2=A0



--001a114ccd565edee30533155abd--


From nobody Wed May 18 09:04:09 2016
Return-Path: 
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 390CA12D18E for ; Wed, 18 May 2016 09:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8UhaYUPn3ka2 for ; Wed, 18 May 2016 09:04:06 -0700 (PDT)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001: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 05B6612D17A for ; Wed, 18 May 2016 09:04:05 -0700 (PDT)
Received: by mail-ig0-x233.google.com with SMTP id m9so29860145ige.1 for ; Wed, 18 May 2016 09:04:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FdZCK7iP9FxfAFcDVAb0TcIRvajxRWEy8r1CKPy5UuA=; b=YgvySUjlHlF1q9Aa2fZg6wZda0vn37mW2nm5Yu2Vg6l5LMrelk9wn7K6gjMRI1GWtx mnV8yulxrNyZkHmvtlvDraKj9mvUqsTQrbNJFWfZ4cTHGYJUHa7cqU2jl0GdqiEx65BB qOfXMKhdkRIrCQmHzY5ly4Si4UNZ/1sjj0F10lFGfqhQfyPz5U4c/fHtPYDdsBo+7o1Q u+tgAeogP6o+vsj3Mjz9UhIRNXIiq+4CJVwiJRaj0qLjn6V9nz3928w/2UplfWq81qLp QtORSQhlWNZyfyIbcaNtceoWv/ydjxd2nwbEwSFZdscHDtfwgjvZUsSL0B+IpVsS3fEK Flkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FdZCK7iP9FxfAFcDVAb0TcIRvajxRWEy8r1CKPy5UuA=; b=BFJcD7gGZ6zt3MrwEVialV5xLYYKAA5H1eNkw88SP2fxpT/F/1QkpssXOaWbXXM0KM Lji+wQlYkttc8YYryQ6aznYlmO/0+tQq03X2PcYWyzeeoQ26y0GNrxiIZ/BvqU91EwxS 8HPNyF0CuPUfaMet9wC4j1pCuLaAKBZfTrKK9XxhfHEczrWRmedqa+xLqYR6cbTh13GQ rSuPcDacHJk3R6DshqAFmFxXm0IHvH9tTuhxZ9SzIsaXdzgHbfnBdt+81ByOefMKnRdC xlbKROAzBN3/K7FlhPf3TgHHNOaWaVTxsFqjztj6EH21vfhtilbOOdD/VoKuRY2CA0Hf I4gQ==
X-Gm-Message-State: AOPr4FUuku3FuNIZFBJ3uPsdJ0LOm22QgxqpUofeqH1PKbMegI4CKl0eHy/e6lKQJkZ8i3NUocrjNzcQV0Lt9d0f
X-Received: by 10.50.41.97 with SMTP id e1mr6142766igl.3.1463587443827; Wed, 18 May 2016 09:04:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.227.227 with HTTP; Wed, 18 May 2016 09:03:44 -0700 (PDT)
In-Reply-To: 
References: 
From: Ian Swett 
Date: Wed, 18 May 2016 12:03:44 -0400
Message-ID: 
To: Jana Iyengar 
Content-Type: multipart/alternative; boundary=089e0116074ab0793905332001d9
Archived-At: 
Cc: quic@ietf.org
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 May 2016 16:04:08 -0000

--089e0116074ab0793905332001d9
Content-Type: text/plain; charset=UTF-8

Thanks Jana, the clarification is appreciated.

On Tue, May 17, 2016 at 8:37 PM, Jana Iyengar  wrote:

> Greetings,
>
> I am modifying the charter text that currently says "loss detection and
> recovery, congestion control, and negotiation" to say "loss detection and
> recovery, congestion control, version negotiation, and option negotiation",
> and I wanted to clarify the roles of version negotiation and option
> negotiation in the current version of QUIC, since it may be a source of a
> bit of confusion.
>
> Version negotiation is used for determining how to read and parse a QUIC
> packet. Any "on-the-wire" change to the core protocol or generally any
> change that impacts interoperability results in a version change. Version
> negotiation, as described in Section 7.1 of draft-tsvwg-quic-protocol-02
> ,
> allows the two ends to agree on the version to use for communication. This
> is, as Christian puts it, a "blunt" instrument, and it should be treated as
> such. Versioning is not generally intended to be used for negotiating the
> equivalent of TCP options. The expectation is that versioning will also
> allow continued experimentation with QUIC.
>
> I believe that no current IETF transport has versioning.
>
> In addition to versioning, QUIC currently exchanges transport parameters
> -- the equivalent of TCP options -- during the handshake. This is
> described, though not in much detail, in Section 9 of
> draft-quic-protocol-02
> .
> Examples of things that may be negotiated via these parameters include max
> open streams, among other things. This mechanism may be used for
> negotiating features as well, such as use of multipath.
>
> The initial drafts will contain both of these mechanisms.
>
> - jana
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>

--089e0116074ab0793905332001d9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks Jana, the clarification is appreciated.

On Tue, May 17, 2016 at=
 8:37 PM, Jana Iyengar <jri@google.com> wrote:
Greetings,

I am modif=
ying the charter text that currently says "loss detection and recovery=
, congestion control, and negotiation" to say "loss detection and=
 recovery, congestion control, version negotiation, and option negotiation&=
quot;, and I wanted to clarify the roles of version negotiation and option =
negotiation in the current version of QUIC, since it may be a source of a b=
it of confusion.

Version negotiation is used for d=
etermining how to read and parse a QUIC packet. Any "on-the-wire"=
 change to the core protocol or generally any change that impacts interoper=
ability results in a version change. Version negotiation, as described in <=
a href=3D"https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02#section-=
7.1" target=3D"_blank">Section 7.1 of draft-tsvwg-quic-protocol-02, all=
ows the two ends to agree on the version to use for communication. This is,=
 as Christian puts it, a "blunt" instrument, and it should be tre=
ated as such. Versioning is not generally intended to be used for negotiati=
ng the equivalent of TCP options. The expectation is that versioning will a=
lso allow continued experimentation with QUIC.

I b=
elieve that no current IETF transport has versioning.

<=
div>In addition to versioning, QUIC currently exchanges transport parameter=
s -- the equivalent of TCP options -- during the handshake. This is describ=
ed, though not in much detail, in Section 9 of draft-=
quic-protocol-02. Examples of things that may be negotiated via these p=
arameters include max open streams, among other things. This mechanism may =
be used for negotiating features as well, such as use of multipath.

The initial drafts will contain both of these mechanisms.=


- =
jana


_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--089e0116074ab0793905332001d9--


From nobody Thu May 19 01:48:36 2016
Return-Path: 
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 7258612D102 for ; Thu, 19 May 2016 01:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 jmHq8gS77kYv for ; Thu, 19 May 2016 01:48:31 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0093812B02B for ; Thu, 19 May 2016 01:48:30 -0700 (PDT)
X-AuditID: c1b4fb30-f79486d0000069d0-f2-573d7ddce47e
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DD.D7.27088.CDD7D375; Thu, 19 May 2016 10:48:29 +0200 (CEST)
Received: from ESESSMB309.ericsson.se ([169.254.9.40]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0248.002; Thu, 19 May 2016 10:48:28 +0200
From: Niklas Widell 
To: Jana Iyengar 
Thread-Topic: [QUIC] Version Negotiation vs. Option Negotiation
Thread-Index: AQHRsJ1wi7eZsKH3oECpSeLV6z5y6Z++uvIAgAE6QYA=
Date: Thu, 19 May 2016 08:48:28 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.4.160422
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_D36346C314B3Fniklaswidellericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2K7n+7dWttwg4b5XBY/7+1ktZh0dCGL Rc8CbgdmjwWbSj2WLPnJFMAUxWWTkpqTWZZapG+XwJWxrbOTuWCpS8XfCZuZGxiPWHYxcnJI CJhI9F/8xAJhi0lcuLeeDcQWEjjCKNH/iL+LkQvIXswoMbV/CStIgk3AQOL/twXMILaIgKLE 059f2bsYOTiYBVwkDs0wBQkLC9hJ/Fp2lg2ixF7i8Z2L7BC2lcTavVfAWlkEVCVe7TzCCtLK K2Au8f94NsSq6YwS97c+YwKp4RQIlFjyeBtYLyPQbd9PrQGLMwuIS9x6Mp8J4mYBiSV7zjND 2KISLx//AztTVEBP4su9eYwg8yWAzlzeLwdxZYzExwsWIBW8AoISJ2c+YZnAKDYLydBZCFWz kFRBlOhILNj9iQ3C1pZYtvA1M4x95sBjJgjbWqLh8x4WZDULGDlWMYoWpxYn5aYbGemlFmUm Fxfn5+nlpZZsYgRG58Etvw12ML587niIUYCDUYmHV0HONlyINbGsuDL3EKMEB7OSCG9+NVCI NyWxsiq1KD++qDQntfgQozQHi5I4r/9LxXAhgfTEktTs1NSC1CKYLBMHp1QDI/eSaakfA6ZV Jl+I5H7vzMJcwrqrf4tQnNq8OWH5S6fycWQnyxTphJ2T0z56IvOYs1HQvJLm18G9tStOrIg3 8Ak9dPnhm9WLzAo+RPzbvCfjSMjBl8vfPn+aoV0/88LHO3y2/2/Pmf4lhMFkwZGT5b0vjA4e /BjWYuA62/yZFffBD9mBndOXTFRiKc5INNRiLipOBACOs4r0ygIAAA==
Archived-At: 
Cc: Ian Swett , "quic@ietf.org" 
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 May 2016 08:48:33 -0000

--_000_D36346C314B3Fniklaswidellericssoncom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
While I understand the need to explicitly identify versions when doing expe=
rimentation with a new protocol, I do have a couple of concerns based on th=
e fact that QUIC assumedly will be a very widely deployed protocol:


  *   Keeping client/server versions deployed in synch is no problem if the=
 same entity controls both endpoints and can update them freely (like Googl=
e does for QUIC in Chrome today). However, in the wild I expect different v=
ersions to be deployed, some in places where they might be very hard to upg=
rade (like IoT and other embedded devices). I thus see a maintenance headac=
he to keep several simultaneous versions of QUIC server code running just t=
o be able to serve different clients.
  *   Who will bump the version? Is it IETF?
  *   Maybe the idea is to keep increasing the version of QUIC until the QU=
IC specs are final, and use that final version as THE version that hosts ne=
ed to implement, but then maybe that should be stated in the charter, or is=
 it implicitly assumed?

Cheers,
Niklas Widell
Ericsson AB

--


On 18/05/16 18:03, "QUIC on behalf of Ian Swett"  on behalf of ianswett@google.com> wrote:

Thanks Jana, the clarification is appreciated.

On Tue, May 17, 2016 at 8:37 PM, Jana Iyengar > wrote:
Greetings,

I am modifying the charter text that currently says "loss detection and rec=
overy, congestion control, and negotiation" to say "loss detection and reco=
very, congestion control, version negotiation, and option negotiation", and=
 I wanted to clarify the roles of version negotiation and option negotiatio=
n in the current version of QUIC, since it may be a source of a bit of conf=
usion.

Version negotiation is used for determining how to read and parse a QUIC pa=
cket. Any "on-the-wire" change to the core protocol or generally any change=
 that impacts interoperability results in a version change. Version negotia=
tion, as described in Section 7.1 of draft-tsvwg-quic-protocol-02, allows the tw=
o ends to agree on the version to use for communication. This is, as Christ=
ian puts it, a "blunt" instrument, and it should be treated as such. Versio=
ning is not generally intended to be used for negotiating the equivalent of=
 TCP options. The expectation is that versioning will also allow continued =
experimentation with QUIC.

I believe that no current IETF transport has versioning.

In addition to versioning, QUIC currently exchanges transport parameters --=
 the equivalent of TCP options -- during the handshake. This is described, =
though not in much detail, in Section 9 of draft-quic-protocol-02. Examples of thi=
ngs that may be negotiated via these parameters include max open streams, a=
mong other things. This mechanism may be used for negotiating features as w=
ell, such as use of multipath.

The initial drafts will contain both of these mechanisms.

- jana

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic



--_000_D36346C314B3Fniklaswidellericssoncom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <2CC2D291FE7D074CA685C063B952D296@ericsson.com>
Content-Transfer-Encoding: quoted-printable









Hi, 


While I understand the need to explicitly identify versions when doing=
 experimentation with a new protocol, I do have a couple of concerns based =
on the fact that QUIC assumedly will be a very widely deployed protocol:&nb=
sp;







    

  • Keeping client/server versions deployed in synch is no problem if the s=
ame entity controls both endpoints and can update them freely (like Google =
does for QUIC in Chrome today). However, in the wild I expect different ver=
sions to be deployed, some in places
 where they might be very hard to upgrade (like IoT and other embedded devi=
ces). I thus see a maintenance headache to keep several simultaneous versio=
ns of QUIC server code running just to be able to serve different clients.<=
/li>
  • Who will bump the version? Is it IETF?
  • Maybe the idea is to=
 keep increasing the version of QUIC until the QUIC specs are final, and us=
e that final version as THE version that hosts need to implement, but then =
maybe that should be stated in the charter, or is it implicitly assumed?







Cheers,


Niklas Widell


Ericsson AB









-- 



















On 18/05/16 18:03, "QUIC on behalf of Ian Swett" <quic-bounces@ietf.org on behalf of
ianswett@google.com> wrote:














Thanks Jana, the clarification is appreciated.





On Tue, May 17, 2016 at 8:37 PM, Jana Iyengar 
<jri@google.com&=
gt; wrote:




Greetings,






I am modifying the charter text that currently says "loss detecti=
on and recovery, congestion control, and negotiation" to say "los=
s detection and recovery, congestion control, version negotiation, and opti=
on negotiation", and I wanted to clarify the roles
 of version negotiation and option negotiation in the current version of QU=
IC, since it may be a source of a bit of confusion.







Version negotiation is used for determining how to read and parse a QU=
IC packet. Any "on-the-wire" change to the core protocol or gener=
ally any change that impacts interoperability results in a version change. =
Version negotiation, as described in

Section 7.1 of draft-tsvwg-quic-protocol-02, allows the two ends to agr=
ee on the version to use for communication. This is, as Christian puts it, =
a "blunt" instrument, and it should be treated as such. Versionin=
g is not generally intended to be used for
 negotiating the equivalent of TCP options. The expectation is that version=
ing will also allow continued experimentation with QUIC.







I believe that no current IETF transport has versioning.







In addition to versioning, QUIC currently exchanges transport paramete=
rs -- the equivalent of TCP options -- during the handshake. This is descri=
bed, though not in much detail, in

Section 9 of draft-quic-protocol-02. Examples of things that may be neg=
otiated via these parameters include max open streams, among other things. =
This mechanism may be used for negotiating features as well, such as use of=
 multipath.







The initial drafts will contain both of these mechanisms.








- jana





_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





















--_000_D36346C314B3Fniklaswidellericssoncom_--


From nobody Fri May 20 06:17:21 2016
Return-Path: 
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 481B812D944 for ; Fri, 20 May 2016 06:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 NAk9km0akeU2 for ; Fri, 20 May 2016 06:17:16 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8FA12D932 for ; Fri, 20 May 2016 06:17:16 -0700 (PDT)
X-AuditID: c1b4fb3a-f79386d00000467b-61-573f0e591eb4
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F3.B3.18043.95E0F375; Fri, 20 May 2016 15:17:13 +0200 (CEST)
Received: from ESESSMB309.ericsson.se ([169.254.9.40]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Fri, 20 May 2016 15:17:13 +0200
From: Niklas Widell 
To: Patrick McManus 
Thread-Topic: [QUIC] Version Negotiation vs. Option Negotiation
Thread-Index: AQHRsJ1wi7eZsKH3oECpSeLV6z5y6Z++uvIAgAE6QYCAAD0ZAIABoE8A
Date: Fri, 20 May 2016 13:17:12 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.4.160422
x-originating-ip: [153.88.183.19]
Content-Type: multipart/alternative; boundary="_000_D364DAD9156B3niklaswidellericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsUyM2K7hG4kn324QcNVNYuf93ayWkw6upDF 4uXsNYwWPQu4HVg8drauZfRYsKnUY8mSn0wBzFFcNimpOZllqUX6dglcGQfa2AumZ1cc/3qL uYFxVlQXIyeHhICJxKGDsxghbDGJC/fWs3UxcnEICRxhlOjvamOCcBYzSlx+uZYZpIpNwEDi /7cFYLaIgJbEvqZn7CA2s0CqxNcZb1hAbGEBO4lfy86yQdTYSzy+c5EdwnaTePqkC8jm4GAR UJU4tdkYxOQVMJdo/KwIsaqHSWJ/40uwMZwCgRLLLrWDrWIEOu77qTVMEKvEJW49mc8EcbSA xJI955khbFGJl4//sYLYogJ6El/uzYN6TFGi/WkDI0RvjMSLjo9g83kFBCVOznzCMoFRbBaS sbOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdAvRxAtrXEv3YbZCULGDlWMYoWpxYX56Yb GemlFmUmFxfn5+nlpZZsYgRG7cEtv612MB587niIUYCDUYmHd0G+XbgQa2JZcWXuIUYJDmYl EV55XvtwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYy+ M3t+hJ03j1vzdOoywfjLPb3FrZncl5WWZ89kCy28cHFFSPidi7sKTBRuMvsFataaFrA7t+oc ZvnGZixgf5p9y7vzPZ4fSt45eBx+Hpyw2yGg6UhXm+7/yiztS9GGT8UnJZ3/e+zxE/XlPHPi 7T8sYJnf0n9cz23nKa6LXJWLXk1TyFlR5KXEUpyRaKjFXFScCAC69jyi1gIAAA==
Archived-At: 
Cc: Jana Iyengar , Ian Swett , "quic@ietf.org" 
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 May 2016 13:17:19 -0000

--_000_D364DAD9156B3niklaswidellericssoncom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Patrick,
Thanks for the explanation, no reason to worry then I suppose.

Cheers
Niklas

--


On 19/05/16 16:27, "Patrick McManus" > wrote:

Hi Niklas,

You're basically envisioning the process that was used for versioning http/=
2 during standardization.. it was known as various "http2-draft-N" with a v=
ariety of N's that were negotiated at each connection setup. Each token cor=
responded to a specific Internet-Draft. The last version was simply renamed=
 "h2" and the draft versions faded from the Internet.

This worked quite well at enabling experimental deployments - especially be=
cause the fallback to HTTP/1 was realistically always possible in the case =
there wasn't a shared version between client and server. Some deployments s=
upported just 1 version at a time, and relied more heavily on HTTP/1 fallba=
ck, others offered a small set of options in order to get the most experien=
ce possible. This worked very well and could work for this effort too as lo=
ng as the higher level service had a TCP fallback available. The Internet-D=
rafts also took the, un-necessary imo, step of declaring some drafts as "fo=
r implementation" and others not. There were a few deployments of non-imple=
mentable drafts anyhow between consenting peers.

During development this is a much cleaner approach than a matrix of mix and=
 match features negotiated on a per feature basis - especially when you're =
trying to make sense of the data gathered from the running code.

-Patrick



On Thu, May 19, 2016 at 4:48 AM, Niklas Widell > wrote:
Hi,
While I understand the need to explicitly identify versions when doing expe=
rimentation with a new protocol, I do have a couple of concerns based on th=
e fact that QUIC assumedly will be a very widely deployed protocol:


  *   Keeping client/server versions deployed in synch is no problem if the=
 same entity controls both endpoints and can update them freely (like Googl=
e does for QUIC in Chrome today). However, in the wild I expect different v=
ersions to be deployed, some in places where they might be very hard to upg=
rade (like IoT and other embedded devices). I thus see a maintenance headac=
he to keep several simultaneous versions of QUIC server code running just t=
o be able to serve different clients.
  *   Who will bump the version? Is it IETF?
  *   Maybe the idea is to keep increasing the version of QUIC until the QU=
IC specs are final, and use that final version as THE version that hosts ne=
ed to implement, but then maybe that should be stated in the charter, or is=
 it implicitly assumed?

Cheers,
Niklas Widell
Ericsson AB

--


On 18/05/16 18:03, "QUIC on behalf of Ian Swett"  on behalf of ianswett@google.com> wrote:

Thanks Jana, the clarification is appreciated.

On Tue, May 17, 2016 at 8:37 PM, Jana Iyengar > wrote:
Greetings,

I am modifying the charter text that currently says "loss detection and rec=
overy, congestion control, and negotiation" to say "loss detection and reco=
very, congestion control, version negotiation, and option negotiation", and=
 I wanted to clarify the roles of version negotiation and option negotiatio=
n in the current version of QUIC, since it may be a source of a bit of conf=
usion.

Version negotiation is used for determining how to read and parse a QUIC pa=
cket. Any "on-the-wire" change to the core protocol or generally any change=
 that impacts interoperability results in a version change. Version negotia=
tion, as described in Section 7.1 of draft-tsvwg-quic-protocol-02, allows the tw=
o ends to agree on the version to use for communication. This is, as Christ=
ian puts it, a "blunt" instrument, and it should be treated as such. Versio=
ning is not generally intended to be used for negotiating the equivalent of=
 TCP options. The expectation is that versioning will also allow continued =
experimentation with QUIC.

I believe that no current IETF transport has versioning.

In addition to versioning, QUIC currently exchanges transport parameters --=
 the equivalent of TCP options -- during the handshake. This is described, =
though not in much detail, in Section 9 of draft-quic-protocol-02. Examples of thi=
ngs that may be negotiated via these parameters include max open streams, a=
mong other things. This mechanism may be used for negotiating features as w=
ell, such as use of multipath.

The initial drafts will contain both of these mechanisms.

- jana

_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic



_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic



--_000_D364DAD9156B3niklaswidellericssoncom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <067BD0F138DF2C4A95BD3EB6F7107294@ericsson.com>
Content-Transfer-Encoding: quoted-printable









Hi Patrick, 


Thanks for the explanation, no reason to worry then I suppose. 






Cheers


Niklas









-- 



















On 19/05/16 16:27, "Patrick McManus" <mcmanus@ducksong.com> wrote:























Hi Niklas, 





You're basically envisioning the process that was used for versioning http/=
2 during standardization.. it was known as various "http2-draft-N"=
; with a variety of N's that were negotiated at each connection setup. Each=
 token corresponded to a specific Internet-Draft.
 The last version was simply renamed "h2" and the draft versions =
faded from the Internet.





This worked quite well at enabling experimental deployments - especially be=
cause the fallback to HTTP/1 was realistically always possible in the case =
there wasn't a shared version between client and server. Some deployments s=
upported just 1 version at a time,
 and relied more heavily on HTTP/1 fallback, others offered a small set of =
options in order to get the most experience possible. This worked very well=
 and could work for this effort too as long as the higher level service had=
 a TCP fallback available. The Internet-Drafts
 also took the, un-necessary imo, step of declaring some drafts as "fo=
r implementation" and others not. There were a few deployments of non-=
implementable drafts anyhow between consenting peers.





During development this is a much cleaner approach than a matrix of mix and=
 match features negotiated on a per feature basis - especially when you're =
trying to make sense of the data gathered from the running code.





-Patrick


















On Thu, May 19, 2016 at 4:48 AM, Niklas Widell <=
span dir=3D"ltr">
<niklas.=
widell@ericsson.com> wrote:








Hi, 


While I understand the need to explicitly identify versions when doing=
 experimentation with a new protocol, I do have a couple of concerns based =
on the fact that QUIC assumedly will be a very widely deployed protocol:&nb=
sp;







    

  • Keeping client/server versions deployed in synch is no problem if the s=
ame entity controls both endpoints and can update them freely (like Google =
does for QUIC in Chrome today). However, in the wild I expect different ver=
sions to be deployed, some in places
 where they might be very hard to upgrade (like IoT and other embedded devi=
ces). I thus see a maintenance headache to keep several simultaneous versio=
ns of QUIC server code running just to be able to serve different clients.<=
/li>
  • Who will bump the version? Is it IETF?
  • Maybe the idea is to=
 keep increasing the version of QUIC until the QUIC specs are final, and us=
e that final version as THE version that hosts need to implement, but then =
maybe that should be stated in the charter, or is it implicitly assumed?







Cheers,


Niklas Widell


Ericsson AB










-- 























On 18/05/16 18:03, "QUIC on behalf of Ian Swett" <quic-bounces@ietf.org on behalf of
ianswett@google.co=
m> wrote:















Thanks Jana, the clarification is appreciated.





On Tue, May 17, 2016 at 8:37 PM, Jana Iyengar 
<jri@google.com&=
gt; wrote:




Greetings,






I am modifying the charter text that currently says "loss detecti=
on and recovery, congestion control, and negotiation" to say "los=
s detection and recovery, congestion control, version negotiation, and opti=
on negotiation", and I wanted to clarify the roles
 of version negotiation and option negotiation in the current version of QU=
IC, since it may be a source of a bit of confusion.







Version negotiation is used for determining how to read and parse a QU=
IC packet. Any "on-the-wire" change to the core protocol or gener=
ally any change that impacts interoperability results in a version change. =
Version negotiation, as described in

Section 7.1 of draft-tsvwg-quic-protocol-02, allows the two ends to agr=
ee on the version to use for communication. This is, as Christian puts it, =
a "blunt" instrument, and it should be treated as such. Versionin=
g is not generally intended to be used for
 negotiating the equivalent of TCP options. The expectation is that version=
ing will also allow continued experimentation with QUIC.







I believe that no current IETF transport has versioning.







In addition to versioning, QUIC currently exchanges transport paramete=
rs -- the equivalent of TCP options -- during the handshake. This is descri=
bed, though not in much detail, in

Section 9 of draft-quic-protocol-02. Examples of things that may be neg=
otiated via these parameters include max open streams, among other things. =
This mechanism may be used for negotiating features as well, such as use of=
 multipath.







The initial drafts will contain both of these mechanisms.








- jana





_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic

























_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





















--_000_D364DAD9156B3niklaswidellericssoncom_--


From nobody Fri May 20 08:22:47 2016
Return-Path: 
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 CA48812D9EF for ; Fri, 20 May 2016 08:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 uLO4xdG8Qyv0 for ; Fri, 20 May 2016 08:22:44 -0700 (PDT)
Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6963112D9EE for ; Fri, 20 May 2016 08:22:44 -0700 (PDT)
Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.14.3) with ESMTP id u4KFMgr5021016 for ; Fri, 20 May 2016 16:22:42 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1012.national.core.bbc.co.uk ([10.161.14.16]) with mapi id 14.03.0195.001; Fri, 20 May 2016 16:22:42 +0100
From: Lucas Pardue 
To: "quic@ietf.org" 
Thread-Topic: [QUIC] Supporting HTTP/2 extension: frames and semantics
Thread-Index: AdGyqP3yyL/jBnftSvGW3FGNxs5zVw==
Date: Fri, 20 May 2016 15:22:41 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A2A80998D@bgb01xud1012>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.161.211]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22332.007
x-tm-as-result: No--40.233400-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A2A80998Dbgb01xud1012_"
MIME-Version: 1.0
Archived-At: 
Subject: [QUIC]  Supporting HTTP/2 extension: frames and semantics
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 May 2016 15:22:45 -0000

--_000_7CF7F94CB496BF4FAB1676F375F9666A2A80998Dbgb01xud1012_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

I would like to gain further clarification on the mapping of HTTP/2 frames =
in QUIC, especially with regards to extension via new frame types. Is it an=
ticipated that HTTP/2 extension frame types will be supported in QUIC and i=
s there a feeling about how that would be defined?

Previous QUIC documents have covered how to map HTTP/2 frame types such as =
HEADERS or DATA, however there was little explanation of how something like=
 the ALTSVC frame [1] would be supported in QUIC (if at all). In the specif=
ic case of HTTP Alternative Services we can fallback on the header field cr=
utch and use Alt-Svc to express the same service detail within a HEADERS fr=
ame. However, this does not hold true for other extensions such as the ORIG=
IN frame [2].

I am also interested in understanding how QUIC might handle HTTP semantic e=
xtension such as proposed in the Peer-to-Peer Extension to HTTP/2 [3].

Lucas

[1] https://tools.ietf.org/html/rfc7838
[2] https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/
[3] https://tools.ietf.org/html/draft-benfield-http2-p2p


--_000_7CF7F94CB496BF4FAB1676F375F9666A2A80998Dbgb01xud1012_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hello,


 


I would like to gain further cl=
arification on the mapping of HTTP/2 frames in QUIC, especially with regard=
s to extension via new frame types. Is it anticipated that HTTP/2 extension=
 frame types will be supported in QUIC
 and is there a feeling about how that would be defined?<=
/p>

 


Previous QUIC documents have co=
vered how to map HTTP/2 frame types such as HEADERS or DATA, however there =
was little explanation of how something like the ALTSVC frame [1] would be =
supported in QUIC (if at all). In the
 specific case of HTTP Alternative Services we can fallback on the header f=
ield crutch and use Alt-Svc to express the same service detail within a HEA=
DERS frame. However, this does not hold true for other extensions such as t=
he ORIGIN frame [2].


 


I am also interested in underst=
anding how QUIC might handle HTTP semantic extension such as proposed in th=
e Peer-to-Peer Extension to HTTP/2 [3].


 


Lucas


 


[1] 
https://tools.ietf.org/html/rfc7838


[2] 
https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/<=
/o:p>


[3] 
https://tools.ietf.org/html/draft-benfield-http2-p2p<=
/p>

 






--_000_7CF7F94CB496BF4FAB1676F375F9666A2A80998Dbgb01xud1012_--


From nobody Fri May 20 14:07:45 2016
Return-Path: 
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 A43E312D651 for ; Fri, 20 May 2016 14:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 r0hfhBCyGUnc for ; Fri, 20 May 2016 14:07:43 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 D4AEE12D0BF for ; Fri, 20 May 2016 14:07:42 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id v200so245816wmv.1 for ; Fri, 20 May 2016 14:07:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hsbqqQYxAg38/H2QS98xGzNDXD1uogmD2LMn4NFdqlY=; b=kFj1eVsT01PqvDKH2eCAqcVp9ckWg0vwdPOacYWZnz9hzK1oM46a07sDXOqAgoxBEo ArE+FO0c93R7tWj08gBMBpHWN+BeDvBp0obQQDpyqdgnjiWXefC+Q2RFtLqLZNnzh0N2 xrumLnm4qp6gZSLi8foA2kWrWMpvcRIg4pYFSv6o3HaKtyVUs5PafIAjC0BClI/Ux9LR Cu7uSfMlxhS3Pr/9/VnBD8Ov76A/uR4Pn6WOya3OTQ08YqDDWcFAn+4Zd8vrSpdJpBmT AX70fXLHp1i71F/ENZchJzrYPR6rrmzqQOqiO3Op1ToSesKn/WFf8fzwQzq/Jb55fbuq flcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hsbqqQYxAg38/H2QS98xGzNDXD1uogmD2LMn4NFdqlY=; b=lqlZV0DTFTVuS9brIWLk+pvMYVG8j70p/iF7qzav392CIZMBqkAIA2VBRKeKPpqiBh rbMfnPyAWIg3WoXBmvmoI0lJ9GHQVWLX9xp5NGUwQXxDO3XnDGZBscs/6K6O289o2Ihg A6qjeAPVX2DyRPIJ+aaysOZYvC/NRWj4uVNbz3mh7Q//IVURYQiiodnD3UyYrT/8gG0Y dRLIoWHoYrabssaD/vBn0uYAZnwGJ3zOnpt/2fHnNo/0n5VrwugEm2ZzO0EDVUq4W4ZM TTghMlsvNIi7v31sAhOTFiG1eyM8rjWVgcTHuZNLj6OwmDL9guWHAIG5ba3oUWaiwp77 /LOg==
X-Gm-Message-State: AOPr4FXGN3F7UzDLwWYwa3c0qMuyK0GWRkaUjfyySV+BC6nOLr8dSW9QdllhZEXMhQgDT2x12CX9Pvb58rYAhfs0
X-Received: by 10.28.157.202 with SMTP id g193mr5934961wme.46.1463778461278; Fri, 20 May 2016 14:07:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.46.151 with HTTP; Fri, 20 May 2016 14:07:40 -0700 (PDT)
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A2A80998D@bgb01xud1012>
References: <7CF7F94CB496BF4FAB1676F375F9666A2A80998D@bgb01xud1012>
From: Ryan Hamilton 
Date: Fri, 20 May 2016 14:07:40 -0700
Message-ID: 
To: Lucas Pardue 
Content-Type: multipart/alternative; boundary=001a114b30243738b305334c7b54
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] Supporting HTTP/2 extension: frames and semantics
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 May 2016 21:07:44 -0000

--001a114b30243738b305334c7b54
Content-Type: text/plain; charset=UTF-8

I don't know that we yet have an answer to this question. I suspect that
the third focus area will resolve this issue. That being said, the simplest
solution would be to deliver these HTTP/2 frames on the QUIC Headers Stream
since that is already processing HTTP/2 frames.

On Fri, May 20, 2016 at 8:22 AM, Lucas Pardue 
wrote:

> Hello,
>
>
>
> I would like to gain further clarification on the mapping of HTTP/2 frames
> in QUIC, especially with regards to extension via new frame types. Is it
> anticipated that HTTP/2 extension frame types will be supported in QUIC and
> is there a feeling about how that would be defined?
>
>
>
> Previous QUIC documents have covered how to map HTTP/2 frame types such as
> HEADERS or DATA, however there was little explanation of how something like
> the ALTSVC frame [1] would be supported in QUIC (if at all). In the
> specific case of HTTP Alternative Services we can fallback on the header
> field crutch and use Alt-Svc to express the same service detail within a
> HEADERS frame. However, this does not hold true for other extensions such
> as the ORIGIN frame [2].
>
>
>
> I am also interested in understanding how QUIC might handle HTTP semantic
> extension such as proposed in the Peer-to-Peer Extension to HTTP/2 [3].
>
>
>
> Lucas
>
>
>
> [1] https://tools.ietf.org/html/rfc7838
>
> [2] https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/
>
> [3] https://tools.ietf.org/html/draft-benfield-http2-p2p
>
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>

--001a114b30243738b305334c7b54
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I don't know that we yet have an answer to this questi=
on. I suspect that the third focus area will resolve this issue. That being=
 said, the simplest solution would be to deliver these HTTP/2 frames on the=
 QUIC Headers Stream since that is already processing HTTP/2 frames.
<=
div class=3D"gmail_extra">
On Fri, May 20, 20=
16 at 8:22 AM, Lucas Pardue <Lucas.Pardue@bbc.co.uk<=
/a>> wrote:











Hello,


=C2=A0


I would like to gain further cl=
arification on the mapping of HTTP/2 frames in QUIC, especially with regard=
s to extension via new frame types. Is it anticipated that HTTP/2 extension=
 frame types will be supported in QUIC
 and is there a feeling about how that would be defined?


=C2=A0


Previous QUIC documents have co=
vered how to map HTTP/2 frame types such as HEADERS or DATA, however there =
was little explanation of how something like the ALTSVC frame [1] would be =
supported in QUIC (if at all). In the
 specific case of HTTP Alternative Services we can fallback on the header f=
ield crutch and use Alt-Svc to express the same service detail within a HEA=
DERS frame. However, this does not hold true for other extensions such as t=
he ORIGIN frame [2].


=C2=A0


I am also interested in underst=
anding how QUIC might handle HTTP semantic extension such as proposed in th=
e Peer-to-Peer Extension to HTTP/2 [3].


=C2=A0


Lucas


=C2=A0


[1] 
https://tools.ietf.org/html/rfc7838


[2] 
https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/


[3] 
https://tools.ietf.org/html/draft-benfield-http2-p2p


=C2=A0







_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/qui=
c





--001a114b30243738b305334c7b54--


From nobody Fri May 20 15:49:14 2016
Return-Path: 
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 06CB712D584 for ; Fri, 20 May 2016 15:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 VKuDCvX1k5Ge for ; Fri, 20 May 2016 15:49:10 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 AFEA612D0A5 for ; Fri, 20 May 2016 15:49:10 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id x189so122929499ywe.3 for ; Fri, 20 May 2016 15:49:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2sz6Q65s5lu3JGaNYN7+NitDuUj4cGU1PKyZBMDZdqs=; b=H8vz8aVkfIw6ykTpIk89wOaSBrcCc0MSxqIkSGboPoMmDQRZ1CTegVFbiGdabDyKBp pinqhbPAMOi6lQEZA3IcvJqMTxlR7BdxZj02c7m1fcNs3Q4fwzX8RRCzXWnj3jJsg7oH OfCruCkcKiLvGwM9Eoj7Gd6CjP17AGSZzgjLLzzN8ETa0zMG6td13IULEg/KWdsATYPX dCBICxqqK7hKW8h/bHPpi8hicZ0mQ99H5hXtbZwuEjy6gerTRv+0eige4uWcUrEcT0TM uo5dMUJcxgweJIuA8BhBNxuVkjbYYPawZvobcVPRX4de5so/wkdEh96jW5Ri2Q2rT/zR rFUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2sz6Q65s5lu3JGaNYN7+NitDuUj4cGU1PKyZBMDZdqs=; b=hl9h9Fqm9iwECKW0uKcQJPP5k+iGfc7ZAdy+ChPZ9NHNqzITiydAFqcArcHa+bhWHX 21ub5FttzJeFJQr0MdtSu3FQmYdDqPlGN8amGDlaQ8sjlm3uaER5ckhjx2DxaZ5AgMCI PSwDaJvA/ZgVJN2yBfG7E9qARYGTJBI/O0b71/kEtWKs1Km0a2ok30ZlqNQPHuVlx8PX 1zEucrLgRGxYe/61wnfFngtlQLdXDg7vZv0YqYJLo+foIyRh8cSE3eV+kXvSXxwDDyOE kIGDBJjZjCKGWEuCCOELYR+QGLBD4/T/Kvk2qiR8Js35rEUm9e440U+d+yCMk2jrVMB9 VNNg==
X-Gm-Message-State: AOPr4FWkc+hR3HH2eoIEBdyrmkBVO9z2/ygqqwQ7WSiFfjUO4Z31jTqGDtuftmPyt+osZaM3679zNjG46kdS/l70
X-Received: by 10.13.193.134 with SMTP id c128mr3689245ywd.270.1463784549732;  Fri, 20 May 2016 15:49:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.215.202 with HTTP; Fri, 20 May 2016 15:49:09 -0700 (PDT)
In-Reply-To: 
References:     
From: Jana Iyengar 
Date: Fri, 20 May 2016 15:49:09 -0700
Message-ID: 
To: Niklas Widell 
Content-Type: multipart/alternative; boundary=001a114e70c61dd7cd05334de66e
Archived-At: 
Cc: Patrick McManus , Ian Swett , "quic@ietf.org" 
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 May 2016 22:49:13 -0000

--001a114e70c61dd7cd05334de66e
Content-Type: text/plain; charset=UTF-8

Hi Niklas,

In addition to what Patrick already said about revving versions through the
initial standardization process, one goal of QUIC is to allow iterability
in the protocol beyond the initial standard. I expect that the IETF will
remain the arbiter of new standardized versions, but individual deployments
should be able to do their own experimental versions as well. We will
probably need an IETF-mediated process using which folks can get and use
experimental version numbers, and this is part of the proposed charter of
work.

- jana

On Fri, May 20, 2016 at 6:17 AM, Niklas Widell 
wrote:

> Hi Patrick,
> Thanks for the explanation, no reason to worry then I suppose.
>
> Cheers
> Niklas
>
> --
>
>
> On 19/05/16 16:27, "Patrick McManus"  wrote:
>
> Hi Niklas,
>
> You're basically envisioning the process that was used for versioning
> http/2 during standardization.. it was known as various "http2-draft-N"
> with a variety of N's that were negotiated at each connection setup. Each
> token corresponded to a specific Internet-Draft. The last version was
> simply renamed "h2" and the draft versions faded from the Internet.
>
> This worked quite well at enabling experimental deployments - especially
> because the fallback to HTTP/1 was realistically always possible in the
> case there wasn't a shared version between client and server. Some
> deployments supported just 1 version at a time, and relied more heavily on
> HTTP/1 fallback, others offered a small set of options in order to get the
> most experience possible. This worked very well and could work for this
> effort too as long as the higher level service had a TCP fallback
> available. The Internet-Drafts also took the, un-necessary imo, step of
> declaring some drafts as "for implementation" and others not. There were a
> few deployments of non-implementable drafts anyhow between consenting peers.
>
> During development this is a much cleaner approach than a matrix of mix
> and match features negotiated on a per feature basis - especially when
> you're trying to make sense of the data gathered from the running code.
>
> -Patrick
>
>
>
> On Thu, May 19, 2016 at 4:48 AM, Niklas Widell  > wrote:
>
>> Hi,
>> While I understand the need to explicitly identify versions when doing
>> experimentation with a new protocol, I do have a couple of concerns based
>> on the fact that QUIC assumedly will be a very widely deployed protocol:
>>
>>
>>    - Keeping client/server versions deployed in synch is no problem if
>>    the same entity controls both endpoints and can update them freely (like
>>    Google does for QUIC in Chrome today). However, in the wild I expect
>>    different versions to be deployed, some in places where they might be very
>>    hard to upgrade (like IoT and other embedded devices). I thus see a
>>    maintenance headache to keep several simultaneous versions of QUIC server
>>    code running just to be able to serve different clients.
>>    - Who will bump the version? Is it IETF?
>>    - Maybe the idea is to keep increasing the version of QUIC until the
>>    QUIC specs are final, and use that final version as THE version that hosts
>>    need to implement, but then maybe that should be stated in the charter, or
>>    is it implicitly assumed?
>>
>>
>> Cheers,
>> Niklas Widell
>> Ericsson AB
>>
>> --
>>
>>
>> On 18/05/16 18:03, "QUIC on behalf of Ian Swett" > on behalf of ianswett@google.com> wrote:
>>
>> Thanks Jana, the clarification is appreciated.
>>
>> On Tue, May 17, 2016 at 8:37 PM, Jana Iyengar  wrote:
>>
>>> Greetings,
>>>
>>> I am modifying the charter text that currently says "loss detection and
>>> recovery, congestion control, and negotiation" to say "loss detection and
>>> recovery, congestion control, version negotiation, and option negotiation",
>>> and I wanted to clarify the roles of version negotiation and option
>>> negotiation in the current version of QUIC, since it may be a source of a
>>> bit of confusion.
>>>
>>> Version negotiation is used for determining how to read and parse a QUIC
>>> packet. Any "on-the-wire" change to the core protocol or generally any
>>> change that impacts interoperability results in a version change. Version
>>> negotiation, as described in Section 7.1 of draft-tsvwg-quic-protocol-02
>>> ,
>>> allows the two ends to agree on the version to use for communication. This
>>> is, as Christian puts it, a "blunt" instrument, and it should be treated as
>>> such. Versioning is not generally intended to be used for negotiating the
>>> equivalent of TCP options. The expectation is that versioning will also
>>> allow continued experimentation with QUIC.
>>>
>>> I believe that no current IETF transport has versioning.
>>>
>>> In addition to versioning, QUIC currently exchanges transport parameters
>>> -- the equivalent of TCP options -- during the handshake. This is
>>> described, though not in much detail, in Section 9 of
>>> draft-quic-protocol-02
>>> .
>>> Examples of things that may be negotiated via these parameters include max
>>> open streams, among other things. This mechanism may be used for
>>> negotiating features as well, such as use of multipath.
>>>
>>> The initial drafts will contain both of these mechanisms.
>>>
>>> - jana
>>>
>>> _______________________________________________
>>> QUIC mailing list
>>> QUIC@ietf.org
>>> https://www.ietf.org/mailman/listinfo/quic
>>>
>>>
>>
>> _______________________________________________
>> QUIC mailing list
>> QUIC@ietf.org
>> https://www.ietf.org/mailman/listinfo/quic
>>
>>
>

--001a114e70c61dd7cd05334de66e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Niklas,

In addition to what Patrick =
already said about revving versions through the initial standardization pro=
cess, one goal of QUIC is to allow iterability in the protocol beyond the i=
nitial standard. I expect that the IETF will remain the arbiter of new stan=
dardized versions, but individual deployments should be able to do their ow=
n experimental versions as well. We will probably need an IETF-mediated pro=
cess using which folks can get and use experimental version numbers, and th=
is is part of the proposed charter of work.

- jana

On Fri, May 20, 2016 at 6:17 AM, Niklas Wi=
dell <niklas.widell@ericsson.com> wrote:









Hi Patrick,=C2=A0


Thanks for the explanation, no reason to worry then I suppose.=C2=A0






Cheers


Niklas









--=C2=A0



















On 19/05/16 16:27, "Patrick McManus" <mcmanus@ducksong.com> wrote:<=
/div>






















Hi Niklas, 





You're basically envisioning the process that was used for versioning h=
ttp/2 during standardization.. it was known as various "http2-draft-N&=
quot; with a variety of N's that were negotiated at each connection set=
up. Each token corresponded to a specific Internet-Draft.
 The last version was simply renamed "h2" and the draft versions =
faded from the Internet.





This worked quite well at enabling experimental deployments - especially be=
cause the fallback to HTTP/1 was realistically always possible in the case =
there wasn't a shared version between client and server. Some deploymen=
ts supported just 1 version at a time,
 and relied more heavily on HTTP/1 fallback, others offered a small set of =
options in order to get the most experience possible. This worked very well=
 and could work for this effort too as long as the higher level service had=
 a TCP fallback available. The Internet-Drafts
 also took the, un-necessary imo, step of declaring some drafts as "fo=
r implementation" and others not. There were a few deployments of non-=
implementable drafts anyhow between consenting peers.





During development this is a much cleaner approach than a matrix of mix and=
 match features negotiated on a per feature basis - especially when you'=
;re trying to make sense of the data gathered from the running code.





-Patrick


















On Thu, May 19, 2016 at 4:48 AM, Niklas Widell <=
span dir=3D"ltr">
<niklas.=
widell@ericsson.com> wrote:








Hi,=C2=A0


While I understand the need to explicitly identify versions when doing=
 experimentation with a new protocol, I do have a couple of concerns based =
on the fact that QUIC assumedly will be a very widely deployed protocol:=C2=
=A0







    

  • Keeping client/server versions deployed in synch is no problem if the s=
ame entity controls both endpoints and can update them freely (like Google =
does for QUIC in Chrome today). However, in the wild I expect different ver=
sions to be deployed, some in places
 where they might be very hard to upgrade (like IoT and other embedded devi=
ces). I thus see a maintenance headache to keep several simultaneous versio=
ns of QUIC server code running just to be able to serve different clients.<=
/li>
  • Who will bump the version? Is it IETF?
  • Maybe the idea is to=
 keep increasing the version of QUIC until the QUIC specs are final, and us=
e that final version as THE version that hosts need to implement, but then =
maybe that should be stated in the charter, or is it implicitly assumed?







Cheers,


Niklas Widell


Ericsson AB










--=C2=A0























On 18/05/16 18:03, "QUIC on behalf of Ian Swett" <quic-bounces@ietf.org on behalf of
ianswett@google.co=
m> wrote:















Thanks Jana, the clarification is appreciated.





On Tue, May 17, 2016 at 8:37 PM, Jana Iyengar 
<jri@google.com&=
gt; wrote:




Greetings,






I am modifying the charter text that currently says "loss detecti=
on and recovery, congestion control, and negotiation" to say "los=
s detection and recovery, congestion control, version negotiation, and opti=
on negotiation", and I wanted to clarify the roles
 of version negotiation and option negotiation in the current version of QU=
IC, since it may be a source of a bit of confusion.







Version negotiation is used for determining how to read and parse a QU=
IC packet. Any "on-the-wire" change to the core protocol or gener=
ally any change that impacts interoperability results in a version change. =
Version negotiation, as described in

Section 7.1 of draft-tsvwg-quic-protocol-02, allows the two ends to agr=
ee on the version to use for communication. This is, as Christian puts it, =
a "blunt" instrument, and it should be treated as such. Versionin=
g is not generally intended to be used for
 negotiating the equivalent of TCP options. The expectation is that version=
ing will also allow continued experimentation with QUIC.







I believe that no current IETF transport has versioning.







In addition to versioning, QUIC currently exchanges transport paramete=
rs -- the equivalent of TCP options -- during the handshake. This is descri=
bed, though not in much detail, in

Section 9 of draft-quic-protocol-02. Examples of things that may be neg=
otiated via these parameters include max open streams, among other things. =
This mechanism may be used for negotiating features as well, such as use of=
 multipath.







The initial drafts will contain both of these mechanisms.








- jana





_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic

























_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic

























--001a114e70c61dd7cd05334de66e--


From nobody Fri May 20 15:54:39 2016
Return-Path: 
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 9DA5C12D65F for ; Fri, 20 May 2016 15:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 vZzg2gvUMAFS for ; Fri, 20 May 2016 15:54:35 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 01E5A12D633 for ; Fri, 20 May 2016 15:54:34 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id o16so5343124ywd.2 for ; Fri, 20 May 2016 15:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DXm1mwFmPkxAAfTgqzHDiSelxHrf20SqkHpiJdwbMMc=; b=J990Ipi/rXGM569w+ugmcgO9XB44nHxqQhMaX908ABlqjgraOLGP1QB061njyXFcJh Fqg3OMPxKh5SvLKbFFImvRQaf+LY4SQKRDthYmSaGJApfIgPF5+nwd5TBgTCCEeaJ6c4 KxUPWQkZ2yWBOhtk5BWWAJ9rcDY6WeefEpdILwDmOfOZPGdlzNU32ZkzHg6cOkLK9emz KKNc13axCncVlUVCI3bdbK6gD5odRS+xK4RDwql64HFkcjSzaADUkdJZXVDpjxJLjTc6 X6qNRyDdqXPRocAa4gdaQ5Qgg3qz1dmbqUOuloxLYmkZPoFfjeQrdYpuS99FdyMzRQhx 4g5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DXm1mwFmPkxAAfTgqzHDiSelxHrf20SqkHpiJdwbMMc=; b=HXMIaR8h9SSrrHFAkGtliPSNu5stRoYWpIdmkMlsiLWGY9FM30uDIKPWRgl4EEdmet XxDfkVLPlgqggCNZvu1u0/NqjthyUMCMgtJrIOMXisv/aNRg0+wtB9tsGwNBjKEkxAE0 f79UVShqyI4NOefqlqaDwSGNb9erNKpUUXN/4/T2l4J8fXxjFVMMXGfzZjSan3yF9BkJ ZALrDSLGMDQht6BIGCKjnlhMOkv0+6wKt+IL18yGbSWLO8STHu8bQndIPajjCCf9OYIn 2qAW6p9ycoxxxCBCd9ppOOlUUNlKK25e0QggwI89cINZFm3t+2M861kTQ8ossSVu4bb3 UTgA==
X-Gm-Message-State: AOPr4FXX6K8xrXU08EJM0TyMso49515kycczfz6I4miNvKpsuDLRHQ/mMaRyN+VxCWDa4dZe0Gz+jP2K6YhRHGny
X-Received: by 10.13.218.65 with SMTP id c62mr3392015ywe.36.1463784874063; Fri, 20 May 2016 15:54:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.215.202 with HTTP; Fri, 20 May 2016 15:54:33 -0700 (PDT)
In-Reply-To: <59f8ddb3-8cd3-6cbe-19c1-07c88264a8c8@tessares.net>
References:    <59f8ddb3-8cd3-6cbe-19c1-07c88264a8c8@tessares.net>
From: Jana Iyengar 
Date: Fri, 20 May 2016 15:54:33 -0700
Message-ID: 
To: Olivier Bonaventure 
Content-Type: multipart/alternative; boundary=94eb2c08050872c81705334df965
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" , =?UTF-8?Q?G=C3=B6ran_Eriksson_AP?= 
Subject: Re: [QUIC] Scope of multi-path WAS: Re: Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 May 2016 22:54:36 -0000

--94eb2c08050872c81705334df965
Content-Type: text/plain; charset=UTF-8

On Mon, May 16, 2016 at 2:57 PM, Olivier Bonaventure <
olivier.bonaventure@tessares.net> wrote:

> Goran,
>
>>
>> Sounds like a good scope for a focused first phase. There may be some use
>> cases for HTTP/2 in a multi-homed device that goes beyond the current
>> MPTCP implementations but let me get back on that one later (need to
>> noodle that problem some more).
>>
>> Personally leaning towards also describing the scope in text but I am open
>> to other views, :-).
>>
>> And as we refer to SCTP and MPTCP, then possibly API considerations should
>> be a deliverable as well as these are available for MPTCP if I am not
>> mistaken (RFC6897 right?).
>>
>
> Well, although the title of RFC6897 contains the word API, it is very
> minimalist and cannot be considered as an API that allows to control MPTCP.
> If RFC6897 is used as an example to specify an API for QUIC, then it means
> that the WG will not really produce an API...
>
> If QUIC focuses on the HTTP/2 like use case, I'm not sure that an API
> would be required. Maybe some QUIC parameters could be exposed and possibly
> tuned by the applications using QUIC.


I agree. At this point, it's not clear to me how useful a QUIC API doc will
be. We can certainly consider it later as more implementations emerge.

- jana


>
> Olivier
>
> --
>
> ------------------------------
> DISCLAIMER.
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> This message contains confidential information and is intended only for the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. If you are not the intended recipient
> you are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this information is strictly
> prohibited.
>

--94eb2c08050872c81705334df965
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 16, 2016 at 2:57 PM, Olivier Bonaventure <olivier.b=
onaventure@tessares.net> wrote:
Goran,





Sounds like a good scope for a focused first phase. There may be some use
cases for HTTP/2 in a multi-homed device that goes beyond the current

MPTCP implementations but let me get back on that one later (need to

noodle that problem some more).



Personally leaning towards also describing the scope in text but I am open<=
br>
to other views, :-).



And as we refer to SCTP and MPTCP, then possibly API considerations should<=
br>
be a deliverable as well as these are available for MPTCP if I am not

mistaken (RFC6897 right?).





Well, although the title of RFC6897 contains the word API, it is very minim=
alist and cannot be considered as an API that allows to control MPTCP. If R=
FC6897 is used as an example to specify an API for QUIC, then it means that=
 the WG will not really produce an API...



If QUIC focuses on the HTTP/2 like use case, I'm not sure that an API w=
ould be required. Maybe some QUIC parameters could be exposed and possibly =
tuned by the applications using QUIC.

I agr=
ee. At this point, it's not clear to me how useful a QUIC API doc will =
be. We can certainly consider it later as more implementations emerge.

- jana





Olivier



-- 



------------------------------

DISCLAIMER.

This email and any files transmitted with it are confidential and intended =
solely for the use of the individual or entity to whom they are addressed. =
If you have received this email in error please notify the system manager. =
This message contains confidential information and is intended only for the=
 individual named. If you are not the named addressee you should not dissem=
inate, distribute or copy this e-mail. Please notify the sender immediately=
 by e-mail if you have received this e-mail by mistake and delete this e-ma=
il from your system. If you are not the intended recipient you are notified=
 that disclosing, copying, distributing or taking any action in reliance on=
 the contents of this information is strictly prohibited.





--94eb2c08050872c81705334df965--


From nobody Fri May 20 16:34:19 2016
Return-Path: 
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 393F712D65F for ; Fri, 20 May 2016 16:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 dT2R6aYeyjBQ for ; Fri, 20 May 2016 16:34:17 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46A612D633 for ; Fri, 20 May 2016 16:34:16 -0700 (PDT)
X-AuditID: c1b4fb3a-f79386d00000467b-8a-573f9ef69924
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D4.25.18043.6FE9F375; Sat, 21 May 2016 01:34:14 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Sat, 21 May 2016 01:34:14 +0200
From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= 
To: Jana Iyengar , Olivier Bonaventure 
Thread-Topic: [QUIC] Scope of multi-path WAS: Re: Draft charter
Thread-Index: AQHRr4wQUahMae7V6EaJpFFBu2L7/5+8F+sA///jboCABlktgIAALJwA
Date: Fri, 20 May 2016 23:34:13 +0000
Message-ID: 
References:    <59f8ddb3-8cd3-6cbe-19c1-07c88264a8c8@tessares.net> 
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.4.160422
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUyM2K7me63efbhBqf6tSyaPvcxWkw6upDF YnbjcRaLngXcFo1z7RxYPXbOusvusWBTqceSJT+ZPFp3/GX3uNM0nTmANYrLJiU1J7MstUjf LoErY8XxC+wFk1gqfj9bwtzA2MLSxcjJISFgIrHsUSsThC0mceHeerYuRi4OIYEjjBKvZj+B cpYwSqyc0AJWxSbgLdHWchisW0QgWmLW1lvMIDazQKHE6iffwGqEBewk5jfuAIpzANXYS0xd 5QdR7ibx/NZWsFYWAVWJe1/OMYLYvALWEg/nXwVrFRLYyCRxt5EDxOYUCJT4+3U5G4jNKCAr cf/7PRaIVeISt57MhzpaQGLJnvPMELaoxMvH/1hBbFEBPYkv9+YxQsSVJBbd/swEcg6zgKbE +l36EGOsJS7eWMAOYStKTOl+yA5xjqDEyZlPWCYwSsxCsm0WQvcsJN2zkHTPQtK9gJF1FaNo cWpxcW66kZFealFmcnFxfp5eXmrJJkZg5B7c8ttqB+PB546HGAU4GJV4eBfk24ULsSaWFVfm HmKU4GBWEuFNmGEfLsSbklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFqEUyW iYNTqoFxRdSsqrUGmhvXrLMqO2ZT8/L64uxvu0pDlxzMO1dVKyX1Z0mIlK1SalZWvuNln+NW t2Qinv9+qyT3lMv1LG8Ak8Shn0JbIjsW7JBXVrM3kpQ8t+5za6b5hqTjxkt2zCnZu/PJP65f xkEbP02zE57i9VI1/f7a91KNc+7tDH1ZP3Ha9C0J8l5rlViKMxINtZiLihMB9EBHbNgCAAA=
Archived-At: 
Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" 
Subject: Re: [QUIC] Scope of multi-path WAS: Re: Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 May 2016 23:34:18 -0000

DQoNCj5JIGFncmVlLiBBdCB0aGlzIHBvaW50LCBpdCdzIG5vdCBjbGVhciB0byBtZSBob3cgdXNl
ZnVsIGEgUVVJQyBBUEkgZG9jDQo+d2lsbCBiZS4gV2UgY2FuIGNlcnRhaW5seSBjb25zaWRlciBp
dCBsYXRlciBhcyBtb3JlIGltcGxlbWVudGF0aW9ucw0KPmVtZXJnZS4NCg0KKzENCg0KQnV0IHBl
cmhhcHMgeW91IGNvdWxkIGVsYWJvcmF0ZSBhIGJpdCBvbiB0aGUgdXNlIG9mIE1QUVVJQyBjYXNl
L3VzYWdlcyB5b3UNCmFyZSBjb25zaWRlcmluZz8NCg0KTW9iaWxpdHk/IEFuZCBpZiB5b3UgZm9y
ZXNlZSBhbnkgY2FzZSB3aGVyZSB0aGUgcGF0aCBzZWxlY3Rpb24gd2lsbCBiZQ0KZG9uZSBiYXNl
ZCBvbiBodHRwIGxheWVyIGlucHV0Pw0KDQpSZWdhcmRzDQpHw7ZyYW4NCg0K


From nobody Fri May 20 23:27:03 2016
Return-Path: 
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 32C7812D1D1 for ; Fri, 20 May 2016 23:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 uo_OPtLnc9fP for ; Fri, 20 May 2016 23:26:59 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3063012D604 for ; Fri, 20 May 2016 23:26:59 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 06D3E7FF93B9 for ; Sat, 21 May 2016 06:26:56 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4L6Qvj0013069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 21 May 2016 06:26:57 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4L6QuHt010256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 21 May 2016 08:26:57 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Sat, 21 May 2016 08:26:57 +0200
From: "Scharf, Michael (Nokia - DE)" 
To: "quic@ietf.org" 
Thread-Topic: QUIC privacy impact
Thread-Index: AQHRsynFCnTysxHU/0GFj3E4WoIavA==
Date: Sat, 21 May 2016 06:26:56 +0000
Message-ID: <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D488612F2FR712WXCHMBA15z_"
MIME-Version: 1.0
Archived-At: 
Subject: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 May 2016 06:27:01 -0000

--_000_655C07320163294895BBADA28372AF5D488612F2FR712WXCHMBA15z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXMgaXQgcGxhbm5lZCB0byBkaXNjdXNzIHBvdGVudGlhbCBwcml2YWN5IGltcGxpY2F0aW9ucyBv
ZiB0aGUg4oCeUVVJQyBjb25uZWN0aW9uIGlkZW50aWZpZXLigJwgKGFsc28gbmFtZWQg4oCcY2xl
YXIgdGV4dCBzdXBlciBjb29raWXigJ0gb24gdGhlIFNQVUQgbGlzdCk/DQoNClRoYW5rcw0KDQpN
aWNoYWVsDQoNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIEVYVCBUZWQgSGFyZGllDQpTZW50OiBTYXR1cmRheSwgTWF5IDE0LCAyMDE2IDE6
MjcgQU0NClRvOiBxdWljQGlldGYub3JnOyBKYW5hIEl5ZW5nYXI7IENocmlzdGlhbiBIdWl0ZW1h
DQpTdWJqZWN0OiBbUVVJQ10gRHJhZnQgY2hhcnRlcg0KDQpIb3dkeSwNCkFzIHBhcnQgb2YgdGhl
IEJvRiBwcmVwYXJhdGlvbiwgd2UgcHV0IHRvZ2V0aGVyIGEgc3RhYiBhdCBhIGRyYWZ0IGNoYXJ0
ZXIuICBJdCdzIGF2YWlsYWJsZSBhcyBodG1sIGFuZCBtYXJrZG93biBvbiBnaXRodWIgYXQ6DQoN
Cmh0dHBzOi8vZ2l0aHViLmNvbS9JRVRGLVFVSUMvQ2hhcnRlcg0KSSd2ZSBhdHRhY2hlZCB0aGUg
SFRNTCB2ZXJzaW9uIGFzIHdlbGwuDQpJdCB3b3VsZCBiZSBncmVhdCB0byBoYXZlIHNvbWUgb2Yg
dGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgYmVmb3JlIHRoZSBCb0YuICBDb21tZW50cyB0byB0
aGUgbGlzdCBvciBpc3N1ZXMvcHVsbCByZXF1ZXN0cyBhdCB0aGUgZ2l0aHViIHJlcG8gYXJlIHdl
bGNvbWUuICBXZSB3aWxsIHBlcmlvZGljYWxseSByZWZsZWN0IGFueSBpc3N1ZXMgb3Igc3VnZ2Vz
dGlvbiBmcm9tIHRoZSBSZXBvIGJhY2sgdG8gdGhlIGxpc3QsIGJ1dCB0aGlzIHdpbGwgYmUgbWFu
dWFsLCBzbyBleHBlY3Qgc29tZSBsYWcuDQoNCnJlZ2FyZHMsDQpUZWQNCg==

--_000_655C07320163294895BBADA28372AF5D488612F2FR712WXCHMBA15z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u
RS1NYWlsRm9ybWF0dm9ybGFnZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg
NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklzIGl0IHBs
YW5uZWQgdG8gZGlzY3VzcyBwb3RlbnRpYWwgcHJpdmFjeSBpbXBsaWNhdGlvbnMgb2YgdGhlIOKA
nlFVSUMgY29ubmVjdGlvbiBpZGVudGlmaWVy4oCcIChhbHNvIG5hbWVkIOKAnGNsZWFyIHRleHQg
c3VwZXIgY29va2ll4oCdIG9uIHRoZSBTUFVEIGxpc3QpPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
TWljaGFlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv
Yj5FWFQgVGVkIEhhcmRpZTxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWF5IDE0LCAyMDE2
IDE6MjcgQU08YnI+DQo8Yj5Ubzo8L2I+IHF1aWNAaWV0Zi5vcmc7IEphbmEgSXllbmdhcjsgQ2hy
aXN0aWFuIEh1aXRlbWE8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1FVSUNdIERyYWZ0IGNoYXJ0ZXI8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SG93
ZHksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjEyLjBwdCI+QXMgcGFydCBvZiB0aGUgQm9GIHByZXBhcmF0aW9uLCB3ZSBw
dXQgdG9nZXRoZXIgYSBzdGFiIGF0IGEgZHJhZnQgY2hhcnRlci4mbmJzcDsgSXQncyBhdmFpbGFi
bGUgYXMgaHRtbCBhbmQgbWFya2Rvd24gb24gZ2l0aHViIGF0Ojxicj4NCjxicj4NCjxhIGhyZWY9
Imh0dHBzOi8vZ2l0aHViLmNvbS9JRVRGLVFVSUMvQ2hhcnRlciI+aHR0cHM6Ly9naXRodWIuY29t
L0lFVEYtUVVJQy9DaGFydGVyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkndmUgYXR0YWNoZWQgdGhl
IEhUTUwgdmVyc2lvbiBhcyB3ZWxsLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCBiZSBncmVhdCB0byBoYXZlIHNvbWUg
b2YgdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgYmVmb3JlIHRoZSBCb0YuJm5ic3A7IENvbW1l
bnRzIHRvIHRoZSBsaXN0IG9yIGlzc3Vlcy9wdWxsIHJlcXVlc3RzIGF0IHRoZSBnaXRodWIgcmVw
byBhcmUgd2VsY29tZS4mbmJzcDsgV2Ugd2lsbCBwZXJpb2RpY2FsbHkgcmVmbGVjdCBhbnkgaXNz
dWVzIG9yIHN1Z2dlc3Rpb24gZnJvbSB0aGUgUmVwbyBiYWNrIHRvIHRoZQ0KIGxpc3QsIGJ1dCB0
aGlzIHdpbGwgYmUgbWFudWFsLCBzbyBleHBlY3Qgc29tZSBsYWcuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij5yZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U
ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_655C07320163294895BBADA28372AF5D488612F2FR712WXCHMBA15z_--


From nobody Sat May 21 06:56:04 2016
Return-Path: 
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 E1BFF12D0CB for ; Sat, 21 May 2016 06:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 rncdf37USU63 for ; Sat, 21 May 2016 06:56:01 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 BCA4412D0C9 for ; Sat, 21 May 2016 06:56:00 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id v200so18186867wmv.0 for ; Sat, 21 May 2016 06:56:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eaU6H5Oi7KrBwsPzfPJ2B90SZyZEIAZb7QjgfZS2NEg=; b=Q1Dv2wYyCCgEHjgobKiRsnjV63fxY+5iXq0f3U29v2J1EezYqAQ1EH6BO/aXFIpZ6r H/1j23Cfyyv6dp0tCtDg3gvjUBoJ7QQE8zO5fC7V/TmCz+6LY0z5e5792GefpAdb54tl NG8x6R1Yn7xDKlxrojYDfcIkskl5yQqveW7ZRNr57zBMZGXJQsQm2vNVZlfB5dFxpTMq FPnGxhfMYBg7neBXCIkUKiTzFPcklpWRmP5cPDnSvs1W70u3oR1MzeLVhPZRItBZImwY s4R9JIvZmdsOUjnuED8dG3XeRK2v0CBMq+Xoe6bD+IfFM9M1MSBrY3mttwwJ2cS21LCq C8Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eaU6H5Oi7KrBwsPzfPJ2B90SZyZEIAZb7QjgfZS2NEg=; b=eXylQ7+19kiw0F3Z89NqSA1fVCVWg9P6aFlTn9lH3WDuz7/C1jxBE2HHcnV+LLz/GH 0gNXqgcMgTPszTQgknrZzzE96sBVliu8u0Oisvf5AMqHY/Qpdg/14QABHLa1Ni65B9wD EeCTdT67UMEhu68ZQSVL7eHavcjXUd4p/MsyiAI/5JKB1XJncZFn+LJFjGYPSrXbVWe6 f/Ei0eS9jX0diU7CXSEOdrMRNrvn0moJUP25pof3zdmgSFLvZhFHT3t2sAd+NgiMmwTr gNYz4Uh7FgdPBP/cib8TbwJxIY5AcWpTbH2gdNK8f8dt2RDV80JL1tQlIBLcI8fE2Lbf xPog==
X-Gm-Message-State: AOPr4FVjeVLMeNoZLKgGQfy6Qjh8QUjrRHmA1EOE3drJe+5l/qw6aPxlhh4/VoOzwV6m2MShh5YuC+QkJEY0KsFL
X-Received: by 10.28.143.11 with SMTP id r11mr9163577wmd.46.1463838959186; Sat, 21 May 2016 06:55:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.46.151 with HTTP; Sat, 21 May 2016 06:55:56 -0700 (PDT)
In-Reply-To: <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>
From: Ryan Hamilton 
Date: Sat, 21 May 2016 06:55:56 -0700
Message-ID: 
To: "Scharf, Michael (Nokia - DE)" 
Content-Type: multipart/alternative; boundary=001a11469bd82c004c05335a912d
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 May 2016 13:56:03 -0000

--001a11469bd82c004c05335a912d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Definitely.

On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) <
michael.scharf@nokia.com> wrote:

> Is it planned to discuss potential privacy implications of the =E2=80=9EQ=
UIC
> connection identifier=E2=80=9C (also named =E2=80=9Cclear text super cook=
ie=E2=80=9D on the SPUD
> list)?
>
>
>
> Thanks
>
>
>
> Michael
>
>
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *EXT Ted Hardie
> *Sent:* Saturday, May 14, 2016 1:27 AM
> *To:* quic@ietf.org; Jana Iyengar; Christian Huitema
> *Subject:* [QUIC] Draft charter
>
>
>
> Howdy,
>
> As part of the BoF preparation, we put together a stab at a draft
> charter.  It's available as html and markdown on github at:
>
> https://github.com/IETF-QUIC/Charter
>
> I've attached the HTML version as well.
>
> It would be great to have some of the discussion on the list before the
> BoF.  Comments to the list or issues/pull requests at the github repo are
> welcome.  We will periodically reflect any issues or suggestion from the
> Repo back to the list, but this will be manual, so expect some lag.
>
>
>
> regards,
>
> Ted
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>

--001a11469bd82c004c05335a912d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Definitely.

On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (N=
okia - DE) <michael.scharf@nokia.com> wrote:











Is it plan=
ned to discuss potential privacy implications of the =E2=80=9EQUIC connecti=
on identifier=E2=80=9C (also named =E2=80=9Cclear text super cookie=E2=80=
=9D on the SPUD list)?


=C2=
=A0


Thanks<=
/u>


=C2=
=A0


Michael=



=C2=
=A0


=C2=
=A0








From: QUIC [ma=
ilto:quic-bounce=
s@ietf.org]
On Behalf Of EXT Ted Hardie

Sent: Saturday, May 14, 2016 1:27 AM

To: quic@ietf.org=
; Jana Iyengar; Christian Huitema

Subject: [QUIC] Draft charter






=C2=A0












Howdy,<=
/p>



As part of the BoF pr=
eparation, we put together a stab at a draft charter.=C2=A0 It's availa=
ble as html and markdown on github at:



https://=
github.com/IETF-QUIC/Charter




I've attached the=
 HTML version as well.=C2=A0







It would be great to have some of the discussion on =
the list before the BoF.=C2=A0 Comments to the list or issues/pull requests=
 at the github repo are welcome.=C2=A0 We will periodically reflect any iss=
ues or suggestion from the Repo back to the
 list, but this will be manual, so expect some lag.






=C2=A0




regards,




Ted











_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--001a11469bd82c004c05335a912d--


From nobody Sat May 21 09:04:49 2016
Return-Path: 
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 93FBD12B018 for ; Sat, 21 May 2016 09:04:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 UKdcF8f0njLu for ; Sat, 21 May 2016 09:04:46 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 511EB12B059 for ; Sat, 21 May 2016 09:04:46 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id c127so18879306ywb.1 for ; Sat, 21 May 2016 09:04:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=HJLerf+76W3Vuk/8Spzw21ZNipcl7qrWHJAdGCJ38XY=; b=ICicR3tV4MRyfgR/8tZ/G/Dnt1WQGDXB8wEqtc4Ar+jgCLOYBc/yj7igU28dGeZ0Kw uzCdgiWRj83yBP1RmBPN+bxLIxe21ONNz0MNos53r2wfY/nc6KaS8AXqKoHnB0SXfL5o Ls+aBsVcmoArxzJ27j/ZJewEPQUr3WldSYNHpDFMdAmsmJb7/RS4ONohFjlzbk2T+YkM RrvN/xWGVzF6dLvPnniWfw97WwNR2SmPggRX5L8HQt6wv9UyUmzYSqB7myeFmP2bPrnq kPbMDus6M9SU2FviJId9ESpZvrESWojXH1IQufc9STbnyAMzb1bpjtjxZKssYPhJs6kZ HJqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=HJLerf+76W3Vuk/8Spzw21ZNipcl7qrWHJAdGCJ38XY=; b=EgYms03Io+xfJ3Onj9HU4Nio+/JbHT+l0uXWdgOGbqVvYgDNspQvmP4OwqOsoRyPbY EiC+XfjhrV/ZhKTC3ylNH7ZWjMjlzEcQOhvnHkR1yh8qgGlYh9GF3htGeYhduLa3Ig40 RXzsV29wsYWfeTQLnhkcw3IUy+tokaxOSv/EQzvNgCmSvzAG8eA7frOF7lhhFxoPc667 b9plVpI2NJ23XiUarU4egJIH9qYbRi4rx2HdOXAsgR2OOLV/AEMuR52BtKyY09xGMekq rMl/YcggBMKC24hXqqSWJ8KFhZBkuYLgT6k4v7MVBmwZBsQovJUVqJOoUPBH3qQgbejC 8PtA==
X-Gm-Message-State: AOPr4FWi7YOZjtZ58eO3htzc/8os919QZ8D64yxMb3rbfsTkziabzLvA+ys31p6gsoKJ6dkTnuRa2Lz+swn5KRKy
MIME-Version: 1.0
X-Received: by 10.13.198.197 with SMTP id i188mr4810864ywd.207.1463846685004;  Sat, 21 May 2016 09:04:45 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Sat, 21 May 2016 09:04:44 -0700 (PDT)
Received: by 10.37.221.193 with HTTP; Sat, 21 May 2016 09:04:44 -0700 (PDT)
In-Reply-To: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com> 
Date: Sat, 21 May 2016 09:04:44 -0700
Message-ID: 
From: Jana Iyengar 
To: Ryan Hamilton 
Content-Type: multipart/alternative; boundary=001a114d6f74aab3b805335c5ddc
Archived-At: 
Cc: "Scharf, Michael \(Nokia - DE\)" , quic@ietf.org
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 May 2016 16:04:48 -0000

--001a114d6f74aab3b805335c5ddc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

That's a design element that should and will definitely be discussed in the
WG.

Specifically this applies to use of connection IDs during multipath, and I
expect that conversation to happen when we discuss multipath.
On May 21, 2016 6:56 AM, "Ryan Hamilton"  wrote:

> Definitely.
>
> On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) <
> michael.scharf@nokia.com> wrote:
>
>> Is it planned to discuss potential privacy implications of the =E2=80=9E=
QUIC
>> connection identifier=E2=80=9C (also named =E2=80=9Cclear text super coo=
kie=E2=80=9D on the SPUD
>> list)?
>>
>>
>>
>> Thanks
>>
>>
>>
>> Michael
>>
>>
>>
>>
>>
>> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *EXT Ted Hardi=
e
>> *Sent:* Saturday, May 14, 2016 1:27 AM
>> *To:* quic@ietf.org; Jana Iyengar; Christian Huitema
>> *Subject:* [QUIC] Draft charter
>>
>>
>>
>> Howdy,
>>
>> As part of the BoF preparation, we put together a stab at a draft
>> charter.  It's available as html and markdown on github at:
>>
>> https://github.com/IETF-QUIC/Charter
>>
>> I've attached the HTML version as well.
>>
>> It would be great to have some of the discussion on the list before the
>> BoF.  Comments to the list or issues/pull requests at the github repo ar=
e
>> welcome.  We will periodically reflect any issues or suggestion from the
>> Repo back to the list, but this will be manual, so expect some lag.
>>
>>
>>
>> regards,
>>
>> Ted
>>
>> _______________________________________________
>> QUIC mailing list
>> QUIC@ietf.org
>> https://www.ietf.org/mailman/listinfo/quic
>>
>>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>

--001a114d6f74aab3b805335c5ddc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


That's a design element that should and will definitely =
be discussed in the WG.


Specifically this applies to use of connection IDs during mu=
ltipath, and I expect that conversation to happen when we discuss multipath=
.


On May 21, 2016 6:56 AM, "Ryan Hamilton&quo=
t; <rch@google.com> wrote:
Definit=
ely.

O=
n Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) <mich=
ael.scharf@nokia.com> wrote:




Is it plan=
ned to discuss potential privacy implications of the =E2=80=9EQUIC connecti=
on identifier=E2=80=9C (also named =E2=80=9Cclear text super cookie=E2=80=
=9D on the SPUD list)?


=C2=
=A0


Thanks<=
/u>


=C2=
=A0


Michael=



=C2=
=A0


=C2=
=A0








From: QUIC [ma=
ilto:quic-bounce=
s@ietf.org]
On Behalf Of EXT Ted Hardie

Sent: Saturday, May 14, 2016 1:27 AM

To: quic@ietf.org=
; Jana Iyengar; Christian Huitema

Subject: [QUIC] Draft charter






=C2=A0












Howdy,<=
/p>



As part of the BoF pr=
eparation, we put together a stab at a draft charter.=C2=A0 It's availa=
ble as html and markdown on github at:



https://=
github.com/IETF-QUIC/Charter




I've attached the=
 HTML version as well.=C2=A0







It would be great to have some of the discussion on =
the list before the BoF.=C2=A0 Comments to the list or issues/pull requests=
 at the github repo are welcome.=C2=A0 We will periodically reflect any iss=
ues or suggestion from the Repo back to the
 list, but this will be manual, so expect some lag.






=C2=A0




regards,




Ted











_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic




--001a114d6f74aab3b805335c5ddc--


From nobody Sat May 21 20:20:22 2016
Return-Path: 
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 8FE0912B054 for ; Sat, 21 May 2016 20:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 qyHCcyfsptSL for ; Sat, 21 May 2016 20:20:19 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 A681A12B005 for ; Sat, 21 May 2016 20:20:19 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id c127so26402518ywb.1 for ; Sat, 21 May 2016 20:20:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VEMiBLLfPjnTEvdssjjQBR5Odb98Kk9Fhps69+dr/hs=; b=ipsDKiZYBnkssPjdryrYWrI3patOgcxWnFEKm2mD7j+36qQl+dbZVb+EjSIhtJp8JC nj1fiO04pWXK4zsxL8a5llHs/eznynDnWIoXPAwZzCMwqJWHGvfcXPNKDaFsEGWRN1ke 8SswKEBvK+Noe+cerQO+r5mDOwabsDNmLeiHMkZN56Hi9llXNqcst0u97DG+271B3mWf 3ImUdxvq1xhMoWfp7aoDNP6ypoFFmyyv2XJZW0aiupHftE10NVJdLpbUKqeGytV9jYlI 5Hfhxf4DqS8vTqoyPR5XCsINrmsMf3DMhY/nUCOiW7BDIeZzFGS+kAkUCxfJ1yVJeeKb PkXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VEMiBLLfPjnTEvdssjjQBR5Odb98Kk9Fhps69+dr/hs=; b=aDREmi1KzxhSDnqAPZeSC9PMezAU7WNfDphM45cgARBXZQMbY27sGJN1kljcoyTPH7 3NMyAhqEqSAtrbA5Gtp4PBiDZuimu+t7es2HhFPsRYXw3+j1/wCI0av2JSSYVcwztxpE 20SmiUgLj6V8lLrOBcvRY3GMagEkQJ8kcKCeBEHUMrDNmh1oziDRfX9+o5DNON2FhX+0 hXiz/HsxPDIU29yPDmR2LY/ZOVk9Tb2nGj3iPRH9A7lloEazZruvZBN7UvJmcMCS87TR m8rJcRTUArp7zyXrevkg+gvvrOZCOlxw5hsx6NvoVbwjDheA7WflFVw+xR/lfoiJ2/yO 2YuQ==
X-Gm-Message-State: AOPr4FU1a4TmSK/7wcmQOI20ocxc68w+swDyl1+cb1dxILfS21WPC2LRw+fEvmabqDB99InigQSGb72bEVsrHV0Q
X-Received: by 10.13.237.1 with SMTP id w1mr5921065ywe.62.1463887218662; Sat, 21 May 2016 20:20:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Sat, 21 May 2016 20:20:18 -0700 (PDT)
In-Reply-To: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>  
From: Jana Iyengar 
Date: Sat, 21 May 2016 20:20:18 -0700
Message-ID: 
To: Ryan Hamilton 
Content-Type: multipart/alternative; boundary=94eb2c0864a8a95471053365cdb5
Archived-At: 
Cc: "Scharf, Michael \(Nokia - DE\)" , quic@ietf.org
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 May 2016 03:20:21 -0000

--94eb2c0864a8a95471053365cdb5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Michael,

Just caught up on the SPUD thread, and I'd like to correct something you
said there that I'll quote here for context:
*"if there is now a new clear text identifier that just happens to be
unique per subscriber. What a great improvement for privacy in the
Internet! And even better that it seems compatible with QUIC..."*

QUIC's connection ID is NOT unique per subscriber. It's per connection. As
I said on the other thread, in the single-path case, it reveals no more
informtion than TCP. In the multipath case, it effectively reveals no more
than MPTCP, since the ID is used to tie the multiple, using MPTCP
parlance, "sub-flows", together. It is possible to consider a different
design that uses multiple connection IDs for the multiple sub-flows, but to
be clear, that makes this new multipath strictly better than MPTCP at
privacy-preservation.

At any rate, I wanted to make sure that we're talking about the same issue.
I'll also note that it's plain wrong to use the term "clear text super
cookie" in relation to the QUIC connection ID (see
https://www.techopedia.com/definition/27310/super-cookie for what I think a
supercookie is.)

- jana

On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar  wrote:

> That's a design element that should and will definitely be discussed in
> the WG.
>
> Specifically this applies to use of connection IDs during multipath, and =
I
> expect that conversation to happen when we discuss multipath.
> On May 21, 2016 6:56 AM, "Ryan Hamilton"  wrote:
>
>> Definitely.
>>
>> On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) <
>> michael.scharf@nokia.com> wrote:
>>
>>> Is it planned to discuss potential privacy implications of the =E2=80=
=9EQUIC
>>> connection identifier=E2=80=9C (also named =E2=80=9Cclear text super co=
okie=E2=80=9D on the SPUD
>>> list)?
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Michael
>>>
>>>
>>>
>>>
>>>
>>> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *EXT Ted
>>> Hardie
>>> *Sent:* Saturday, May 14, 2016 1:27 AM
>>> *To:* quic@ietf.org; Jana Iyengar; Christian Huitema
>>> *Subject:* [QUIC] Draft charter
>>>
>>>
>>>
>>> Howdy,
>>>
>>> As part of the BoF preparation, we put together a stab at a draft
>>> charter.  It's available as html and markdown on github at:
>>>
>>> https://github.com/IETF-QUIC/Charter
>>>
>>> I've attached the HTML version as well.
>>>
>>> It would be great to have some of the discussion on the list before the
>>> BoF.  Comments to the list or issues/pull requests at the github repo a=
re
>>> welcome.  We will periodically reflect any issues or suggestion from th=
e
>>> Repo back to the list, but this will be manual, so expect some lag.
>>>
>>>
>>>
>>> regards,
>>>
>>> Ted
>>>
>>> _______________________________________________
>>> QUIC mailing list
>>> QUIC@ietf.org
>>> https://www.ietf.org/mailman/listinfo/quic
>>>
>>>
>>
>> _______________________________________________
>> QUIC mailing list
>> QUIC@ietf.org
>> https://www.ietf.org/mailman/listinfo/quic
>>
>>

--94eb2c0864a8a95471053365cdb5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Michael,

Just caught up on the SP=
UD thread, and I'd like to correct something you said there that I'=
ll quote here for context:=C2=A0
"if there is now a new clear t=
ext identifier that just happens to be unique per subscriber. What a great =
improvement for privacy in the Internet! And even better that it seems comp=
atible with QUIC..."

QUIC's conne=
ction ID is NOT unique per subscriber. It's per connection. As I said o=
n the other thread, in the single-path case, it reveals no more informtion =
than TCP. In the multipath case, it effectively reveals no more than MPTCP,=
 since the ID is used to tie the multiple, using MPTCP parlance,=C2=A0"=
;sub-flows", together. It is possible to consider a different design t=
hat uses multiple connection IDs for the multiple sub-flows, but to be clea=
r, that makes this new multipath strictly better than MPTCP=C2=A0at privacy=
-preservation.

At any rate, I wanted to make sure =
that we're talking about the same issue. I'll also note that it'=
;s plain wrong to use the term "clear text super cookie" in relat=
ion to the QUIC connection ID (see=C2=A0https://www.techopedia.com/definition/273=
10/super-cookie=C2=A0for what I think a supercookie is.)

=

- jana

On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar <jri@google.com=
> wrote:
That=
9;s a design element that should and will definitely be discussed in the WG=
.


Specifically this applies to use of connection IDs during mu=
ltipath, and I expect that conversation to happen when we discuss multipath=
.


On May 21, 2016 6:56 AM, "Ryan Hamilton&quo=
t; <rch@google.com> wrote:
Definitely.

On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia -=
 DE) <michael.scharf@nokia.com> wrote:











Is it plan=
ned to discuss potential privacy implications of the =E2=80=9EQUIC connecti=
on identifier=E2=80=9C (also named =E2=80=9Cclear text super cookie=E2=80=
=9D on the SPUD list)?


=C2=
=A0


Thanks<=
/u>


=C2=
=A0


Michael=



=C2=
=A0


=C2=
=A0








From: QUIC [ma=
ilto:quic-bounce=
s@ietf.org]
On Behalf Of EXT Ted Hardie

Sent: Saturday, May 14, 2016 1:27 AM

To: quic@ietf.org=
; Jana Iyengar; Christian Huitema

Subject: [QUIC] Draft charter






=C2=A0












Howdy,<=
/p>



As part of the BoF pr=
eparation, we put together a stab at a draft charter.=C2=A0 It's availa=
ble as html and markdown on github at:



https://=
github.com/IETF-QUIC/Charter




I've attached the=
 HTML version as well.=C2=A0







It would be great to have some of the discussion on =
the list before the BoF.=C2=A0 Comments to the list or issues/pull requests=
 at the github repo are welcome.=C2=A0 We will periodically reflect any iss=
ues or suggestion from the Repo back to the
 list, but this will be manual, so expect some lag.






=C2=A0




regards,




Ted











_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic







--94eb2c0864a8a95471053365cdb5--


From nobody Sat May 21 20:44:31 2016
Return-Path: 
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 345BC12D0CE for ; Sat, 21 May 2016 20:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=microsoft.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 Jw4Xs4KuGeQf for ; Sat, 21 May 2016 20:44:27 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5718212B054 for ; Sat, 21 May 2016 20:44:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IlarKQUEUs4UNeFBF7HTn/U3XosENMxfyYuzyU+/FTM=; b=VDcKhsTxLDfce+RWlzbBnA3yGH/g2xR8on96/Uf9lgrcKNQw9GlY6qMiRmXj7sL5WWfQZUcEmcc37cxSy3CxhMWngLAYuqInG/FFzxInIpenhjNVM7bFOSIxVnYqcqU0ZyiFVQFI0bzK7x46KQ4uaCB9xfaIwRfKLipB5XPkzLU=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.497.12; Sun, 22 May 2016 03:44:05 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0492.020; Sun, 22 May 2016 03:44:05 +0000
From: Christian Huitema 
To: Jana Iyengar , Ryan Hamilton 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynMN6GVCYzd10uovw2jcGWCDZ/DaqoAgAAj/QCAALzAAIAAAxrA
Date: Sun, 22 May 2016 03:44:04 +0000
Message-ID: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [72.235.151.78]
x-ms-office365-filtering-correlation-id: 54bbe2c2-2a28-4aaf-617d-08d381f3529a
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:tnSRk3V5H8l6oF/JSJRxPnAiO6UAhqxD2Hk3QmDeuH6Rr/va6Sn+j3KEYnQR14k7jvJwRrTNor9z99i6jVmylNZipe5Vl1WNRCozpvLPrpzpV+W9QdUVp1hft7suL4ptVJdy3xRiIJS5D1ErMwpJUg==; 24:K9lfKKGJvykJ22xdZ8d/gkUxRGuoD9K98Ba47TNPJHhn4VXmn+VnTepleKMU2yylGrrcqbeZ1EPHuq4MIUVzQGCdJhLDFQ2Q3W2VRBE8sFw=; 7:WVHAXDz/35jOY93nA71SnhBhIKWmi5OoH93ZaZeImdXIcWYFRViu+WoLryjYTJ7Tj+1hezlcLr2PyGO0Dcxq6uZti3vfe3Qy5TJHiprFrq8YO7gBFwtEoQdqFGtUX0L5VFq/k/BbeIzf09D0esYbZkKNIfyQhHfkj7veFtG9LxJSX5lQIowKlPKwU+FBYuaFR4wIXQZyPSjz0aEcVxfgxg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; 
x-forefront-prvs: 0950706AC1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(122556002)(189998001)(3660700001)(19617315012)(3280700002)(106116001)(76576001)(50986999)(15975445007)(2900100001)(2950100001)(86612001)(77096005)(92566002)(5001770100001)(9686002)(19300405004)(86362001)(1220700001)(586003)(99286002)(5008740100001)(2906002)(790700001)(6116002)(102836003)(3846002)(74316001)(8990500004)(19580395003)(19580405001)(5003600100002)(8676002)(8936002)(5002640100001)(93886004)(66066001)(5890100001)(76176999)(19625215002)(16236675004)(54356999)(87936001)(11100500001)(33656002)(10400500002)(10290500002)(81166006)(5005710100001)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB06559A2FD42A3E4CB1E5AB7EA84D0DM2PR0301MB0655_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2016 03:44:04.9600 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653
Archived-At: 
Cc: "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 May 2016 03:44:30 -0000

--_000_DM2PR0301MB06559A2FD42A3E4CB1E5AB7EA84D0DM2PR0301MB0655_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SnVzdCB0byBiZSBjbGVhciwgSSBkaWQgdXNlIHRoZSB0ZXJtIOKAnHN1cGVyIGNvb2tpZeKAnSBp
biB0aGUgY29udGV4dCBvZiBtdWx0aS1wYXRoIGFuZCBtb2JpbGl0eS4gVGhhdCB3YXMgdHJpZ2dl
cmVkIGJ5IHRoZSBTUFVEIGRpc2N1c3Npb24sIGR1cmluZyB3aGljaCBhIHByb3Bvc2l0aW9uIHN1
cmZhY2VkIHRvIHVzZSBhIFFVSUMtbGlrZSBjb25uZWN0aW9uIElEIGZvciBtb2JpbGl0eSBhbmQg
bXVsdGlwYXRoLCBhbmQgdG8gc3RhbmRhcmRpemUgdGhhdCBhcyBwYXJ0IG9mIHRoZSBTUFVEIGhl
YWRlci4gSSB0aGluayB1c2luZyB0aGUgc2FtZSBzdGF0aXN0aWNhbGx5IHVuaXF1ZSA2NC1iaXQg
bnVtYmVyIGluIHRoZSBjbGVhciB0ZXh0IGVudmVsb3BlIG9mIHBhY2tldHMgc2VudCBmcm9tIGRp
ZmZlcmVudCBJUCBhZGRyZXNzZXMgaXMgYSByZWFsbHkgYmFkIGlkZWEuIEl0IGlzIGEgYmFkIGlk
ZWEgZm9yIE1QLVRDUCwgYW5kIGl0IHdvdWxkIGJlIGJhZCBpZGVhIGZvciBRVUlDIG9yIFNQVUQu
DQoNCkkgZG8gYWdyZWUgd2l0aCBKYW5hIGFuZCBSeWFuIHRoYXQgdGhlcmUgaXMgbm8gc3VjaCBw
cm9ibGVtIGlmIHRoZSB1bmlxdWUgbnVtYmVyIGlzIG9ubHkgdXNlZCBmb3IgYSBzaW5nbGUgcGFp
ciBvZiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGFkZHJlc3Nlcy4gQW5kIEkgYWxzbyBhZ3JlZSB0
aGF0IHRoZSBwcm9wZXIgdGltZSB0byBzdHVkeSBwcml2YWN5LXByZXNlcnZpbmcgbXVsdGlwYXRo
IG1lY2hhbmlzbXMgaXMgZHVyaW5nIHRoZSBzdHVkeSBvZiBtdWx0aXBhdGguDQoNCi0tIENocmlz
dGlhbiBIdWl0ZW1hDQoNCg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu
b3JnXSBPbiBCZWhhbGYgT2YgSmFuYSBJeWVuZ2FyDQpTZW50OiBTYXR1cmRheSwgTWF5IDIxLCAy
MDE2IDU6MjAgUE0NClRvOiBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNvbT4NCkNjOiBTY2hh
cmYsIE1pY2hhZWwgKE5va2lhIC0gREUpIDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+OyBxdWlj
QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1FVSUNdIFFVSUMgcHJpdmFjeSBpbXBhY3QNCg0KTWlj
aGFlbCwNCg0KSnVzdCBjYXVnaHQgdXAgb24gdGhlIFNQVUQgdGhyZWFkLCBhbmQgSSdkIGxpa2Ug
dG8gY29ycmVjdCBzb21ldGhpbmcgeW91IHNhaWQgdGhlcmUgdGhhdCBJJ2xsIHF1b3RlIGhlcmUg
Zm9yIGNvbnRleHQ6DQoiaWYgdGhlcmUgaXMgbm93IGEgbmV3IGNsZWFyIHRleHQgaWRlbnRpZmll
ciB0aGF0IGp1c3QgaGFwcGVucyB0byBiZSB1bmlxdWUgcGVyIHN1YnNjcmliZXIuIFdoYXQgYSBn
cmVhdCBpbXByb3ZlbWVudCBmb3IgcHJpdmFjeSBpbiB0aGUgSW50ZXJuZXQhIEFuZCBldmVuIGJl
dHRlciB0aGF0IGl0IHNlZW1zIGNvbXBhdGlibGUgd2l0aCBRVUlDLi4uIg0KDQpRVUlDJ3MgY29u
bmVjdGlvbiBJRCBpcyBOT1QgdW5pcXVlIHBlciBzdWJzY3JpYmVyLiBJdCdzIHBlciBjb25uZWN0
aW9uLiBBcyBJIHNhaWQgb24gdGhlIG90aGVyIHRocmVhZCwgaW4gdGhlIHNpbmdsZS1wYXRoIGNh
c2UsIGl0IHJldmVhbHMgbm8gbW9yZSBpbmZvcm10aW9uIHRoYW4gVENQLiBJbiB0aGUgbXVsdGlw
YXRoIGNhc2UsIGl0IGVmZmVjdGl2ZWx5IHJldmVhbHMgbm8gbW9yZSB0aGFuIE1QVENQLCBzaW5j
ZSB0aGUgSUQgaXMgdXNlZCB0byB0aWUgdGhlIG11bHRpcGxlLCB1c2luZyBNUFRDUCBwYXJsYW5j
ZSwgInN1Yi1mbG93cyIsIHRvZ2V0aGVyLiBJdCBpcyBwb3NzaWJsZSB0byBjb25zaWRlciBhIGRp
ZmZlcmVudCBkZXNpZ24gdGhhdCB1c2VzIG11bHRpcGxlIGNvbm5lY3Rpb24gSURzIGZvciB0aGUg
bXVsdGlwbGUgc3ViLWZsb3dzLCBidXQgdG8gYmUgY2xlYXIsIHRoYXQgbWFrZXMgdGhpcyBuZXcg
bXVsdGlwYXRoIHN0cmljdGx5IGJldHRlciB0aGFuIE1QVENQIGF0IHByaXZhY3ktcHJlc2VydmF0
aW9uLg0KDQpBdCBhbnkgcmF0ZSwgSSB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoYXQgd2UncmUgdGFs
a2luZyBhYm91dCB0aGUgc2FtZSBpc3N1ZS4gSSdsbCBhbHNvIG5vdGUgdGhhdCBpdCdzIHBsYWlu
IHdyb25nIHRvIHVzZSB0aGUgdGVybSAiY2xlYXIgdGV4dCBzdXBlciBjb29raWUiIGluIHJlbGF0
aW9uIHRvIHRoZSBRVUlDIGNvbm5lY3Rpb24gSUQgKHNlZSBodHRwczovL3d3dy50ZWNob3BlZGlh
LmNvbS9kZWZpbml0aW9uLzI3MzEwL3N1cGVyLWNvb2tpZSBmb3Igd2hhdCBJIHRoaW5rIGEgc3Vw
ZXJjb29raWUgaXMuKQ0KDQotIGphbmENCg0KT24gU2F0LCBNYXkgMjEsIDIwMTYgYXQgOTowNCBB
TSwgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbTxtYWlsdG86anJpQGdvb2dsZS5jb20+PiB3
cm90ZToNCg0KVGhhdCdzIGEgZGVzaWduIGVsZW1lbnQgdGhhdCBzaG91bGQgYW5kIHdpbGwgZGVm
aW5pdGVseSBiZSBkaXNjdXNzZWQgaW4gdGhlIFdHLg0KDQpTcGVjaWZpY2FsbHkgdGhpcyBhcHBs
aWVzIHRvIHVzZSBvZiBjb25uZWN0aW9uIElEcyBkdXJpbmcgbXVsdGlwYXRoLCBhbmQgSSBleHBl
Y3QgdGhhdCBjb252ZXJzYXRpb24gdG8gaGFwcGVuIHdoZW4gd2UgZGlzY3VzcyBtdWx0aXBhdGgu
DQpPbiBNYXkgMjEsIDIwMTYgNjo1NiBBTSwgIlJ5YW4gSGFtaWx0b24iIDxyY2hAZ29vZ2xlLmNv
bTxtYWlsdG86cmNoQGdvb2dsZS5jb20+PiB3cm90ZToNCkRlZmluaXRlbHkuDQoNCk9uIEZyaSwg
TWF5IDIwLCAyMDE2IGF0IDExOjI2IFBNLCBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpIDxt
aWNoYWVsLnNjaGFyZkBub2tpYS5jb208bWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT4+
IHdyb3RlOg0KSXMgaXQgcGxhbm5lZCB0byBkaXNjdXNzIHBvdGVudGlhbCBwcml2YWN5IGltcGxp
Y2F0aW9ucyBvZiB0aGUg4oCeUVVJQyBjb25uZWN0aW9uIGlkZW50aWZpZXLigJwgKGFsc28gbmFt
ZWQg4oCcY2xlYXIgdGV4dCBzdXBlciBjb29raWXigJ0gb24gdGhlIFNQVUQgbGlzdCk/DQoNClRo
YW5rcw0KDQpNaWNoYWVsDQoNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm
Lm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEVYVCBUZWQg
SGFyZGllDQpTZW50OiBTYXR1cmRheSwgTWF5IDE0LCAyMDE2IDE6MjcgQU0NClRvOiBxdWljQGll
dGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPjsgSmFuYSBJeWVuZ2FyOyBDaHJpc3RpYW4gSHVp
dGVtYQ0KU3ViamVjdDogW1FVSUNdIERyYWZ0IGNoYXJ0ZXINCg0KSG93ZHksDQpBcyBwYXJ0IG9m
IHRoZSBCb0YgcHJlcGFyYXRpb24sIHdlIHB1dCB0b2dldGhlciBhIHN0YWIgYXQgYSBkcmFmdCBj
aGFydGVyLiAgSXQncyBhdmFpbGFibGUgYXMgaHRtbCBhbmQgbWFya2Rvd24gb24gZ2l0aHViIGF0
Og0KDQpodHRwczovL2dpdGh1Yi5jb20vSUVURi1RVUlDL0NoYXJ0ZXINCkkndmUgYXR0YWNoZWQg
dGhlIEhUTUwgdmVyc2lvbiBhcyB3ZWxsLg0KSXQgd291bGQgYmUgZ3JlYXQgdG8gaGF2ZSBzb21l
IG9mIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGJlZm9yZSB0aGUgQm9GLiAgQ29tbWVudHMg
dG8gdGhlIGxpc3Qgb3IgaXNzdWVzL3B1bGwgcmVxdWVzdHMgYXQgdGhlIGdpdGh1YiByZXBvIGFy
ZSB3ZWxjb21lLiAgV2Ugd2lsbCBwZXJpb2RpY2FsbHkgcmVmbGVjdCBhbnkgaXNzdWVzIG9yIHN1
Z2dlc3Rpb24gZnJvbSB0aGUgUmVwbyBiYWNrIHRvIHRoZSBsaXN0LCBidXQgdGhpcyB3aWxsIGJl
IG1hbnVhbCwgc28gZXhwZWN0IHNvbWUgbGFnLg0KDQpyZWdhcmRzLA0KVGVkDQoNCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpRVUlDIG1haWxpbmcgbGlz
dA0KUVVJQ0BpZXRmLm9yZzxtYWlsdG86UVVJQ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vcXVpYw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQpRVUlDIG1haWxpbmcgbGlzdA0KUVVJQ0BpZXRmLm9yZzxt
YWlsdG86UVVJQ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vcXVpYw0KDQo=

--_000_DM2PR0301MB06559A2FD42A3E4CB1E5AB7EA84D0DM2PR0301MB0655_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg
Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9
Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p
Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp
c3QueG1sQDAxRDFCMzg4LjVDMTJERkMwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m
ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+
DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVh
bjwvdzpTcGVsbGluZ1N0YXRlPg0KPHc6R3JhbW1hclN0YXRlPkNsZWFuPC93OkdyYW1tYXJTdGF0
ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlz
Lz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxz
ZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Okln
bm9yZU1peGVkQ29udGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6
QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3OkxpZFRo
ZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhlbWVPdGhlcj4NCjx3OkxpZFRoZW1lQXNpYW4+WC1OT05F
PC93OkxpZFRoZW1lQXNpYW4+DQo8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+WC1OT05FPC93Okxp
ZFRoZW1lQ29tcGxleFNjcmlwdD4NCjx3OkNvbXBhdGliaWxpdHk+DQo8dzpEb05vdEV4cGFuZFNo
aWZ0UmV0dXJuLz4NCjx3OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQo8dzpTcGxpdFBnQnJlYWtBbmRQ
YXJhTWFyay8+DQo8dzpFbmFibGVPcGVuVHlwZUtlcm5pbmcvPg0KPC93OkNvbXBhdGliaWxpdHk+
DQo8bTptYXRoUHI+DQo8bTptYXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBNYXRoIi8+DQo8bTpicmtC
aW4gbTp2YWw9ImJlZm9yZSIvPg0KPG06YnJrQmluU3ViIG06dmFsPSImIzQ1Oy0iLz4NCjxtOnNt
YWxsRnJhYyBtOnZhbD0ib2ZmIi8+DQo8bTpkaXNwRGVmLz4NCjxtOmxNYXJnaW4gbTp2YWw9IjAi
Lz4NCjxtOnJNYXJnaW4gbTp2YWw9IjAiLz4NCjxtOmRlZkpjIG06dmFsPSJjZW50ZXJHcm91cCIv
Pg0KPG06d3JhcEluZGVudCBtOnZhbD0iMTQ0MCIvPg0KPG06aW50TGltIG06dmFsPSJzdWJTdXAi
Lz4NCjxtOm5hcnlMaW0gbTp2YWw9InVuZE92ciIvPg0KPC9tOm1hdGhQcj48L3c6V29yZERvY3Vt
ZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8dzpMYXRl
bnRTdHlsZXMgRGVmTG9ja2VkU3RhdGU9ImZhbHNlIiBEZWZVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui
IERlZlNlbWlIaWRkZW49ImZhbHNlIiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJpb3JpdHk9Ijk5
IiBMYXRlbnRTdHlsZUNvdW50PSIzNzEiPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSIwIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJOb3JtYWwiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVh
ZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l
PSJoZWFkaW5nIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
OSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUi
IE5hbWU9ImhlYWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0i
dHJ1ZSIgTmFtZT0iaGVhZGluZyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9y
bWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
IFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIiBOYW1lPSJpbmRleCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDIiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRl
eCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg
VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt
ZT0iaW5kZXggNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA3Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiIE5hbWU9ImluZGV4IDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggOSIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAxIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSIgTmFtZT0idG9jIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO
YW1lPSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIz
OSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA0Ii8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVu
PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDUiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiIE5hbWU9InRvYyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9j
IDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlI
aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIiBOYW1lPSJOb3JtYWwgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3Ru
b3RlIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iYW5ub3RhdGlvbiB0ZXh0Ii8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz
ZWQ9InRydWUiIE5hbWU9ImhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJmb290ZXIiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggaGVhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz
ZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg
TmFtZT0idGFibGUgb2YgZmlndXJlcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbnZlbG9wZSBh
ZGRyZXNzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIHJldHVybiIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIiBOYW1lPSJmb290bm90ZSByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i
YW5ub3RhdGlvbiByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0ibGluZSBudW1iZXIi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0icGFnZSBudW1iZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt
ZT0iZW5kbm90ZSByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW5kbm90ZSB0ZXh0
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRhYmxlIG9mIGF1dGhvcml0aWVzIi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9
InRydWUiIE5hbWU9Im1hY3JvIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt
aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYSBoZWFkaW5nIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBC
dWxsZXQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSIgTmFtZT0iTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgMyIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIiBOYW1lPSJMaXN0IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCA1Ii8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i
TGlzdCBCdWxsZXQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCA0Ii8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i
TGlzdCBOdW1iZXIgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciAzIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i
TGlzdCBOdW1iZXIgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSIxMCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i
Q2xvc2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJTaWduYXR1cmUiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiIE5hbWU9IkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSIgTmFtZT0iQm9keSBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJ
bmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBD
b250aW51ZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i
dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNCIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i
TWVzc2FnZSBIZWFkZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iMTEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h
bWU9IlNhbHV0YXRpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iRGF0ZSIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIiBOYW1lPSJCb2R5IFRleHQgRmlyc3QgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9
IkJvZHkgVGV4dCBGaXJzdCBJbmRlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJOb3RlIEhl
YWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IDIiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSIgTmFtZT0iQm9keSBUZXh0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IElu
ZGVudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQgMyIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIiBOYW1lPSJCbG9jayBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikh5cGVy
bGluayIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi
IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJGb2xsb3dlZEh5cGVybGluayIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgUUZvcm1hdD0idHJ1ZSIgTmFt
ZT0iU3Ryb25nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIw
IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJE
b2N1bWVudCBNYXAiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu
PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iUGxhaW4gVGV4dCIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIiBOYW1lPSJFLW1haWwgU2lnbmF0dXJlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhU
TUwgVG9wIG9mIEZvcm0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBCb3R0b20gb2YgRm9y
bSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu
aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJOb3JtYWwgKFdlYikiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg
TmFtZT0iSFRNTCBBY3JvbnltIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt
aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQWRkcmVzcyIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIENpdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i
SFRNTCBDb2RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i
dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgRGVmaW5pdGlvbiIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEtleWJvYXJkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhU
TUwgUHJlZm9ybWF0dGVkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgU2FtcGxlIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiIE5hbWU9IkhUTUwgVHlwZXdyaXRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l
PSJIVE1MIFZhcmlhYmxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCBUYWJsZSIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo
ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHN1YmplY3QiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg
TmFtZT0iTm8gTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJPdXRsaW5lIExpc3QgMSIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo
ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJPdXRsaW5lIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l
PSJPdXRsaW5lIExpc3QgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI
aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTaW1wbGUgMSIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTaW1wbGUgMiIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO
YW1lPSJUYWJsZSBTaW1wbGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2lj
IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV
bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3NpYyAyIi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBD
bGFzc2ljIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMSIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9
IlRhYmxlIENvbG9yZnVsIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAx
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgMiIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl
IiBOYW1lPSJUYWJsZSBDb2x1bW5zIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29s
dW1ucyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgNSIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUg
R3JpZCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgMyIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3Jp
ZCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg
VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNiIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl
IiBOYW1lPSJUYWJsZSBHcmlkIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA4
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO
YW1lPSJUYWJsZSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAzIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l
PSJUYWJsZSBMaXN0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA2Ii8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU
YWJsZSBMaXN0IDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu
PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAxIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMiIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl
IiBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUg
Q29udGVtcG9yYXJ5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEVsZWdhbnQiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgUHJvZmVzc2lvbmFsIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h
bWU9IlRhYmxlIFN1YnRsZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt
aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFN1YnRsZSAy
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFdlYiAxIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h
bWU9IlRhYmxlIFdlYiAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFdlYiAzIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiIE5hbWU9IkJhbGxvb24gVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl
IiBOYW1lPSJUYWJsZSBUaGVtZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8gU3Bh
Y2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFt
ZT0iTGlnaHQgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNo
YWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIg
TmFtZT0iTWVkaXVtIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVk
aXVtIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3
MCIgTmFtZT0iRGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlk
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJM
aWdodCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAx
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJN
ZWRpdW0gU2hhZGluZyAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlz
dCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgTmFtZT0iUmV2aXNpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iMzQiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ikxpc3QgUGFyYWdyYXBoIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjI5IiBRRm9ybWF0PSJ0cnVl
IiBOYW1lPSJRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSIzMCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBRdW90ZSIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2Nl
bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFt
ZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQg
MyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3
MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1
bCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAy
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJM
aWdodCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2Vu
dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1l
PSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAyIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlz
dCAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRp
dW0gR3JpZCAzIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50
IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9
IkNvbG9yZnVsIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcg
QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEi
IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDMiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n
IDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1l
ZGl1bSBMaXN0IDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNj
ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5h
bWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGlu
ZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3
MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQg
U2hhZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVt
IFNoYWRpbmcgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBB
Y2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIg
TmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNCIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdy
aWQgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1
bCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2Vu
dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1l
PSJMaWdodCBTaGFkaW5nIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2Vu
dCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1l
PSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0g
TGlzdCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA1
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJN
ZWRpdW0gR3JpZCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50
IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9
IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDUiLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdy
aWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdy
aWQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50
IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9
Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEg
QWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgi
IE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlz
dCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3
MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29s
b3JmdWwgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSIxOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lzIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBRRm9ybWF0PSJ0cnVlIiBO
YW1lPSJJbnRlbnNlIEVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjMxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMyIiBRRm9ybWF0PSJ0cnVl
IiBOYW1lPSJJbnRlbnNlIFJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSIzMyIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBUaXRsZSIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJpYmxpb2dyYXBoeSIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQxIiBOYW1lPSJQbGFpbiBU
YWJsZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQyIiBO
YW1lPSJQbGFpbiBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjQzIiBOYW1lPSJQbGFpbiBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjQ0IiBOYW1lPSJQbGFpbiBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ1IiBOYW1lPSJQbGFpbiBUYWJsZSA1Ii8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQwIiBOYW1lPSJHcmlk
IFRhYmxlIExpZ2h0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRh
YmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5h
bWU9IkdyaWQgVGFibGUgNSBEYXJrIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xv
cmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFt
ZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDEiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFi
bGUgMyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQg
MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0i
R3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50
IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9
IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxl
IDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDIi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikdy
aWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAy
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJH
cmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAz
IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5
IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlk
IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3Jp
ZCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBB
Y2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIg
TmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBU
YWJsZSA2IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQg
VGFibGUgMSBMaWdodCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNj
ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5h
bWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFi
bGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRh
YmxlIDEgTGlnaHQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2Vu
dCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1l
PSJHcmlkIFRhYmxlIDQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxl
IDYgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJs
ZSAxIExpZ2h0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3
IiBOYW1lPSJMaXN0IFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFy
ayIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0i
TGlzdCBUYWJsZSA2IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdo
dCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0
NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDEiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFi
bGUgNCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1
bCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1
MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQg
QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDci
IE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAyIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxl
IDQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwg
QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIi
IE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFj
Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBO
YW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMyIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0
IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUw
IiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFj
Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBO
YW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2Nl
bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFt
ZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBB
Y2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIg
TmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2Nl
bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFt
ZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50
IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9
Ikxpc3QgVGFibGUgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNj
ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5h
bWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50
IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9
Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA2
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJM
aXN0IFRhYmxlIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2Vu
dCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1l
PSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA2
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJM
aXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjwvdzpMYXRlbnRTdHlsZXM+DQo8L3ht
bD48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUg
NCA2IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MTsNCgltc28tZ2VuZXJpYy1mb250LWZhbWls
eTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6
MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9z
ZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2Vu
ZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28t
Zm9udC1zaWduYXR1cmU6LTUzNjg1OTkwNSAtMTA3MzczMjQ4NSA5IDAgNTExIDA7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2UtMToyIDExIDYgMyAy
IDIgMiAyIDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1p
bHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJl
OjE2NzEgMCAwIDAgMTU5IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ
cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1z
by1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0K
CW1zby1mb250LXNpZ25hdHVyZTotNTIwMDgxNjY1IC0xMDczNzE3MTU3IDQxIDAgNjYwNDcgMDt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0Onll
czsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCW1zby1mYXJlYXN0LWZv
bnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5
bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0
ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpwDQoJe21zby1zdHlsZS1u
b3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K
CW1hcmdpbi1sZWZ0OjBpbjsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1z
aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgltc28t
ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs
MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHls
ZS11bmhpZGU6bm87DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp
bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJbXNv
LXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs
aWJyaTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs
eTsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2Fs
aWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZh
bWlseTpDYWxpYnJpOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZv
bnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lOw0KCXRleHQtdW5kZXJsaW5l
Om5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmU7DQoJdGV4dC1saW5lLXRocm91Z2g6bm9uZTt9
DQpzcGFuLlNwZWxsRQ0KCXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tc3BsLWU6eWVzO30NCnNw
YW4uR3JhbUUNCgl7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5ZXM7fQ0KLk1zb0No
cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJv
cHM6eWVzOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1hc2NpaS1m
b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
bXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp
bWVzIE5ldyBSb21hbiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu
Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjsNCgltc28taGVhZGVyLW1hcmdpbjou
NWluOw0KCW1zby1mb290ZXItbWFyZ2luOi41aW47DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRp
di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm
IGd0ZSBtc28gMTBdPjxzdHlsZT4vKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNvTm9y
bWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6IlRhYmxlIE5vcm1hbCI7DQoJbXNvLXRzdHlsZS1y
b3diYW5kLXNpemU6MDsNCgltc28tdHN0eWxlLWNvbGJhbmQtc2l6ZTowOw0KCW1zby1zdHlsZS1u
b3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtcGFyZW50OiIi
Ow0KCW1zby1wYWRkaW5nLWFsdDowaW4gNS40cHQgMGluIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdp
bjowaW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9u
OndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5z
aS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb
ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i
ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91
dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0idGFiLWludGVydmFsOi41aW4iPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGNv
bG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+SnVzdCB0byBiZSBjbGVhciwgSSBkaWQgdXNlIHRoZSB0ZXJtIOKAnHN1cGVyIGNvb2tpZeKA
nSBpbiB0aGUgY29udGV4dCBvZiBtdWx0aS1wYXRoIGFuZCBtb2JpbGl0eS4gVGhhdCB3YXMgdHJp
Z2dlcmVkDQogYnkgdGhlIFNQVUQgZGlzY3Vzc2lvbiwgZHVyaW5nIHdoaWNoIGEgcHJvcG9zaXRp
b24gc3VyZmFjZWQgdG8gdXNlIGEgUVVJQy1saWtlIGNvbm5lY3Rpb24gSUQgZm9yIG1vYmlsaXR5
IGFuZCBtdWx0aXBhdGgsIGFuZCB0byBzdGFuZGFyZGl6ZSB0aGF0IGFzIHBhcnQgb2YgdGhlIFNQ
VUQgaGVhZGVyLiBJIHRoaW5rIHVzaW5nIHRoZSBzYW1lIHN0YXRpc3RpY2FsbHkgdW5pcXVlIDY0
LWJpdCBudW1iZXIgaW4gdGhlIGNsZWFyIHRleHQgZW52ZWxvcGUNCiBvZiBwYWNrZXRzIHNlbnQg
ZnJvbSBkaWZmZXJlbnQgSVAgYWRkcmVzc2VzIGlzIGEgcmVhbGx5IGJhZCBpZGVhLiBJdCBpcyBh
IGJhZCBpZGVhIGZvciBNUC1UQ1AsIGFuZCBpdCB3b3VsZCBiZSBiYWQgaWRlYSBmb3IgUVVJQyBv
ciBTUFVELjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBjb2xvcj0iIzFmNDk3ZCIgZmFj
ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgZG8gYWdyZWUgd2l0
aCBKYW5hIGFuZCBSeWFuIHRoYXQgdGhlcmUgaXMgbm8gc3VjaCBwcm9ibGVtIGlmIHRoZSB1bmlx
dWUgbnVtYmVyIGlzIG9ubHkgdXNlZCBmb3IgYSBzaW5nbGUgcGFpcg0KIG9mIHNvdXJjZSBhbmQg
ZGVzdGluYXRpb24gYWRkcmVzc2VzLiBBbmQgSSBhbHNvIGFncmVlIHRoYXQgdGhlIHByb3BlciB0
aW1lIHRvIHN0dWR5IHByaXZhY3ktcHJlc2VydmluZyBtdWx0aXBhdGggbWVjaGFuaXNtcyBpcyBk
dXJpbmcgdGhlIHN0dWR5IG9mIG11bHRpcGF0aC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZh
Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i
MiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFy
ZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7bXNvLWJpZGktZm9u
dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLW5v
LXByb29mOnllcyI+LS0gQ2hyaXN0aWFuIEh1aXRlbWE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2Qi
IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6
ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48Zm9udCBzaXplPSIzIiBjb2xv
cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw
dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF
MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1m
YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztmb250LXdlaWdo
dDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGli
cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO
ZXcgUm9tYW4mcXVvdDsiPg0KIFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxi
PjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5PbiBCZWhhbGYgT2YNCjwvc3Bhbj48L2I+
SmFuYSBJeWVuZ2FyPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6
PC9zcGFuPjwvYj4gU2F0dXJkYXksIE1heSAyMSwgMjAxNiA1OjIwIFBNPGJyPg0KPGI+PHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+IFJ5YW4gSGFtaWx0b24gJmx0
O3JjaEBnb29nbGUuY29tJmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk
Ij5DYzo8L3NwYW4+PC9iPiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpICZsdDttaWNoYWVs
LnNjaGFyZkBub2tpYS5jb20mZ3Q7OyBxdWljQGlldGYub3JnPGJyPg0KPGI+PHNwYW4gc3R5bGU9
ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IFtRVUlDXSBRVUlDIHBy
aXZhY3kgaW1wYWN0PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz
aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0Ij5NaWNoYWVsLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIz
IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5K
dXN0IGNhdWdodCB1cCBvbiB0aGUgU1BVRCB0aHJlYWQsIGFuZCBJJ2QgbGlrZSB0byBjb3JyZWN0
IHNvbWV0aGluZyB5b3Ugc2FpZCB0aGVyZSB0aGF0IEknbGwgcXVvdGUgaGVyZSBmb3IgY29udGV4
dDombmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxpPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1zdHlsZTppdGFsaWMiPiZxdW90O2lmIHRoZXJl
IGlzIG5vdyBhIG5ldyBjbGVhciB0ZXh0IGlkZW50aWZpZXIgdGhhdCBqdXN0IGhhcHBlbnMgdG8g
YmUgdW5pcXVlIHBlciBzdWJzY3JpYmVyLiBXaGF0IGEgZ3JlYXQgaW1wcm92ZW1lbnQgZm9yIHBy
aXZhY3kgaW4gdGhlIEludGVybmV0IQ0KIEFuZCBldmVuIGJldHRlciB0aGF0IGl0IHNlZW1zIGNv
bXBhdGlibGUgd2l0aCBRVUlDLi4uJnF1b3Q7PC9zcGFuPjwvZm9udD48L2k+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UVVJQydzIGNvbm5lY3Rpb24gSUQgaXMgTk9UIHVuaXF1
ZSBwZXIgc3Vic2NyaWJlci4gSXQncyBwZXIgY29ubmVjdGlvbi4gQXMgSSBzYWlkIG9uIHRoZSBv
dGhlciB0aHJlYWQsIGluIHRoZSBzaW5nbGUtcGF0aCBjYXNlLCBpdCByZXZlYWxzIG5vIG1vcmUg
aW5mb3JtdGlvbiB0aGFuIFRDUC4NCiBJbiB0aGUgbXVsdGlwYXRoIGNhc2UsIGl0IGVmZmVjdGl2
ZWx5IHJldmVhbHMgbm8gbW9yZSB0aGFuIE1QVENQLCBzaW5jZSB0aGUgSUQgaXMgdXNlZCB0byB0
aWUgdGhlIG11bHRpcGxlLCB1c2luZyBNUFRDUCBwYXJsYW5jZSwmbmJzcDsmcXVvdDtzdWItZmxv
d3MmcXVvdDssIHRvZ2V0aGVyLiBJdCBpcyBwb3NzaWJsZSB0byBjb25zaWRlciBhIGRpZmZlcmVu
dCBkZXNpZ24gdGhhdCB1c2VzIG11bHRpcGxlIGNvbm5lY3Rpb24gSURzIGZvciB0aGUgbXVsdGlw
bGUgc3ViLWZsb3dzLA0KIGJ1dCB0byBiZSBjbGVhciwgdGhhdCBtYWtlcyB0aGlzIG5ldyBtdWx0
aXBhdGggc3RyaWN0bHkgYmV0dGVyIHRoYW4gTVBUQ1AmbmJzcDthdCBwcml2YWN5LXByZXNlcnZh
dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi
IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkF0
IGFueSByYXRlLCBJIHdhbnRlZCB0byBtYWtlIHN1cmUgdGhhdCB3ZSdyZSB0YWxraW5nIGFib3V0
IHRoZSBzYW1lIGlzc3VlLiBJJ2xsIGFsc28gbm90ZSB0aGF0IGl0J3MgcGxhaW4gd3JvbmcgdG8g
dXNlIHRoZSB0ZXJtICZxdW90O2NsZWFyIHRleHQgc3VwZXIgY29va2llJnF1b3Q7IGluIHJlbGF0
aW9uDQogdG8gdGhlIFFVSUMgY29ubmVjdGlvbiBJRCAoc2VlJm5ic3A7PGEgaHJlZj0iaHR0cHM6
Ly93d3cudGVjaG9wZWRpYS5jb20vZGVmaW5pdGlvbi8yNzMxMC9zdXBlci1jb29raWUiPmh0dHBz
Oi8vd3d3LnRlY2hvcGVkaWEuY29tL2RlZmluaXRpb24vMjczMTAvc3VwZXItY29va2llPC9hPiZu
YnNwO2ZvciB3aGF0IEkgdGhpbmsgYSBzdXBlcmNvb2tpZSBpcy4pPG86cD48L286cD48L3NwYW4+
PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp
emU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4tIGphbmE8bzpwPjwvbzpwPjwvc3Bhbj48
L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk9uIFNhdCwgTWF5IDIxLCAyMDE2IGF0IDk6
MDQgQU0sIEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaUBnb29nbGUuY29tIiB0
YXJnZXQ9Il9ibGFuayI+anJpQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7bXNvLWJvcmRlci1sZWZ0LWFsdDpzb2xpZCAjQ0NDQ0ND
IC43NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXJpZ2h0OjBpbiI+DQo8cD48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UaGF0J3MgYSBkZXNpZ24gZWxlbWVudCB0aGF0
IHNob3VsZCBhbmQgd2lsbCBkZWZpbml0ZWx5IGJlIGRpc2N1c3NlZCBpbiB0aGUgV0cuPG86cD48
L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5l
dyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlNwZWNpZmljYWxseSB0aGlz
IGFwcGxpZXMgdG8gdXNlIG9mIGNvbm5lY3Rpb24gSURzIGR1cmluZyBtdWx0aXBhdGgsIGFuZCBJ
IGV4cGVjdCB0aGF0IGNvbnZlcnNhdGlvbiB0byBoYXBwZW4gd2hlbiB3ZSBkaXNjdXNzIG11bHRp
cGF0aC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFu
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+T24gTWF5IDIxLCAyMDE2IDY6NTYgQU0s
ICZxdW90O1J5YW4gSGFtaWx0b24mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyY2hAZ29vZ2xl
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJjaEBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48
L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O21zby1ib3JkZXItbGVmdC1hbHQ6c29saWQg
I0NDQ0NDQyAuNzVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Zm9udCBzaXplPSIzIiBmYWNlPSJUcmVidWNoZXQgTVMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5E
ZWZpbml0ZWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5l
dyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6
ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw
dCI+T24gRnJpLCBNYXkgMjAsIDIwMTYgYXQgMTE6MjYgUE0sIFNjaGFyZiwgTWljaGFlbCAoTm9r
aWEgLSBERSkgJmx0OzxhIGhyZWY9Im1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20iIHRh
cmdldD0iX2JsYW5rIj5taWNoYWVsLnNjaGFyZkBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw
PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7bXNvLWJvcmRlci1sZWZ0LWFsdDpzb2xp
ZCAjQ0NDQ0NDIC43NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44
cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JcyBpdCBwbGFubmVkIHRvIGRpc2N1c3MgcG90ZW50aWFs
IHByaXZhY3kgaW1wbGljYXRpb25zDQogb2YgdGhlIOKAnlFVSUMgY29ubmVjdGlvbiBpZGVudGlm
aWVy4oCcIChhbHNvIG5hbWVkIOKAnGNsZWFyIHRleHQgc3VwZXIgY29va2ll4oCdIG9uIHRoZSBT
UFVEIGxpc3QpPzwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJtc28tYW5zaS1s
YW5ndWFnZTpERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz0iREUi
IHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i
Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48L2Zv
bnQ+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpERSI+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBjb2xv
cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJtc28tYW5zaS1sYW5n
dWFnZTpERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkRFIiBz
dHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6REUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNh
bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250
PjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6REUiPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9
IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m
bmJzcDs8L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3Vh
Z2U6REUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8
ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu
MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z
by1vdXRsaW5lLWxldmVsOjEiPg0KPGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3Bh
biBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWFuc2ktbGFuZ3VhZ2U6REU7Zm9udC13ZWlnaHQ6Ym9s
ZCI+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxz
cGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssc2Fucy1zZXJpZjttc28tYW5zaS1sYW5ndWFnZTpERSI+DQogUVVJQyBbbWFp
bHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0
OmJvbGQiPk9uIEJlaGFsZiBPZiA8L3NwYW4+PC9iPkVYVCBUZWQgSGFyZGllPGJyPg0KPGI+PHNw
YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gU2F0dXJkYXksIE1h
eSAxNCwgMjAxNiAxOjI3IEFNPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi
PlRvOjwvc3Bhbj48L2I+IDxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+DQpxdWljQGlldGYub3JnPC9hPjsgSmFuYSBJeWVuZ2FyOyBDaHJpc3RpYW4gSHVpdGVt
YTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48
L2I+IFtRVUlDXSBEcmFmdCBjaGFydGVyPC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJERSIgc3R5
bGU9Im1zby1hbnNpLWxhbmd1YWdlOkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1l
cyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28t
YW5zaS1sYW5ndWFnZTpERSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9udCBz
aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9u
dC1zaXplOjEyLjBwdDttc28tYW5zaS1sYW5ndWFnZTpERSI+SG93ZHksPG86cD48L286cD48L3Nw
YW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9udCBzaXplPSIzIiBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdDttc28tYW5zaS1sYW5ndWFnZTpERSI+QXMgcGFydCBvZiB0aGUgQm9GIHByZXBhcmF0aW9u
LCB3ZSBwdXQgdG9nZXRoZXIgYSBzdGFiIGF0IGEgZHJhZnQgY2hhcnRlci4mbmJzcDsgSXQncyBh
dmFpbGFibGUNCiBhcyBodG1sIGFuZCBtYXJrZG93biBvbiBnaXRodWIgYXQ6PGJyPg0KPGJyPg0K
PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL0lFVEYtUVVJQy9DaGFydGVyIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly9naXRodWIuY29tL0lFVEYtUVVJQy9DaGFydGVyPC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGZvbnQgc2l6ZT0i
MyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6
ZToxMi4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6REUiPkkndmUgYXR0YWNoZWQgdGhlIEhUTUwgdmVy
c2lvbiBhcyB3ZWxsLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGlt
ZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNv
LWFuc2ktbGFuZ3VhZ2U6REUiPkl0IHdvdWxkIGJlIGdyZWF0IHRvIGhhdmUgc29tZSBvZiB0aGUg
ZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBiZWZvcmUgdGhlIEJvRi4mbmJzcDsNCiBDb21tZW50cyB0
byB0aGUgbGlzdCBvciBpc3N1ZXMvcHVsbCByZXF1ZXN0cyBhdCB0aGUgZ2l0aHViIHJlcG8gYXJl
IHdlbGNvbWUuJm5ic3A7IFdlIHdpbGwgcGVyaW9kaWNhbGx5IHJlZmxlY3QgYW55IGlzc3VlcyBv
ciBzdWdnZXN0aW9uIGZyb20gdGhlIFJlcG8gYmFjayB0byB0aGUgbGlzdCwgYnV0IHRoaXMgd2ls
bCBiZSBtYW51YWwsIHNvIGV4cGVjdCBzb21lIGxhZy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIz
IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXpl
OjEyLjBwdDttc28tYW5zaS1sYW5ndWFnZTpERSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9m
b250PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9udCBzaXplPSIzIiBmYWNlPSJU
aW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtt
c28tYW5zaS1sYW5ndWFnZTpERSI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjMiIGZhY2U9IlRp
bWVzIE5ldyBSb21hbiI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21z
by1hbnNpLWxhbmd1YWdlOkRFIj5UZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21h
biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUVVJQyBtYWlsaW5nIGxpc3Q8YnI+
DQo8YSBocmVmPSJtYWlsdG86UVVJQ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlFVSUNAaWV0
Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9xdWljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9xdWljPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRp
bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpRVUlDIG1haWxpbmcgbGlz
dDxicj4NCjxhIGhyZWY9Im1haWx0bzpRVUlDQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UVVJ
Q0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL3F1aWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL3F1aWM8L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFu
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_DM2PR0301MB06559A2FD42A3E4CB1E5AB7EA84D0DM2PR0301MB0655_--


From nobody Sun May 22 00:44:31 2016
Return-Path: 
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 E8FC412D0AF for ; Sun, 22 May 2016 00:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 sKgwKAU2DaOH for ; Sun, 22 May 2016 00:44:28 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9257B12D09E for ; Sun, 22 May 2016 00:44:28 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-1f-5741635a5ec6
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 11.8A.12926.A5361475; Sun, 22 May 2016 09:44:26 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0294.000; Sun, 22 May 2016 09:43:27 +0200
From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= 
To: Christian Huitema , Jana Iyengar ,  Ryan Hamilton 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynLzG7Kc0WafEWNs7kTj2FsFJ/DSSMAgAAj/ACAALzBAIAABqQAgABkZoA=
Date: Sun, 22 May 2016 07:43:27 +0000
Message-ID: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.4.160422
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9EEA62AFACBD314E98E4B00096144A74@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUyM2K7um5UsmO4wd53UhZNn/sYLSYdXchi 8fOilkXPAm6L+R97WRxYPRZsKvVYsuQnk0frjr/sHndvXWIKYInisklJzcksSy3St0vgylg4 4SJLwTKuignbnjM2MLZwdTFyckgImEhcbfnDAmGLSVy4t56ti5GLQ0jgCKPE7mmnmEESQgJL GCW2/U0BsdkEvCXaWg6DNYgI5ElMPTiFFcRmFkiQODr3ATuILSygLtG8ZjYzRI2GxKq9p5gg bD+Jn219jCA2i4CqxJsjM8Dm8ApYS6y/M5ERYvF5Zolnu76DDeUUSJTo+/OODcRmFJCVuP/9 HgvEMnGJW0/mM0FcLSCxZM95ZghbVOLl439gvaICehJf7s1jhIgrSaw9vB2olwOoV1Ni/S59 iDHWEq0/T0HdrygxpfshO8Q9ghInZz5hmcAoMQvJtlkI3bOQdM9C0j0LSfcCRtZVjKLFqcVJ uelGxnqpRZnJxcX5eXp5qSWbGIERe3DLb9UdjJffOB5iFOBgVOLhXSDkGC7EmlhWXJl7iFGC g1lJhPdkAlCINyWxsiq1KD++qDQntfgQozQHi5I4r/9LxXAhgfTEktTs1NSC1CKYLBMHp1QD Y4P/OgVbpqy8bd0z2g0fRlqVrMo13fN584MI8SDZ15396W/ko9wOWt+d3GSwolBITVuo4nf8 B+c+ky8CU8uDbrKc5zyjekVUyOrodr/ygmXKzbcijura7nqUkl8imi4ft/zpO9VTG//9mZLI 0rP0tp2xhvzMHs2VNXtflTbZ79rts+Co1en7SizFGYmGWsxFxYkA4b0EEtQCAAA=
Archived-At: 
Cc: "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 May 2016 07:44:30 -0000

DQoNCj5JIGRvIGFncmVlIHdpdGggSmFuYSBhbmQgUnlhbiB0aGF0IHRoZXJlIGlzIG5vIHN1Y2gg
cHJvYmxlbSBpZiB0aGUgdW5pcXVlDQo+bnVtYmVyIGlzIG9ubHkgdXNlZCBmb3IgYSBzaW5nbGUg
cGFpciBvZiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uDQo+YWRkcmVzc2VzLiANCg0KU28gaWYgdGhl
IGRldmljZSBtb3ZlIGludG8gYW4gYXJlYSB3aXRoIGEgbmV3IG5ldHdvcmsgYW5kIG9idGFpbnMg
YW5vdGhlcg0KaG9zdCBhZGRyZXNzLCB0aGVuIGEgbmV3IGNvbm5lY3Rpb24gaWQgd291bGQgYmUg
Y3JlYXRlZCBieSB0aGUgY2xpZW50Pw0KDQpkcmFmdC10c3Z3Zy1xdWljLXByb3RvY29sLTAyIGNs
YWltcyB0aGUgY29ubmVjdGlvbiBpZCByZW1haW4gdGhlIHNhbWUgZXZlbg0KZHVyaW5nIG1pZ3Jh
dGlvbjog4oCcUVVJQyBjYW4gc3Vydml2ZSBJUCBhZGRyZXNzIGNoYW5nZXMgYW5kIE5BVA0KICAg
cmUtYmluZGluZ3Mgc2luY2UgdGhlIENvbm5lY3Rpb24gSUQgcmVtYWlucyB0aGUgc2FtZSBhY3Jv
c3MgdGhlc2UNCm1pZ3JhdGlvbnMu4oCdLiANCg0KVGhpcyBkb2VzIG5vdCBmaXQgdG9nZXRoZXIg
ZG9lcyBpdD8NCg0KSSBtdXN0IGJlIG1pc3Npbmcgc29tZXRoaW5nLi4uDQoNCg0KPkFuZCBJIGFs
c28gYWdyZWUgdGhhdCB0aGUgcHJvcGVyIHRpbWUgdG8gc3R1ZHkgcHJpdmFjeS1wcmVzZXJ2aW5n
DQo+bXVsdGlwYXRoIG1lY2hhbmlzbXMgaXMgZHVyaW5nIHRoZSBzdHVkeSBvZiBtdWx0aXBhdGgu
DQoNCisxIEFuZCB3aGVuIGNvbnNpZGVyaW5nIHRoZSBpbmNyZWFzZWQgYXR0ZW50aW9uIHRvIGVu
ZCB1c2VyIHByaXZhY3kgYW5kDQpzZWN1cml0eSBpbiBJRVRGIGFuZCBXM0MsIHRoaXMgbWF5IG1l
YW4gYSByZW5ld2VkIGxvb2sgYXQgdGhlIHRoZXNlDQphc3BlY3RzIG9mIG11bHRpIHBhdGggbm90
IGNvdmVyZWQgaW4gcHJldmlvdXMgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQoNCg==


From nobody Sun May 22 10:33:16 2016
Return-Path: 
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 944BF12D0DE for ; Sun, 22 May 2016 10:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 kmiTABXwgoLi for ; Sun, 22 May 2016 10:33:13 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC84712D10B for ; Sun, 22 May 2016 10:33:12 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id C8643E70EDE63; Sun, 22 May 2016 17:33:07 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4MHXA1J013335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 May 2016 17:33:10 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4MHW4Rk031268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 May 2016 19:33:10 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sun, 22 May 2016 19:32:31 +0200
From: "Scharf, Michael (Nokia - DE)" 
To: Jana Iyengar , Ryan Hamilton 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynFCnTysxHU/0GFj3E4WoIavJ/DSSMAgAAj/ACAALzBAIABBqOQ
Date: Sun, 22 May 2016 17:32:30 +0000
Message-ID: <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D4886201EFR712WXCHMBA15z_"
MIME-Version: 1.0
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 May 2016 17:33:15 -0000

--_000_655C07320163294895BBADA28372AF5D4886201EFR712WXCHMBA15z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

ZHJhZnQtdHN2d2ctcXVpYy1wcm90b2NvbC0wMiBzYXlzOg0KDQogIFFVSUMgY29ubmVjdGlvbnMg
YXJlIGlkZW50aWZpZWQgYnkgYSA2NC1iaXQgQ29ubmVjdGlvbiBJRCwgcmFuZG9tbHkNCiAgIGdl
bmVyYXRlZCBieSB0aGUgY2xpZW50LiAgUVVJQyBjYW4gc3Vydml2ZSBJUCBhZGRyZXNzIGNoYW5n
ZXMgYW5kIE5BVA0KICAgcmUtYmluZGluZ3Mgc2luY2UgdGhlIENvbm5lY3Rpb24gSUQgcmVtYWlu
cyB0aGUgc2FtZSBhY3Jvc3MgdGhlc2UNCiAgIG1pZ3JhdGlvbnMuDQoNClNvLCBjYW4gd2UgYWdy
ZWUgdGhhdCB0aGlzIHN0YXRlbWVudCBpcyB2ZXJ5LCB2ZXJ5IHZhZ3VlPw0KDQpGb3IgaW5zdGFu
Y2UsIGNvdWxkIEkgd3JpdGUgYSBRVUlDIGltcGxlbWVudGF0aW9uIGNvbXBsaWFudCB0byBkcmFm
dC10c3Z3Zy1xdWljLXByb3RvY29sLTAyIHRoYXQgZS5nLiB1c2VzIGEgc3RhdGljIGFuZCBhIHJh
bmRvbSBwYXJ0IG9mIHRoZSBjb25uZWN0aW9uIElELCBhbmQgZS5nLiBzdG9yZXMgdGhlIHN0YXRp
YyBwYXJ0IHBlcm1hbmVudGx5IG9uIHRoZSB1c2Vy4oCZcyBjb21wdXRlcj8gT3IsIGNvdWxkIEkg
cGljayBhcyBhIHN0YXRpYyBwYXJ0IHRoZSBNQUMgYWRkcmVzcz8gVGhlIHRvdGFsIElEIHdvdWxk
IHN0aWxsIGJlIHJhbmRvbS4gSSBoYXZlIGRpZmZpY3VsdGllcyB0byB1bmRlcnN0YW5kIGhvdyB0
aGlzIHNvcnQgb2YgSUQgZ2VuZXJhdGlvbiB3b3VsZCBiZSBkaWZmZXJlbnQgZnJvbSBhIOKAnGNs
ZWFyIHRleHQgc3VwZXIgY29va2ll4oCdIGFuZCB3aGF0IGlzIGRlZmluZWQgaW4gdGhlIHJlZmVy
ZW5jZSB5b3UgcHJvdmlkZS4NCg0KSSBhbSBzdXJlIHRoYXQgdGhpcyBpcyBub3Qgd2hhdCB0aGUg
Y3VycmVudCBRVUlDIGltcGxlbWVudGF0aW9uIGRvZXMuIEJ1dCBzaW5jZSB3ZSBhcmUgaW4gSUVU
RiBjb250ZXh0LCB0YWxraW5nIGFib3V0IGEgcG90ZW50aWFsIHN0YW5kYXJkLCBJIGFtIGNvbmNl
cm5lZCB3aGF0IG90aGVyIGltcGxlbWVudGVycyBvZiBhIG5ldyBwcm90b2NvbCBjb3VsZCBkbywg
YW5kIHdoYXQgdXNlIGNhc2VzIHRoZXkgY291bGQgZmluZCBmb3IgdGhpcyBJRC4NCg0KQW5kIGlm
IHRoZXJlIHdhcyBzb21lIGludGVyZXN0aW5nIHVzZSBvZiBoYXZpbmcgYW4gZW50aXJlbHkgdXNl
ci1kZWZpbmVkIGNsZWFyIHRleHQgdmFsdWUgYXQgc29tZSBjb25zdGFudCBvZmZzZXQgaW4gdGhl
IHBhY2tldCwgZm9yIGEgd2lkZWx5IHVzZWQgSW50ZXJuZXQgdHJhbnNwb3J0IHByb3RvY29sLCBJ
IGFtIHByZXR0eSBzdXJlIHNvbWUgaW1wbGVtZW50ZXJzIHdvdWxkIG5vdCBjYXJlIGFib3V0IHNv
bWUgTVVTVHMgaW4gYW4gUkZDIHNheWluZyDigJxwbGVhc2UsIHBsZWFzZSwgcGxlYXNlIHNlbGVj
dCBldmVyeSBiaXQgaW4gdGhlIElEIHJhbmRvbWx54oCdLg0KDQpPciBkbyBJIG1pc3Mgc29tZXRo
aW5nIG9idmlvdXM/DQoNCk1pY2hhZWwNCg0KDQoNCg0KRnJvbTogSmFuYSBJeWVuZ2FyIFttYWls
dG86anJpQGdvb2dsZS5jb21dDQpTZW50OiBTdW5kYXksIE1heSAyMiwgMjAxNiA1OjIwIEFNDQpU
bzogUnlhbiBIYW1pbHRvbg0KQ2M6IHF1aWNAaWV0Zi5vcmc7IFNjaGFyZiwgTWljaGFlbCAoTm9r
aWEgLSBERSkNClN1YmplY3Q6IFJlOiBbUVVJQ10gUVVJQyBwcml2YWN5IGltcGFjdA0KDQpNaWNo
YWVsLA0KDQpKdXN0IGNhdWdodCB1cCBvbiB0aGUgU1BVRCB0aHJlYWQsIGFuZCBJJ2QgbGlrZSB0
byBjb3JyZWN0IHNvbWV0aGluZyB5b3Ugc2FpZCB0aGVyZSB0aGF0IEknbGwgcXVvdGUgaGVyZSBm
b3IgY29udGV4dDoNCiJpZiB0aGVyZSBpcyBub3cgYSBuZXcgY2xlYXIgdGV4dCBpZGVudGlmaWVy
IHRoYXQganVzdCBoYXBwZW5zIHRvIGJlIHVuaXF1ZSBwZXIgc3Vic2NyaWJlci4gV2hhdCBhIGdy
ZWF0IGltcHJvdmVtZW50IGZvciBwcml2YWN5IGluIHRoZSBJbnRlcm5ldCEgQW5kIGV2ZW4gYmV0
dGVyIHRoYXQgaXQgc2VlbXMgY29tcGF0aWJsZSB3aXRoIFFVSUMuLi4iDQoNClFVSUMncyBjb25u
ZWN0aW9uIElEIGlzIE5PVCB1bmlxdWUgcGVyIHN1YnNjcmliZXIuIEl0J3MgcGVyIGNvbm5lY3Rp
b24uIEFzIEkgc2FpZCBvbiB0aGUgb3RoZXIgdGhyZWFkLCBpbiB0aGUgc2luZ2xlLXBhdGggY2Fz
ZSwgaXQgcmV2ZWFscyBubyBtb3JlIGluZm9ybXRpb24gdGhhbiBUQ1AuIEluIHRoZSBtdWx0aXBh
dGggY2FzZSwgaXQgZWZmZWN0aXZlbHkgcmV2ZWFscyBubyBtb3JlIHRoYW4gTVBUQ1AsIHNpbmNl
IHRoZSBJRCBpcyB1c2VkIHRvIHRpZSB0aGUgbXVsdGlwbGUsIHVzaW5nIE1QVENQIHBhcmxhbmNl
LCAic3ViLWZsb3dzIiwgdG9nZXRoZXIuIEl0IGlzIHBvc3NpYmxlIHRvIGNvbnNpZGVyIGEgZGlm
ZmVyZW50IGRlc2lnbiB0aGF0IHVzZXMgbXVsdGlwbGUgY29ubmVjdGlvbiBJRHMgZm9yIHRoZSBt
dWx0aXBsZSBzdWItZmxvd3MsIGJ1dCB0byBiZSBjbGVhciwgdGhhdCBtYWtlcyB0aGlzIG5ldyBt
dWx0aXBhdGggc3RyaWN0bHkgYmV0dGVyIHRoYW4gTVBUQ1AgYXQgcHJpdmFjeS1wcmVzZXJ2YXRp
b24uDQoNCkF0IGFueSByYXRlLCBJIHdhbnRlZCB0byBtYWtlIHN1cmUgdGhhdCB3ZSdyZSB0YWxr
aW5nIGFib3V0IHRoZSBzYW1lIGlzc3VlLiBJJ2xsIGFsc28gbm90ZSB0aGF0IGl0J3MgcGxhaW4g
d3JvbmcgdG8gdXNlIHRoZSB0ZXJtICJjbGVhciB0ZXh0IHN1cGVyIGNvb2tpZSIgaW4gcmVsYXRp
b24gdG8gdGhlIFFVSUMgY29ubmVjdGlvbiBJRCAoc2VlIGh0dHBzOi8vd3d3LnRlY2hvcGVkaWEu
Y29tL2RlZmluaXRpb24vMjczMTAvc3VwZXItY29va2llIGZvciB3aGF0IEkgdGhpbmsgYSBzdXBl
cmNvb2tpZSBpcy4pDQoNCi0gamFuYQ0KDQpPbiBTYXQsIE1heSAyMSwgMjAxNiBhdCA5OjA0IEFN
LCBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPG1haWx0bzpqcmlAZ29vZ2xlLmNvbT4+IHdy
b3RlOg0KDQpUaGF0J3MgYSBkZXNpZ24gZWxlbWVudCB0aGF0IHNob3VsZCBhbmQgd2lsbCBkZWZp
bml0ZWx5IGJlIGRpc2N1c3NlZCBpbiB0aGUgV0cuDQoNClNwZWNpZmljYWxseSB0aGlzIGFwcGxp
ZXMgdG8gdXNlIG9mIGNvbm5lY3Rpb24gSURzIGR1cmluZyBtdWx0aXBhdGgsIGFuZCBJIGV4cGVj
dCB0aGF0IGNvbnZlcnNhdGlvbiB0byBoYXBwZW4gd2hlbiB3ZSBkaXNjdXNzIG11bHRpcGF0aC4N
Ck9uIE1heSAyMSwgMjAxNiA2OjU2IEFNLCAiUnlhbiBIYW1pbHRvbiIgPHJjaEBnb29nbGUuY29t
PG1haWx0bzpyY2hAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KRGVmaW5pdGVseS4NCg0KT24gRnJpLCBN
YXkgMjAsIDIwMTYgYXQgMTE6MjYgUE0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgPG1p
Y2hhZWwuc2NoYXJmQG5va2lhLmNvbTxtYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPj4g
d3JvdGU6DQpJcyBpdCBwbGFubmVkIHRvIGRpc2N1c3MgcG90ZW50aWFsIHByaXZhY3kgaW1wbGlj
YXRpb25zIG9mIHRoZSDigJ5RVUlDIGNvbm5lY3Rpb24gaWRlbnRpZmllcuKAnCAoYWxzbyBuYW1l
ZCDigJxjbGVhciB0ZXh0IHN1cGVyIGNvb2tpZeKAnSBvbiB0aGUgU1BVRCBsaXN0KT8NCg0KVGhh
bmtzDQoNCk1pY2hhZWwNCg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu
b3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRVhUIFRlZCBI
YXJkaWUNClNlbnQ6IFNhdHVyZGF5LCBNYXkgMTQsIDIwMTYgMToyNyBBTQ0KVG86IHF1aWNAaWV0
Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+OyBKYW5hIEl5ZW5nYXI7IENocmlzdGlhbiBIdWl0
ZW1hDQpTdWJqZWN0OiBbUVVJQ10gRHJhZnQgY2hhcnRlcg0KDQpIb3dkeSwNCkFzIHBhcnQgb2Yg
dGhlIEJvRiBwcmVwYXJhdGlvbiwgd2UgcHV0IHRvZ2V0aGVyIGEgc3RhYiBhdCBhIGRyYWZ0IGNo
YXJ0ZXIuICBJdCdzIGF2YWlsYWJsZSBhcyBodG1sIGFuZCBtYXJrZG93biBvbiBnaXRodWIgYXQ6
DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9JRVRGLVFVSUMvQ2hhcnRlcg0KSSd2ZSBhdHRhY2hlZCB0
aGUgSFRNTCB2ZXJzaW9uIGFzIHdlbGwuDQpJdCB3b3VsZCBiZSBncmVhdCB0byBoYXZlIHNvbWUg
b2YgdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgYmVmb3JlIHRoZSBCb0YuICBDb21tZW50cyB0
byB0aGUgbGlzdCBvciBpc3N1ZXMvcHVsbCByZXF1ZXN0cyBhdCB0aGUgZ2l0aHViIHJlcG8gYXJl
IHdlbGNvbWUuICBXZSB3aWxsIHBlcmlvZGljYWxseSByZWZsZWN0IGFueSBpc3N1ZXMgb3Igc3Vn
Z2VzdGlvbiBmcm9tIHRoZSBSZXBvIGJhY2sgdG8gdGhlIGxpc3QsIGJ1dCB0aGlzIHdpbGwgYmUg
bWFudWFsLCBzbyBleHBlY3Qgc29tZSBsYWcuDQoNCnJlZ2FyZHMsDQpUZWQNCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClFVSUMgbWFpbGluZyBsaXN0
DQpRVUlDQGlldGYub3JnPG1haWx0bzpRVUlDQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9xdWljDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NClFVSUMgbWFpbGluZyBsaXN0DQpRVUlDQGlldGYub3JnPG1h
aWx0bzpRVUlDQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9xdWljDQoNCg==

--_000_655C07320163294895BBADA28372AF5D4886201EFR712WXCHMBA15z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1T
IjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u
cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46
MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgVm9yZm9ybWF0aWVydCBaY2huIjsNCgltYXJnaW46
MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYu
TXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlNw
cmVjaGJsYXNlbnRleHQgWmNobiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm
Ijt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0Kc3Bhbi5TcHJlY2hibGFzZW50ZXh0WmNobg0KCXttc28tc3R5bGUtbmFtZToiU3By
ZWNoYmxhc2VudGV4dCBaY2huIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6U3ByZWNoYmxhc2VudGV4dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp
ZiI7fQ0Kc3Bhbi5IVE1MVm9yZm9ybWF0aWVydFpjaG4NCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg
Vm9yZm9ybWF0aWVydCBaY2huIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkhUTUwgVm9yZm9ybWF0aWVydCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBX
b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w
cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmRyYWZ0
LXRzdndnLXF1aWMtcHJvdG9jb2wtMDIgc2F5czoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDtRVUlDIGNvbm5l
Y3Rpb25zIGFyZSBpZGVudGlmaWVkIGJ5IGEgNjQtYml0IENvbm5lY3Rpb24gSUQsIHJhbmRvbWx5
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZ2VuZXJhdGVkIGJ5IHRoZSBjbGllbnQuJm5ic3A7IFFV
SUMgY2FuIHN1cnZpdmUgSVAgYWRkcmVzcyBjaGFuZ2VzIGFuZCBOQVQ8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw
OyZuYnNwOyByZS1iaW5kaW5ncyBzaW5jZSB0aGUgQ29ubmVjdGlvbiBJRCByZW1haW5zIHRoZSBz
YW1lIGFjcm9zcyB0aGVzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
Pm1pZ3JhdGlvbnMuIDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+U28sIGNhbiB3ZSBhZ3JlZSB0aGF0IHRoaXMgc3RhdGVtZW50IGlzIHZlcnksIHZlcnkg
dmFndWU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBpbnN0YW5jZSwg
Y291bGQgSSB3cml0ZSBhIFFVSUMgaW1wbGVtZW50YXRpb24gY29tcGxpYW50IHRvIGRyYWZ0LXRz
dndnLXF1aWMtcHJvdG9jb2wtMDIgdGhhdCBlLmcuIHVzZXMgYSBzdGF0aWMgYW5kIGEgcmFuZG9t
IHBhcnQgb2YgdGhlIGNvbm5lY3Rpb24NCiBJRCwgYW5kIGUuZy4gc3RvcmVzIHRoZSBzdGF0aWMg
cGFydCBwZXJtYW5lbnRseSBvbiB0aGUgdXNlcuKAmXMgY29tcHV0ZXI/IE9yLCBjb3VsZCBJIHBp
Y2sgYXMgYSBzdGF0aWMgcGFydCB0aGUgTUFDIGFkZHJlc3M/IFRoZSB0b3RhbCBJRCB3b3VsZCBz
dGlsbCBiZSByYW5kb20uIEkgaGF2ZSBkaWZmaWN1bHRpZXMgdG8gdW5kZXJzdGFuZCBob3cgdGhp
cyBzb3J0IG9mIElEIGdlbmVyYXRpb24gd291bGQgYmUgZGlmZmVyZW50IGZyb20gYSDigJxjbGVh
cg0KIHRleHQgc3VwZXIgY29va2ll4oCdIGFuZCB3aGF0IGlzIGRlZmluZWQgaW4gdGhlIHJlZmVy
ZW5jZSB5b3UgcHJvdmlkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBh
bSBzdXJlIHRoYXQgdGhpcyBpcyBub3Qgd2hhdCB0aGUgY3VycmVudCBRVUlDIGltcGxlbWVudGF0
aW9uIGRvZXMuIEJ1dCBzaW5jZSB3ZSBhcmUgaW4gSUVURiBjb250ZXh0LCB0YWxraW5nIGFib3V0
IGEgcG90ZW50aWFsIHN0YW5kYXJkLCBJIGFtDQogY29uY2VybmVkIHdoYXQgb3RoZXIgaW1wbGVt
ZW50ZXJzIG9mIGEgbmV3IHByb3RvY29sIGNvdWxkIGRvLCBhbmQgd2hhdCB1c2UgY2FzZXMgdGhl
eSBjb3VsZCBmaW5kIGZvciB0aGlzIElELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5BbmQgaWYgdGhlcmUgd2FzIHNvbWUgaW50ZXJlc3RpbmcgdXNlIG9mIGhhdmluZyBhbiBl
bnRpcmVseSB1c2VyLWRlZmluZWQgY2xlYXIgdGV4dCB2YWx1ZSBhdCBzb21lIGNvbnN0YW50IG9m
ZnNldCBpbiB0aGUgcGFja2V0LCBmb3IgYSB3aWRlbHkgdXNlZA0KIEludGVybmV0IHRyYW5zcG9y
dCBwcm90b2NvbCwgSSBhbSBwcmV0dHkgc3VyZSBzb21lIGltcGxlbWVudGVycyB3b3VsZCBub3Qg
Y2FyZSBhYm91dCBzb21lIE1VU1RzIGluIGFuIFJGQyBzYXlpbmcg4oCccGxlYXNlLCBwbGVhc2Us
IHBsZWFzZSBzZWxlY3QgZXZlcnkgYml0IGluIHRoZSBJRCByYW5kb21seeKAnS4NCjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PciBkbyBJIG1pc3Mgc29tZXRoaW5nIG9idmlv
dXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+IEphbmEgSXllbmdhciBbbWFpbHRvOmpyaUBnb29nbGUuY29tXQ0K
PGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWF5IDIyLCAyMDE2IDU6MjAgQU08YnI+DQo8Yj5U
bzo8L2I+IFJ5YW4gSGFtaWx0b248YnI+DQo8Yj5DYzo8L2I+IHF1aWNAaWV0Zi5vcmc7IFNjaGFy
ZiwgTWljaGFlbCAoTm9raWEgLSBERSk8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtRVUlDXSBR
VUlDIHByaXZhY3kgaW1wYWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWNoYWVsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3QgY2F1Z2h0IHVwIG9uIHRoZSBTUFVEIHRocmVhZCwg
YW5kIEknZCBsaWtlIHRvIGNvcnJlY3Qgc29tZXRoaW5nIHlvdSBzYWlkIHRoZXJlIHRoYXQgSSds
bCBxdW90ZSBoZXJlIGZvciBjb250ZXh0OiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxpPiZxdW90O2lmIHRoZXJlIGlzIG5vdyBhIG5ldyBjbGVhciB0
ZXh0IGlkZW50aWZpZXIgdGhhdCBqdXN0IGhhcHBlbnMgdG8gYmUgdW5pcXVlIHBlciBzdWJzY3Jp
YmVyLiBXaGF0IGEgZ3JlYXQgaW1wcm92ZW1lbnQgZm9yIHByaXZhY3kgaW4gdGhlIEludGVybmV0
ISBBbmQgZXZlbiBiZXR0ZXIgdGhhdCBpdCBzZWVtcyBjb21wYXRpYmxlIHdpdGggUVVJQy4uLiZx
dW90OzwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+UVVJQydzIGNvbm5lY3Rpb24gSUQgaXMgTk9UIHVuaXF1ZSBwZXIgc3Vic2NyaWJlci4g
SXQncyBwZXIgY29ubmVjdGlvbi4gQXMgSSBzYWlkIG9uIHRoZSBvdGhlciB0aHJlYWQsIGluIHRo
ZSBzaW5nbGUtcGF0aCBjYXNlLCBpdCByZXZlYWxzIG5vIG1vcmUgaW5mb3JtdGlvbiB0aGFuIFRD
UC4gSW4gdGhlIG11bHRpcGF0aCBjYXNlLCBpdCBlZmZlY3RpdmVseSByZXZlYWxzIG5vIG1vcmUg
dGhhbiBNUFRDUCwgc2luY2UNCiB0aGUgSUQgaXMgdXNlZCB0byB0aWUgdGhlIG11bHRpcGxlLCB1
c2luZyBNUFRDUCBwYXJsYW5jZSwmbmJzcDsmcXVvdDtzdWItZmxvd3MmcXVvdDssIHRvZ2V0aGVy
LiBJdCBpcyBwb3NzaWJsZSB0byBjb25zaWRlciBhIGRpZmZlcmVudCBkZXNpZ24gdGhhdCB1c2Vz
IG11bHRpcGxlIGNvbm5lY3Rpb24gSURzIGZvciB0aGUgbXVsdGlwbGUgc3ViLWZsb3dzLCBidXQg
dG8gYmUgY2xlYXIsIHRoYXQgbWFrZXMgdGhpcyBuZXcgbXVsdGlwYXRoIHN0cmljdGx5IGJldHRl
ciB0aGFuDQogTVBUQ1AmbmJzcDthdCBwcml2YWN5LXByZXNlcnZhdGlvbi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgYW55IHJhdGUsIEkg
d2FudGVkIHRvIG1ha2Ugc3VyZSB0aGF0IHdlJ3JlIHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUgaXNz
dWUuIEknbGwgYWxzbyBub3RlIHRoYXQgaXQncyBwbGFpbiB3cm9uZyB0byB1c2UgdGhlIHRlcm0g
JnF1b3Q7Y2xlYXIgdGV4dCBzdXBlciBjb29raWUmcXVvdDsgaW4gcmVsYXRpb24gdG8gdGhlIFFV
SUMgY29ubmVjdGlvbiBJRCAoc2VlJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cudGVjaG9wZWRp
YS5jb20vZGVmaW5pdGlvbi8yNzMxMC9zdXBlci1jb29raWUiPmh0dHBzOi8vd3d3LnRlY2hvcGVk
aWEuY29tL2RlZmluaXRpb24vMjczMTAvc3VwZXItY29va2llPC9hPiZuYnNwO2Zvcg0KIHdoYXQg
SSB0aGluayBhIHN1cGVyY29va2llIGlzLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBqYW5hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgTWF5IDIxLCAyMDE2IGF0IDk6MDQg
QU0sIEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaUBnb29nbGUuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+anJpQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjxwPlRoYXQncyBhIGRlc2lnbiBlbGVtZW50IHRoYXQgc2hvdWxkIGFuZCB3aWxsIGRlZmluaXRl
bHkgYmUgZGlzY3Vzc2VkIGluIHRoZSBXRy48bzpwPjwvbzpwPjwvcD4NCjxwPlNwZWNpZmljYWxs
eSB0aGlzIGFwcGxpZXMgdG8gdXNlIG9mIGNvbm5lY3Rpb24gSURzIGR1cmluZyBtdWx0aXBhdGgs
IGFuZCBJIGV4cGVjdCB0aGF0IGNvbnZlcnNhdGlvbiB0byBoYXBwZW4gd2hlbiB3ZSBkaXNjdXNz
IG11bHRpcGF0aC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9uIE1heSAyMSwgMjAxNiA2OjU2IEFNLCAmcXVvdDtSeWFuIEhhbWlsdG9u
JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmNoQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5r
Ij5yY2hAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlZmluaXRlbHkuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiBGcmksIE1heSAyMCwgMjAxNiBhdCAxMToyNiBQTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tp
YSAtIERFKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXMgaXQgcGxh
bm5lZCB0byBkaXNjdXNzIHBvdGVudGlhbCBwcml2YWN5IGltcGxpY2F0aW9ucyBvZiB0aGUg4oCe
UVVJQyBjb25uZWN0aW9uIGlkZW50aWZpZXLigJwNCiAoYWxzbyBuYW1lZCDigJxjbGVhciB0ZXh0
IHN1cGVyIGNvb2tpZeKAnSBvbiB0aGUgU1BVRCBsaXN0KT88L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w
cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPiBRVUlDIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNl
c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8
Yj5PbiBCZWhhbGYgT2YgPC9iPkVYVCBUZWQgSGFyZGllPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVy
ZGF5LCBNYXkgMTQsIDIwMTYgMToyNyBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRv
OnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPjsgSmFuYSBJ
eWVuZ2FyOyBDaHJpc3RpYW4gSHVpdGVtYTxicj4NCjxiPlN1YmplY3Q6PC9iPiBbUVVJQ10gRHJh
ZnQgY2hhcnRlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkhvd2R5LDxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkFzIHBhcnQgb2YgdGhlIEJvRiBwcmVwYXJhdGlvbiwg
d2UgcHV0IHRvZ2V0aGVyIGEgc3RhYiBhdCBhIGRyYWZ0IGNoYXJ0ZXIuJm5ic3A7IEl0J3MgYXZh
aWxhYmxlIGFzIGh0bWwgYW5kIG1hcmtkb3duIG9uIGdpdGh1YiBhdDo8YnI+DQo8YnI+DQo8YSBo
cmVmPSJodHRwczovL2dpdGh1Yi5jb20vSUVURi1RVUlDL0NoYXJ0ZXIiIHRhcmdldD0iX2JsYW5r
Ij5odHRwczovL2dpdGh1Yi5jb20vSUVURi1RVUlDL0NoYXJ0ZXI8L2E+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SSd2ZSBhdHRhY2hlZCB0aGUgSFRNTCB2ZXJzaW9u
IGFzIHdlbGwuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+SXQgd291bGQgYmUgZ3JlYXQgdG8gaGF2ZSBzb21lIG9mIHRoZSBkaXNj
dXNzaW9uIG9uIHRoZSBsaXN0IGJlZm9yZSB0aGUgQm9GLiZuYnNwOyBDb21tZW50cyB0byB0aGUg
bGlzdCBvciBpc3N1ZXMvcHVsbCByZXF1ZXN0cyBhdCB0aGUgZ2l0aHViIHJlcG8gYXJlIHdlbGNv
bWUuJm5ic3A7IFdlIHdpbGwgcGVyaW9kaWNhbGx5DQogcmVmbGVjdCBhbnkgaXNzdWVzIG9yIHN1
Z2dlc3Rpb24gZnJvbSB0aGUgUmVwbyBiYWNrIHRvIHRoZSBsaXN0LCBidXQgdGhpcyB3aWxsIGJl
IG1hbnVhbCwgc28gZXhwZWN0IHNvbWUgbGFnLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp
bi1ib3R0b206MTIuMHB0Ij5yZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPlRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w
cHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyPg0KUVVJQyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86UVVJQ0BpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPlFVSUNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9xdWljIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9xdWljPC9hPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48
YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N
ClFVSUMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlFVSUNAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj5RVUlDQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcXVpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcXVpYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_655C07320163294895BBADA28372AF5D4886201EFR712WXCHMBA15z_--


From nobody Sun May 22 10:33:42 2016
Return-Path: 
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 C367C12D139 for ; Sun, 22 May 2016 10:33:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 beFK-iWINous for ; Sun, 22 May 2016 10:33:39 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C4712D12B for ; Sun, 22 May 2016 10:33:39 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 70718C92256CE; Sun, 22 May 2016 17:33:34 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4MHXbIs013369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 May 2016 17:33:37 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4MHXbXH032216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 May 2016 19:33:37 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sun, 22 May 2016 19:33:37 +0200
From: "Scharf, Michael (Nokia - DE)" 
To: Jana Iyengar , Ryan Hamilton 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynFCnTysxHU/0GFj3E4WoIavJ/DSSMAgAAj/ACAAcge0A==
Date: Sun, 22 May 2016 17:33:36 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>  
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48862030FR712WXCHMBA15z_"
MIME-Version: 1.0
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 May 2016 17:33:42 -0000

--_000_655C07320163294895BBADA28372AF5D48862030FR712WXCHMBA15z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2VsbCwgSSBiZWxpZXZlIHRoaXMgdG9waWMgZmFsbHMgaW50byBSRkMgNzI1OCwgd2hpY2ggc3Rh
dGVzLCBhbW9uZ3N0IG90aGVyczoNCg0KDQogICBUaG9zZSBkZXZlbG9waW5nIElFVEYgc3BlY2lm
aWNhdGlvbnMgbmVlZCB0byBiZSBhYmxlIHRvIGRlc2NyaWJlIGhvdw0KDQogICB0aGV5IGhhdmUg
Y29uc2lkZXJlZCBQTSwgYW5kLCBpZiB0aGUgYXR0YWNrIGlzIHJlbGV2YW50IHRvIHRoZSB3b3Jr
DQoNCiAgIHRvIGJlIHB1Ymxpc2hlZCwgYmUgYWJsZSB0byBqdXN0aWZ5IHJlbGF0ZWQgZGVzaWdu
IGRlY2lzaW9ucy4gIFRoaXMNCg0KICAgZG9lcyBub3QgbWVhbiBhIG5ldyAicGVydmFzaXZlIG1v
bml0b3JpbmcgY29uc2lkZXJhdGlvbnMiIHNlY3Rpb24gaXMNCg0KICAgbmVlZGVkIGluIElFVEYg
ZG9jdW1lbnRhdGlvbi4gIEl0IG1lYW5zIHRoYXQsIGlmIGFza2VkLCB0aGVyZSBuZWVkcw0KDQog
ICB0byBiZSBhIGdvb2QgYW5zd2VyIHRvIHRoZSBxdWVzdGlvbiAiSXMgcGVydmFzaXZlIG1vbml0
b3JpbmcgcmVsZXZhbnQNCg0KICAgdG8gdGhpcyB3b3JrIGFuZCBpZiBzbywgaG93IGhhcyBpdCBi
ZWVuIGNvbnNpZGVyZWQ/Ig0KDQogICAgIFvigKZdDQoNCiAgIEluIHBhcnRpY3VsYXIsIGFyY2hp
dGVjdHVyYWwgZGVjaXNpb25zLCBpbmNsdWRpbmcgd2hpY2ggZXhpc3RpbmcNCiAgIHRlY2hub2xv
Z3kgaXMgcmV1c2VkLCBtYXkgc2lnbmlmaWNhbnRseSBpbXBhY3QgdGhlIHZ1bG5lcmFiaWxpdHkg
b2YgYQ0KICAgcHJvdG9jb2wgdG8gUE0uICBUaG9zZSBkZXZlbG9waW5nIElFVEYgc3BlY2lmaWNh
dGlvbnMgdGhlcmVmb3JlIG5lZWQNCiAgIHRvIGNvbnNpZGVyIG1pdGlnYXRpbmcgUE0gd2hlbiBt
YWtpbmcgYXJjaGl0ZWN0dXJhbCBkZWNpc2lvbnMuDQogICBHZXR0aW5nIGFkZXF1YXRlLCBlYXJs
eSByZXZpZXcgb2YgYXJjaGl0ZWN0dXJhbCBkZWNpc2lvbnMgaW5jbHVkaW5nDQogICB3aGV0aGVy
IGFwcHJvcHJpYXRlIG1pdGlnYXRpb24gb2YgUE0gY2FuIGJlIG1hZGUgaXMgaW1wb3J0YW50Lg0K
ICAgUmV2aXNpdGluZyB0aGVzZSBhcmNoaXRlY3R1cmFsIGRlY2lzaW9ucyBsYXRlIGluIHRoZSBw
cm9jZXNzIGlzIHZlcnkNCiAgIGNvc3RseS4NCg0KQXMgcGVyIFJGQyA3MjU4IGhlcmUgdGhlIGZv
cm1hbCBxdWVzdGlvbjoNCg0KSXMgcGVydmFzaXZlIG1vbml0b3JpbmcgcmVsZXZhbnQgdG8gdGhl
IGRlc2lnbiBjaG9pY2VzIG1hZGUgZm9yIHRoZSBRVUlDIGNvbm5lY3Rpb24gSUQsIGFuZCBpZiBz
bywgaG93IGhhcyBpdCBiZWVuIGNvbnNpZGVyZWQ/DQoNCkEgZ29vZCBwbGFjZSB0byBhbnN3ZXIg
bWF5IGJlIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpbiBkcmFmdC10c3Z3Zy1x
dWljLXByb3RvY29sLg0KDQpJbiBnZW5lcmFsLCBJIHBlcnNvbmFsbHkgYmVsaWV2ZSB0aGF0IHRo
aXMgdG9waWMgc2hvdWxkIGJlIGFkZHJlc3NlZCBwcmlvciB0byB0aGUgQm9GIGFuZCBub3QgYWZ0
ZXIgdGhlIFdHIGlzIGZvcm1lZC4gQnV0IHRoaXMgZm9ybWFsIHF1ZXN0aW9uIGlzIGFib3ZlIG15
IElFVEYgcGF5Z3JhZGUuDQoNCk1pY2hhZWwNCg0KDQpGcm9tOiBKYW5hIEl5ZW5nYXIgW21haWx0
bzpqcmlAZ29vZ2xlLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBNYXkgMjEsIDIwMTYgNjowNSBQTQ0K
VG86IFJ5YW4gSGFtaWx0b24NCkNjOiBxdWljQGlldGYub3JnOyBTY2hhcmYsIE1pY2hhZWwgKE5v
a2lhIC0gREUpDQpTdWJqZWN0OiBSZTogW1FVSUNdIFFVSUMgcHJpdmFjeSBpbXBhY3QNCg0KDQpU
aGF0J3MgYSBkZXNpZ24gZWxlbWVudCB0aGF0IHNob3VsZCBhbmQgd2lsbCBkZWZpbml0ZWx5IGJl
IGRpc2N1c3NlZCBpbiB0aGUgV0cuDQoNClNwZWNpZmljYWxseSB0aGlzIGFwcGxpZXMgdG8gdXNl
IG9mIGNvbm5lY3Rpb24gSURzIGR1cmluZyBtdWx0aXBhdGgsIGFuZCBJIGV4cGVjdCB0aGF0IGNv
bnZlcnNhdGlvbiB0byBoYXBwZW4gd2hlbiB3ZSBkaXNjdXNzIG11bHRpcGF0aC4NCk9uIE1heSAy
MSwgMjAxNiA2OjU2IEFNLCAiUnlhbiBIYW1pbHRvbiIgPHJjaEBnb29nbGUuY29tPG1haWx0bzpy
Y2hAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KRGVmaW5pdGVseS4NCg0KT24gRnJpLCBNYXkgMjAsIDIw
MTYgYXQgMTE6MjYgUE0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgPG1pY2hhZWwuc2No
YXJmQG5va2lhLmNvbTxtYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPj4gd3JvdGU6DQpJ
cyBpdCBwbGFubmVkIHRvIGRpc2N1c3MgcG90ZW50aWFsIHByaXZhY3kgaW1wbGljYXRpb25zIG9m
IHRoZSDigJ5RVUlDIGNvbm5lY3Rpb24gaWRlbnRpZmllcuKAnCAoYWxzbyBuYW1lZCDigJxjbGVh
ciB0ZXh0IHN1cGVyIGNvb2tpZeKAnSBvbiB0aGUgU1BVRCBsaXN0KT8NCg0KVGhhbmtzDQoNCk1p
Y2hhZWwNCg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0
bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRVhUIFRlZCBIYXJkaWUNClNl
bnQ6IFNhdHVyZGF5LCBNYXkgMTQsIDIwMTYgMToyNyBBTQ0KVG86IHF1aWNAaWV0Zi5vcmc8bWFp
bHRvOnF1aWNAaWV0Zi5vcmc+OyBKYW5hIEl5ZW5nYXI7IENocmlzdGlhbiBIdWl0ZW1hDQpTdWJq
ZWN0OiBbUVVJQ10gRHJhZnQgY2hhcnRlcg0KDQpIb3dkeSwNCkFzIHBhcnQgb2YgdGhlIEJvRiBw
cmVwYXJhdGlvbiwgd2UgcHV0IHRvZ2V0aGVyIGEgc3RhYiBhdCBhIGRyYWZ0IGNoYXJ0ZXIuICBJ
dCdzIGF2YWlsYWJsZSBhcyBodG1sIGFuZCBtYXJrZG93biBvbiBnaXRodWIgYXQ6DQoNCmh0dHBz
Oi8vZ2l0aHViLmNvbS9JRVRGLVFVSUMvQ2hhcnRlcg0KSSd2ZSBhdHRhY2hlZCB0aGUgSFRNTCB2
ZXJzaW9uIGFzIHdlbGwuDQpJdCB3b3VsZCBiZSBncmVhdCB0byBoYXZlIHNvbWUgb2YgdGhlIGRp
c2N1c3Npb24gb24gdGhlIGxpc3QgYmVmb3JlIHRoZSBCb0YuICBDb21tZW50cyB0byB0aGUgbGlz
dCBvciBpc3N1ZXMvcHVsbCByZXF1ZXN0cyBhdCB0aGUgZ2l0aHViIHJlcG8gYXJlIHdlbGNvbWUu
ICBXZSB3aWxsIHBlcmlvZGljYWxseSByZWZsZWN0IGFueSBpc3N1ZXMgb3Igc3VnZ2VzdGlvbiBm
cm9tIHRoZSBSZXBvIGJhY2sgdG8gdGhlIGxpc3QsIGJ1dCB0aGlzIHdpbGwgYmUgbWFudWFsLCBz
byBleHBlY3Qgc29tZSBsYWcuDQoNCnJlZ2FyZHMsDQpUZWQNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClFVSUMgbWFpbGluZyBsaXN0DQpRVUlDQGll
dGYub3JnPG1haWx0bzpRVUlDQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9xdWljDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NClFVSUMgbWFpbGluZyBsaXN0DQpRVUlDQGlldGYub3JnPG1haWx0bzpRVUlD
QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9xdWljDQo=

--_000_655C07320163294895BBADA28372AF5D48862030FR712WXCHMBA15z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1T
IjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u
cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46
MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgVm9yZm9ybWF0aWVydCBaY2huIjsNCgltYXJnaW46
MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYu
TXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlNw
cmVjaGJsYXNlbnRleHQgWmNobiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm
Ijt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0Kc3Bhbi5TcHJlY2hibGFzZW50ZXh0WmNobg0KCXttc28tc3R5bGUtbmFtZToiU3By
ZWNoYmxhc2VudGV4dCBaY2huIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6U3ByZWNoYmxhc2VudGV4dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp
ZiI7fQ0Kc3Bhbi5IVE1MVm9yZm9ybWF0aWVydFpjaG4NCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg
Vm9yZm9ybWF0aWVydCBaY2huIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkhUTUwgVm9yZm9ybWF0aWVydCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBX
b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w
cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlbGws
IEkgYmVsaWV2ZSB0aGlzIHRvcGljIGZhbGxzIGludG88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+UkZDIDcyNTgsIHdoaWNoIHN0YXRlcywgYW1vbmdzdCBvdGhlcnM6PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgVGhvc2UgZGV2ZWxv
cGluZyBJRVRGIHNwZWNpZmljYXRpb25zIG5lZWQgdG8gYmUgYWJsZSB0byBkZXNjcmliZSBob3c8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZu
YnNwOyB0aGV5IGhhdmUgY29uc2lkZXJlZCBQTSwgYW5kLCBpZiB0aGUgYXR0YWNrIGlzIHJlbGV2
YW50IHRvIHRoZSB3b3JrPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkVOLVVTIj4mbmJzcDsmbmJzcDsgdG8gYmUgcHVibGlzaGVkLCBiZSBhYmxlIHRvIGp1c3RpZnkg
cmVsYXRlZCBkZXNpZ24gZGVjaXNpb25zLiZuYnNwOyBUaGlzPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgZG9lcyBub3QgbWVhbiBh
IG5ldyAmcXVvdDtwZXJ2YXNpdmUgbW9uaXRvcmluZyBjb25zaWRlcmF0aW9ucyZxdW90OyBzZWN0
aW9uIGlzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4m
bmJzcDsmbmJzcDsgbmVlZGVkIGluIElFVEYgZG9jdW1lbnRhdGlvbi4mbmJzcDsgSXQgbWVhbnMg
dGhhdCwgaWYgYXNrZWQsIHRoZXJlIG5lZWRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgdG8gYmUgYSBnb29kIGFuc3dlciB0byB0
aGUgcXVlc3Rpb24gJnF1b3Q7SXMgcGVydmFzaXZlIG1vbml0b3JpbmcgcmVsZXZhbnQ8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyB0
byB0aGlzIHdvcmsgYW5kIGlmIHNvLCBob3cgaGFzIGl0IGJlZW4gY29uc2lkZXJlZD8mcXVvdDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgW+KApl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEluIHBhcnRpY3VsYXIsIGFyY2hpdGVjdHVyYWwg
ZGVjaXNpb25zLCBpbmNsdWRpbmcgd2hpY2ggZXhpc3Rpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw
OyB0ZWNobm9sb2d5IGlzIHJldXNlZCwgbWF5IHNpZ25pZmljYW50bHkgaW1wYWN0IHRoZSB2dWxu
ZXJhYmlsaXR5IG9mIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwcm90b2NvbCB0byBQTS4mbmJz
cDsgVGhvc2UgZGV2ZWxvcGluZyBJRVRGIHNwZWNpZmljYXRpb25zIHRoZXJlZm9yZSBuZWVkPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdG8gY29uc2lkZXIgbWl0aWdhdGluZyBQTSB3aGVuIG1ha2lu
ZyBhcmNoaXRlY3R1cmFsIGRlY2lzaW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBHZXR0aW5n
IGFkZXF1YXRlLCBlYXJseSByZXZpZXcgb2YgYXJjaGl0ZWN0dXJhbCBkZWNpc2lvbnMgaW5jbHVk
aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgd2hldGhlciBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9u
IG9mIFBNIGNhbiBiZSBtYWRlIGlzIGltcG9ydGFudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBS
ZXZpc2l0aW5nIHRoZXNlIGFyY2hpdGVjdHVyYWwgZGVjaXNpb25zIGxhdGUgaW4gdGhlIHByb2Nl
c3MgaXMgdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNvc3RseS48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgcGVyIFJGQyA3MjU4IGhlcmUgdGhlIGZvcm1hbCBxdWVz
dGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXMgcGVydmFzaXZlIG1v
bml0b3JpbmcgcmVsZXZhbnQgdG8gdGhlIGRlc2lnbiBjaG9pY2VzIG1hZGUgZm9yIHRoZSBRVUlD
IGNvbm5lY3Rpb24gSUQsIGFuZCBpZiBzbywgaG93IGhhcyBpdCBiZWVuIGNvbnNpZGVyZWQ/PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEgZ29vZCBwbGFjZSB0byBhbnN3ZXIg
bWF5IGJlIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpbiBkcmFmdC10c3Z3Zy1x
dWljLXByb3RvY29sLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBnZW5l
cmFsLCBJIHBlcnNvbmFsbHkgYmVsaWV2ZSB0aGF0IHRoaXMgdG9waWMgc2hvdWxkIGJlIGFkZHJl
c3NlZCBwcmlvciB0byB0aGUgQm9GIGFuZCBub3QgYWZ0ZXIgdGhlIFdHIGlzIGZvcm1lZC4gQnV0
IHRoaXMgZm9ybWFsIHF1ZXN0aW9uDQogaXMgYWJvdmUgbXkgSUVURiBwYXlncmFkZS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj
bSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6
c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKYW5hIEl5ZW5nYXIgW21haWx0bzpqcmlA
Z29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWF5IDIxLCAyMDE2IDY6
MDUgUE08YnI+DQo8Yj5Ubzo8L2I+IFJ5YW4gSGFtaWx0b248YnI+DQo8Yj5DYzo8L2I+IHF1aWNA
aWV0Zi5vcmc7IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IFtRVUlDXSBRVUlDIHByaXZhY3kgaW1wYWN0PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHA+VGhhdCdzIGEgZGVzaWduIGVsZW1lbnQgdGhhdCBzaG91bGQgYW5kIHdpbGwgZGVmaW5p
dGVseSBiZSBkaXNjdXNzZWQgaW4gdGhlIFdHLjxvOnA+PC9vOnA+PC9wPg0KPHA+U3BlY2lmaWNh
bGx5IHRoaXMgYXBwbGllcyB0byB1c2Ugb2YgY29ubmVjdGlvbiBJRHMgZHVyaW5nIG11bHRpcGF0
aCwgYW5kIEkgZXhwZWN0IHRoYXQgY29udmVyc2F0aW9uIHRvIGhhcHBlbiB3aGVuIHdlIGRpc2N1
c3MgbXVsdGlwYXRoLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk9uIE1heSAyMSwgMjAxNiA2OjU2IEFNLCAmcXVvdDtSeWFuIEhhbWlsdG9uJnF1b3Q7ICZsdDs8
YSBocmVmPSJtYWlsdG86cmNoQGdvb2dsZS5jb20iPnJjaEBnb29nbGUuY29tPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+RGVmaW5pdGVseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTWF5IDIwLCAyMDE2IGF0IDEx
OjI2IFBNLCBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpICZsdDs8YSBocmVmPSJtYWlsdG86
bWljaGFlbC5zY2hhcmZAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWljaGFlbC5zY2hhcmZA
bm9raWEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5JcyBpdCBwbGFubmVkIHRvIGRpc2N1c3MgcG90ZW50aWFsIHBy
aXZhY3kgaW1wbGljYXRpb25zIG9mIHRoZSDigJ5RVUlDIGNvbm5lY3Rpb24gaWRlbnRpZmllcuKA
nA0KIChhbHNvIG5hbWVkIOKAnGNsZWFyIHRleHQgc3VwZXIgY29va2ll4oCdIG9uIHRoZSBTUFVE
IGxpc3QpPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NaWNoYWVsPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh
ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFFVSUMgW21haWx0
bzo8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RVhUIFRlZCBI
YXJkaWU8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIE1heSAxNCwgMjAxNiAxOjI3IEFNPGJy
Pg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPnF1aWNAaWV0Zi5vcmc8L2E+OyBKYW5hIEl5ZW5nYXI7IENocmlzdGlhbiBIdWl0ZW1hPGJy
Pg0KPGI+U3ViamVjdDo8L2I+IFtRVUlDXSBEcmFmdCBjaGFydGVyPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy
LjBwdCI+SG93ZHksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+QXMg
cGFydCBvZiB0aGUgQm9GIHByZXBhcmF0aW9uLCB3ZSBwdXQgdG9nZXRoZXIgYSBzdGFiIGF0IGEg
ZHJhZnQgY2hhcnRlci4mbmJzcDsgSXQncyBhdmFpbGFibGUgYXMgaHRtbCBhbmQgbWFya2Rvd24g
b24gZ2l0aHViIGF0Ojxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9JRVRG
LVFVSUMvQ2hhcnRlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9JRVRGLVFV
SUMvQ2hhcnRlcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5J
J3ZlIGF0dGFjaGVkIHRoZSBIVE1MIHZlcnNpb24gYXMgd2VsbC4mbmJzcDsNCjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCB3b3VsZCBiZSBn
cmVhdCB0byBoYXZlIHNvbWUgb2YgdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgYmVmb3JlIHRo
ZSBCb0YuJm5ic3A7IENvbW1lbnRzIHRvIHRoZSBsaXN0IG9yIGlzc3Vlcy9wdWxsIHJlcXVlc3Rz
IGF0IHRoZSBnaXRodWIgcmVwbyBhcmUgd2VsY29tZS4mbmJzcDsgV2Ugd2lsbCBwZXJpb2RpY2Fs
bHkNCiByZWZsZWN0IGFueSBpc3N1ZXMgb3Igc3VnZ2VzdGlvbiBmcm9tIHRoZSBSZXBvIGJhY2sg
dG8gdGhlIGxpc3QsIGJ1dCB0aGlzIHdpbGwgYmUgbWFudWFsLCBzbyBleHBlY3Qgc29tZSBsYWcu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPnJlZ2FyZHMsPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGVkPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpRVUlDIG1haWxpbmcgbGlzdDxicj4N
CjxhIGhyZWY9Im1haWx0bzpRVUlDQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UVVJQ0BpZXRm
Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL3F1aWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3F1aWM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUVVJQyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo
cmVmPSJtYWlsdG86UVVJQ0BpZXRmLm9yZyI+UVVJQ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3F1aWMiIHRhcmdldD0iX2Js
YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3F1aWM8L2E+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_655C07320163294895BBADA28372AF5D48862030FR712WXCHMBA15z_--


From nobody Sun May 22 14:39:21 2016
Return-Path: 
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 ABBF712D5D0 for ; Sun, 22 May 2016 14:39:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level: 
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 M92u5mQeoKAZ for ; Sun, 22 May 2016 14:39:09 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4626012B040 for ; Sun, 22 May 2016 14:39:09 -0700 (PDT)
Received: from [172.30.194.98] (unknown [91.143.127.69]) by trammell.ch (Postfix) with ESMTPSA id 73D991A0046; Sun, 22 May 2016 23:39:07 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_CA6DC3A4-3593-44C1-8015-7419E8B96571"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell 
In-Reply-To: <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Date: Sun, 22 May 2016 23:39:05 +0200
Message-Id: <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com>
To: "Scharf, Michael (Nokia - DE)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 May 2016 21:39:12 -0000

--Apple-Mail=_CA6DC3A4-3593-44C1-8015-7419E8B96571
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

hi Michael, all,

There are, of course, ways to make such a connection ID be useful as =
such to the endpoints without exposing that linkability to the network =
(off the top of my head, by having the connection ID given a 4-typle be =
algorithmically derivable from any other {4-tuple, connection-id} and a =
shared secret derived from the session key). If the point of this =
connection ID is supporting multipath, this would work. If the point of =
the connection ID is allowing on-path devices to associate multiple =
connections, then linkability is tautologically possible.

But the eventual protocol specification should make it clear that the =
former is the case (at least, I hope it is); the algorithm for deriving =
the connection ID would then need to be part of the spec as well.

Cheers,

Brian



> On 22 May 2016, at 19:33, Scharf, Michael (Nokia - DE) =
 wrote:
>=20
> Well, I believe this topic falls into RFC 7258, which states, amongst =
others:
>=20
>    Those developing IETF specifications need to be able to describe =
how
>    they have considered PM, and, if the attack is relevant to the work
>    to be published, be able to justify related design decisions.  This
>    does not mean a new "pervasive monitoring considerations" section =
is
>    needed in IETF documentation.  It means that, if asked, there needs
>    to be a good answer to the question "Is pervasive monitoring =
relevant
>    to this work and if so, how has it been considered?"
>=20
>      [=E2=80=A6]
>=20
>    In particular, architectural decisions, including which existing
>    technology is reused, may significantly impact the vulnerability of =
a
>    protocol to PM.  Those developing IETF specifications therefore =
need
>    to consider mitigating PM when making architectural decisions.
>    Getting adequate, early review of architectural decisions including
>    whether appropriate mitigation of PM can be made is important.
>    Revisiting these architectural decisions late in the process is =
very
>    costly.
>=20
> As per RFC 7258 here the formal question:
>=20
> Is pervasive monitoring relevant to the design choices made for the =
QUIC connection ID, and if so, how has it been considered?
>=20
> A good place to answer may be a security considerations section in =
draft-tsvwg-quic-protocol.
>=20
> In general, I personally believe that this topic should be addressed =
prior to the BoF and not after the WG is formed. But this formal =
question is above my IETF paygrade.
>=20
> Michael
>=20
>=20
> From: Jana Iyengar [mailto:jri@google.com]
> Sent: Saturday, May 21, 2016 6:05 PM
> To: Ryan Hamilton
> Cc: quic@ietf.org; Scharf, Michael (Nokia - DE)
> Subject: Re: [QUIC] QUIC privacy impact
>=20
> That's a design element that should and will definitely be discussed =
in the WG.
>=20
> Specifically this applies to use of connection IDs during multipath, =
and I expect that conversation to happen when we discuss multipath.
>=20
> On May 21, 2016 6:56 AM, "Ryan Hamilton"  wrote:
> Definitely.
>=20
> On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) =
 wrote:
> Is it planned to discuss potential privacy implications of the =E2=80=9E=
QUIC connection identifier=E2=80=9C (also named =E2=80=9Cclear text =
super cookie=E2=80=9D on the SPUD list)?
>=20
> Thanks
>=20
> Michael
>=20
>=20
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of EXT Ted Hardie
> Sent: Saturday, May 14, 2016 1:27 AM
> To: quic@ietf.org; Jana Iyengar; Christian Huitema
> Subject: [QUIC] Draft charter
>=20
> Howdy,
>=20
> As part of the BoF preparation, we put together a stab at a draft =
charter.  It's available as html and markdown on github at:
>=20
> https://github.com/IETF-QUIC/Charter
>=20
> I've attached the HTML version as well.
>=20
> It would be great to have some of the discussion on the list before =
the BoF.  Comments to the list or issues/pull requests at the github =
repo are welcome.  We will periodically reflect any issues or suggestion =
from the Repo back to the list, but this will be manual, so expect some =
lag.
>=20
> regards,
>=20
> Ted
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>=20
>=20
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic


--Apple-Mail=_CA6DC3A4-3593-44C1-8015-7419E8B96571
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJXQib6AAoJEIoSt78L6kajbsQQAKq2R1AbOQwJRL+EQe2ux93B
OHNFFp6syHGrkl8D+jCFekyR2fPXwUv3Yv3lLx0KdksTZHixYCH5ohN0BOcRvZ+l
5WLn283yJjBDhbNCHiXkQwEL9aMK4EXEFA8PKOB78d66RfzBMkWkkzAPlO94pC93
NJ2fckrGi0dJ65Gqckwag6BG2JLCjSjM/Tuox5EoLs8EgET4dVOw85PovVAUVq8E
fNfZBk6HCInBdKtgoSpuGLQLQ/TOcXy95Sp6/ukHZlWhR5hss9h4GYWDtRnrzx0d
ztoFXgrGqzwHPrBZqAwM+JPlpC1dwSb/kT7HKxSneKCVr+FVNfxjTlar3OmKuCVr
U4IDKvUFKv1r44Pulyy4duA5UXL215UpR5aEGSl8Y3tPpYNlebeGI0D+Wifk5rnh
sJ+MFiyKZ5DXQfqBlhRFRWJYlRfVp9IcDDjNgwrHczPGMIJ+LMG678oxJhQKKBj6
aveSNQ9lkS0et04sPBCqI43r8rhzRJp+nl7tFxVy4hBeuPc3TtvqrHLY3D+vs44U
Ssk7GYbGl6QSJy8l/jIN3kYhYDxOqJIatA5vOFbxdEgmxjyN/CHkgnjNqQxtD7SQ
BbrLFy7LyHgFSuV88Zi6GOD4QfDN7/JNZ431N2lCdSG47V3YHy0o7Q64tJ4fVPd1
l5NDOXJoLsI3hpe2ayQ6
=e4Qv
-----END PGP SIGNATURE-----

--Apple-Mail=_CA6DC3A4-3593-44C1-8015-7419E8B96571--


From nobody Sun May 22 14:55:40 2016
Return-Path: 
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 CD6B612D5D2 for ; Sun, 22 May 2016 14:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level: 
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 fHjSt9yYBJth for ; Sun, 22 May 2016 14:55:36 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847FB12B04D for ; Sun, 22 May 2016 14:55:36 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 0A4ACB0F6AEDB; Sun, 22 May 2016 21:55:31 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4MLtYM5010874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 22 May 2016 21:55:34 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4MLsRxE013526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 May 2016 23:55:34 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sun, 22 May 2016 23:54:28 +0200
From: "Scharf, Michael (Nokia - DE)" 
To: Brian Trammell 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynFCnTysxHU/0GFj3E4WoIavJ/DSSMAgAAj/ACAAcge0IAAJ6KAgAAkAGA=
Date: Sun, 22 May 2016 21:54:28 +0000
Message-ID: <655C07320163294895BBADA28372AF5D488623DB@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>
In-Reply-To: <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: Jana Iyengar , "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 May 2016 21:55:39 -0000

V291bGRuJ3Qgc29tZSB3b3JkaW5nIGJlIHVzZWZ1bCBpbiB0aGUgcHJvcG9zZWQgY2hhcnRlcj8g
RS5nLiwgdXNlciB0cmFjdGFiaWxpdHkgYW5kIHVzZXIgbG9jYXRpb24gcHJpdmFjeSBpcyBub3Qg
bWVudGlvbmVkIGZvciB0aGUgc2VjdXJpdHkgZGVsaXZlcmFibGVzLg0KDQpNaWNoYWVsDQoNCg0K
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBUcmFtbWVsbCBbbWFp
bHRvOmlldGZAdHJhbW1lbGwuY2hdDQo+IFNlbnQ6IFN1bmRheSwgTWF5IDIyLCAyMDE2IDExOjM5
IFBNDQo+IFRvOiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpDQo+IENjOiBKYW5hIEl5ZW5n
YXI7IFJ5YW4gSGFtaWx0b247IHF1aWNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtRVUlDXSBR
VUlDIHByaXZhY3kgaW1wYWN0DQo+IA0KPiBoaSBNaWNoYWVsLCBhbGwsDQo+IA0KPiBUaGVyZSBh
cmUsIG9mIGNvdXJzZSwgd2F5cyB0byBtYWtlIHN1Y2ggYSBjb25uZWN0aW9uIElEIGJlIHVzZWZ1
bCBhcw0KPiBzdWNoIHRvIHRoZSBlbmRwb2ludHMgd2l0aG91dCBleHBvc2luZyB0aGF0IGxpbmth
YmlsaXR5IHRvIHRoZSBuZXR3b3JrDQo+IChvZmYgdGhlIHRvcCBvZiBteSBoZWFkLCBieSBoYXZp
bmcgdGhlIGNvbm5lY3Rpb24gSUQgZ2l2ZW4gYSA0LXR5cGxlIGJlDQo+IGFsZ29yaXRobWljYWxs
eSBkZXJpdmFibGUgZnJvbSBhbnkgb3RoZXIgezQtdHVwbGUsIGNvbm5lY3Rpb24taWR9IGFuZCBh
DQo+IHNoYXJlZCBzZWNyZXQgZGVyaXZlZCBmcm9tIHRoZSBzZXNzaW9uIGtleSkuIElmIHRoZSBw
b2ludCBvZiB0aGlzDQo+IGNvbm5lY3Rpb24gSUQgaXMgc3VwcG9ydGluZyBtdWx0aXBhdGgsIHRo
aXMgd291bGQgd29yay4gSWYgdGhlIHBvaW50IG9mDQo+IHRoZSBjb25uZWN0aW9uIElEIGlzIGFs
bG93aW5nIG9uLXBhdGggZGV2aWNlcyB0byBhc3NvY2lhdGUgbXVsdGlwbGUNCj4gY29ubmVjdGlv
bnMsIHRoZW4gbGlua2FiaWxpdHkgaXMgdGF1dG9sb2dpY2FsbHkgcG9zc2libGUuDQo+IA0KPiBC
dXQgdGhlIGV2ZW50dWFsIHByb3RvY29sIHNwZWNpZmljYXRpb24gc2hvdWxkIG1ha2UgaXQgY2xl
YXIgdGhhdCB0aGUNCj4gZm9ybWVyIGlzIHRoZSBjYXNlIChhdCBsZWFzdCwgSSBob3BlIGl0IGlz
KTsgdGhlIGFsZ29yaXRobSBmb3IgZGVyaXZpbmcNCj4gdGhlIGNvbm5lY3Rpb24gSUQgd291bGQg
dGhlbiBuZWVkIHRvIGJlIHBhcnQgb2YgdGhlIHNwZWMgYXMgd2VsbC4NCj4gDQo+IENoZWVycywN
Cj4gDQo+IEJyaWFuDQo+IA0KPiANCj4gDQo+ID4gT24gMjIgTWF5IDIwMTYsIGF0IDE5OjMzLCBT
Y2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpDQo+IDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+
IHdyb3RlOg0KPiA+DQo+ID4gV2VsbCwgSSBiZWxpZXZlIHRoaXMgdG9waWMgZmFsbHMgaW50byBS
RkMgNzI1OCwgd2hpY2ggc3RhdGVzLCBhbW9uZ3N0DQo+IG90aGVyczoNCj4gPg0KPiA+ICAgIFRo
b3NlIGRldmVsb3BpbmcgSUVURiBzcGVjaWZpY2F0aW9ucyBuZWVkIHRvIGJlIGFibGUgdG8gZGVz
Y3JpYmUNCj4gaG93DQo+ID4gICAgdGhleSBoYXZlIGNvbnNpZGVyZWQgUE0sIGFuZCwgaWYgdGhl
IGF0dGFjayBpcyByZWxldmFudCB0byB0aGUNCj4gd29yaw0KPiA+ICAgIHRvIGJlIHB1Ymxpc2hl
ZCwgYmUgYWJsZSB0byBqdXN0aWZ5IHJlbGF0ZWQgZGVzaWduIGRlY2lzaW9ucy4NCj4gVGhpcw0K
PiA+ICAgIGRvZXMgbm90IG1lYW4gYSBuZXcgInBlcnZhc2l2ZSBtb25pdG9yaW5nIGNvbnNpZGVy
YXRpb25zIiBzZWN0aW9uDQo+IGlzDQo+ID4gICAgbmVlZGVkIGluIElFVEYgZG9jdW1lbnRhdGlv
bi4gIEl0IG1lYW5zIHRoYXQsIGlmIGFza2VkLCB0aGVyZQ0KPiBuZWVkcw0KPiA+ICAgIHRvIGJl
IGEgZ29vZCBhbnN3ZXIgdG8gdGhlIHF1ZXN0aW9uICJJcyBwZXJ2YXNpdmUgbW9uaXRvcmluZw0K
PiByZWxldmFudA0KPiA+ICAgIHRvIHRoaXMgd29yayBhbmQgaWYgc28sIGhvdyBoYXMgaXQgYmVl
biBjb25zaWRlcmVkPyINCj4gPg0KPiA+ICAgICAgW+KApl0NCj4gPg0KPiA+ICAgIEluIHBhcnRp
Y3VsYXIsIGFyY2hpdGVjdHVyYWwgZGVjaXNpb25zLCBpbmNsdWRpbmcgd2hpY2ggZXhpc3RpbmcN
Cj4gPiAgICB0ZWNobm9sb2d5IGlzIHJldXNlZCwgbWF5IHNpZ25pZmljYW50bHkgaW1wYWN0IHRo
ZSB2dWxuZXJhYmlsaXR5DQo+IG9mIGENCj4gPiAgICBwcm90b2NvbCB0byBQTS4gIFRob3NlIGRl
dmVsb3BpbmcgSUVURiBzcGVjaWZpY2F0aW9ucyB0aGVyZWZvcmUNCj4gbmVlZA0KPiA+ICAgIHRv
IGNvbnNpZGVyIG1pdGlnYXRpbmcgUE0gd2hlbiBtYWtpbmcgYXJjaGl0ZWN0dXJhbCBkZWNpc2lv
bnMuDQo+ID4gICAgR2V0dGluZyBhZGVxdWF0ZSwgZWFybHkgcmV2aWV3IG9mIGFyY2hpdGVjdHVy
YWwgZGVjaXNpb25zDQo+IGluY2x1ZGluZw0KPiA+ICAgIHdoZXRoZXIgYXBwcm9wcmlhdGUgbWl0
aWdhdGlvbiBvZiBQTSBjYW4gYmUgbWFkZSBpcyBpbXBvcnRhbnQuDQo+ID4gICAgUmV2aXNpdGlu
ZyB0aGVzZSBhcmNoaXRlY3R1cmFsIGRlY2lzaW9ucyBsYXRlIGluIHRoZSBwcm9jZXNzIGlzDQo+
IHZlcnkNCj4gPiAgICBjb3N0bHkuDQo+ID4NCj4gPiBBcyBwZXIgUkZDIDcyNTggaGVyZSB0aGUg
Zm9ybWFsIHF1ZXN0aW9uOg0KPiA+DQo+ID4gSXMgcGVydmFzaXZlIG1vbml0b3JpbmcgcmVsZXZh
bnQgdG8gdGhlIGRlc2lnbiBjaG9pY2VzIG1hZGUgZm9yIHRoZQ0KPiBRVUlDIGNvbm5lY3Rpb24g
SUQsIGFuZCBpZiBzbywgaG93IGhhcyBpdCBiZWVuIGNvbnNpZGVyZWQ/DQo+ID4NCj4gPiBBIGdv
b2QgcGxhY2UgdG8gYW5zd2VyIG1heSBiZSBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rp
b24gaW4NCj4gZHJhZnQtdHN2d2ctcXVpYy1wcm90b2NvbC4NCj4gPg0KPiA+IEluIGdlbmVyYWws
IEkgcGVyc29uYWxseSBiZWxpZXZlIHRoYXQgdGhpcyB0b3BpYyBzaG91bGQgYmUgYWRkcmVzc2Vk
DQo+IHByaW9yIHRvIHRoZSBCb0YgYW5kIG5vdCBhZnRlciB0aGUgV0cgaXMgZm9ybWVkLiBCdXQg
dGhpcyBmb3JtYWwNCj4gcXVlc3Rpb24gaXMgYWJvdmUgbXkgSUVURiBwYXlncmFkZS4NCj4gPg0K
PiA+IE1pY2hhZWwNCj4gPg0KPiA+DQo+ID4gRnJvbTogSmFuYSBJeWVuZ2FyIFttYWlsdG86anJp
QGdvb2dsZS5jb21dDQo+ID4gU2VudDogU2F0dXJkYXksIE1heSAyMSwgMjAxNiA2OjA1IFBNDQo+
ID4gVG86IFJ5YW4gSGFtaWx0b24NCj4gPiBDYzogcXVpY0BpZXRmLm9yZzsgU2NoYXJmLCBNaWNo
YWVsIChOb2tpYSAtIERFKQ0KPiA+IFN1YmplY3Q6IFJlOiBbUVVJQ10gUVVJQyBwcml2YWN5IGlt
cGFjdA0KPiA+DQo+ID4gVGhhdCdzIGEgZGVzaWduIGVsZW1lbnQgdGhhdCBzaG91bGQgYW5kIHdp
bGwgZGVmaW5pdGVseSBiZSBkaXNjdXNzZWQNCj4gaW4gdGhlIFdHLg0KPiA+DQo+ID4gU3BlY2lm
aWNhbGx5IHRoaXMgYXBwbGllcyB0byB1c2Ugb2YgY29ubmVjdGlvbiBJRHMgZHVyaW5nIG11bHRp
cGF0aCwNCj4gYW5kIEkgZXhwZWN0IHRoYXQgY29udmVyc2F0aW9uIHRvIGhhcHBlbiB3aGVuIHdl
IGRpc2N1c3MgbXVsdGlwYXRoLg0KPiA+DQo+ID4gT24gTWF5IDIxLCAyMDE2IDY6NTYgQU0sICJS
eWFuIEhhbWlsdG9uIiA8cmNoQGdvb2dsZS5jb20+IHdyb3RlOg0KPiA+IERlZmluaXRlbHkuDQo+
ID4NCj4gPiBPbiBGcmksIE1heSAyMCwgMjAxNiBhdCAxMToyNiBQTSwgU2NoYXJmLCBNaWNoYWVs
IChOb2tpYSAtIERFKQ0KPiA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPiB3cm90ZToNCj4gPiBJ
cyBpdCBwbGFubmVkIHRvIGRpc2N1c3MgcG90ZW50aWFsIHByaXZhY3kgaW1wbGljYXRpb25zIG9m
IHRoZSDigJ5RVUlDDQo+IGNvbm5lY3Rpb24gaWRlbnRpZmllcuKAnCAoYWxzbyBuYW1lZCDigJxj
bGVhciB0ZXh0IHN1cGVyIGNvb2tpZeKAnSBvbiB0aGUNCj4gU1BVRCBsaXN0KT8NCj4gPg0KPiA+
IFRoYW5rcw0KPiA+DQo+ID4gTWljaGFlbA0KPiA+DQo+ID4NCj4gPiBGcm9tOiBRVUlDIFttYWls
dG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRVhUIFRlZCBIYXJkaWUNCj4g
PiBTZW50OiBTYXR1cmRheSwgTWF5IDE0LCAyMDE2IDE6MjcgQU0NCj4gPiBUbzogcXVpY0BpZXRm
Lm9yZzsgSmFuYSBJeWVuZ2FyOyBDaHJpc3RpYW4gSHVpdGVtYQ0KPiA+IFN1YmplY3Q6IFtRVUlD
XSBEcmFmdCBjaGFydGVyDQo+ID4NCj4gPiBIb3dkeSwNCj4gPg0KPiA+IEFzIHBhcnQgb2YgdGhl
IEJvRiBwcmVwYXJhdGlvbiwgd2UgcHV0IHRvZ2V0aGVyIGEgc3RhYiBhdCBhIGRyYWZ0DQo+IGNo
YXJ0ZXIuICBJdCdzIGF2YWlsYWJsZSBhcyBodG1sIGFuZCBtYXJrZG93biBvbiBnaXRodWIgYXQ6
DQo+ID4NCj4gPiBodHRwczovL2dpdGh1Yi5jb20vSUVURi1RVUlDL0NoYXJ0ZXINCj4gPg0KPiA+
IEkndmUgYXR0YWNoZWQgdGhlIEhUTUwgdmVyc2lvbiBhcyB3ZWxsLg0KPiA+DQo+ID4gSXQgd291
bGQgYmUgZ3JlYXQgdG8gaGF2ZSBzb21lIG9mIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGJl
Zm9yZQ0KPiB0aGUgQm9GLiAgQ29tbWVudHMgdG8gdGhlIGxpc3Qgb3IgaXNzdWVzL3B1bGwgcmVx
dWVzdHMgYXQgdGhlIGdpdGh1Yg0KPiByZXBvIGFyZSB3ZWxjb21lLiAgV2Ugd2lsbCBwZXJpb2Rp
Y2FsbHkgcmVmbGVjdCBhbnkgaXNzdWVzIG9yDQo+IHN1Z2dlc3Rpb24gZnJvbSB0aGUgUmVwbyBi
YWNrIHRvIHRoZSBsaXN0LCBidXQgdGhpcyB3aWxsIGJlIG1hbnVhbCwgc28NCj4gZXhwZWN0IHNv
bWUgbGFnLg0KPiA+DQo+ID4gcmVnYXJkcywNCj4gPg0KPiA+IFRlZA0KPiA+DQo+ID4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBRVUlDIG1haWxp
bmcgbGlzdA0KPiA+IFFVSUNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL3F1aWMNCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IFFVSUMgbWFpbGluZyBsaXN0DQo+ID4g
UVVJQ0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
cXVpYw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gPiBRVUlDIG1haWxpbmcgbGlzdA0KPiA+IFFVSUNAaWV0Zi5vcmcNCj4gPiBodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3F1aWMNCg0K


From nobody Sun May 22 17:09:08 2016
Return-Path: 
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 D603512D52F for ; Sun, 22 May 2016 17:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 sKJrV4ex--6t for ; Sun, 22 May 2016 17:09:04 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 B55CC12D140 for ; Sun, 22 May 2016 17:09:04 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id t145so9129225qke.2 for ; Sun, 22 May 2016 17:09:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=Ysuw3vsgAf4lECbyhkqq5LoREtq6jV1Q1zmD3NA4PH4=; b=cPvq0vkAoQ3RTq6iFaiCB8cNXPdNLkvWDHsdxwHuGBtS1ZvP3j0RqzsAwTs3lXPFwQ +9nhBFHOy0eCzCg2GWy4siwVyfsjqjA0oI6op8/c2psTD2CVWLkl42nUltn+cLOgOXI8 vSyJYJe3cqlYgjdqmy2ipfbhvIbwQ87vW/NbA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=Ysuw3vsgAf4lECbyhkqq5LoREtq6jV1Q1zmD3NA4PH4=; b=l7Jhk94hyRc4k3zl6nEAtIy2SPdczS0pmKKiy1Hlb9B/K6aYvDmsA/8Va6l9M+yIux 9MDTb6QbpIOH+ZGsqYxaCg0IL5+1sAU0sN+ISB2VtNPo6mw5C4/P5uZXGmPjydS6IwU5 TTzO1r5QRIE+0qPT+yl2lWpXN0ETziTapgYH81e3zdFkf15RXrq2VmhkpV28peONDMV1 nxljQWP9JdtW4ZTen+1YZdHiyZsH+smoAIstzfUDtlZJV30tfs7cTqIEVrHSMOw6GJD4 9B1Ak+6jHbY7MTal1v073iAP7OYNIJ0WR+/hyn1wLvhxI8iyINXbXoYQm6hQtQ3HgRh/ b03A==
X-Gm-Message-State: AOPr4FVyGizpipKO6I9SaFJPIEw6kOSmZtM56/CH3G+8ke38A7xdzJrXSv/nYWZTx4K/VpriCyKyD1wRElqBYw==
MIME-Version: 1.0
X-Received: by 10.55.76.84 with SMTP id z81mr13748253qka.17.1463962143678; Sun, 22 May 2016 17:09:03 -0700 (PDT)
Received: by 10.55.96.130 with HTTP; Sun, 22 May 2016 17:09:03 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:94e5:5686:315b:151a]
In-Reply-To: <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>
Date: Sun, 22 May 2016 20:09:03 -0400
Message-ID: 
From: Kyle Rose 
To: Brian Trammell 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Jana Iyengar , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 00:09:07 -0000

> There are, of course, ways to make such a connection ID be useful as such=
 to the endpoints without exposing that linkability to the network (off the=
 top of my head, by having the connection ID given a 4-typle be algorithmic=
ally derivable from any other {4-tuple, connection-id} and a shared secret =
derived from the session key).

I'm not sure this is sufficient in all cases. When roaming, active
connections can be correlated through traffic analysis, as one flow
will suddenly cease at the moment another becomes active; when load
balancing, the start and the end of the connection will cause all
flows to start and stop simultaneously. (Smoke =3D> fire.)

If you want to achieve anonymity of flows, I think a necessary (but
probably still insufficient) constraint is for the connection ID in
every packet to appear unique to a passive observer.

That having been said, I'm still not sure that completely privacy on
the public internet (that is, at the routing layer) is really
possible: once your privacy requirements are strong enough, something
like TOR with added chaff to throw off traffic analysis may be the
only real option.

Kyle


From nobody Sun May 22 21:23:09 2016
Return-Path: 
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 52D0812D62A for ; Sun, 22 May 2016 21:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 DvBxyVIZ1cfo for ; Sun, 22 May 2016 21:23:06 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0588612D628 for ; Sun, 22 May 2016 21:23:05 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 94C9022E257; Mon, 23 May 2016 00:22:57 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Mon, 23 May 2016 14:22:55 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch> 
To: Kyle Rose 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Ryan Hamilton , Brian Trammell , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" , Jana Iyengar 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 04:23:08 -0000

Shooting for perfect privacy is always going to fail.

What we should be aiming for is no worse than TCP -- having stable, =
well-understood behaviour is the important thing here. The Internet (and =
the Web) is a platform that people both design for and use with certain =
assumptions in mind; we shouldn't violate them without very carefully =
weighing the impact.

Making it better than TCP would be a good outcome too, of course.

It would be nice to have something in the charter stating "no worse than =
TCP" for privacy and possibly other properties as well.

Cheers,


> On 23 May 2016, at 10:09 AM, Kyle Rose  wrote:
>=20
>> There are, of course, ways to make such a connection ID be useful as =
such to the endpoints without exposing that linkability to the network =
(off the top of my head, by having the connection ID given a 4-typle be =
algorithmically derivable from any other {4-tuple, connection-id} and a =
shared secret derived from the session key).
>=20
> I'm not sure this is sufficient in all cases. When roaming, active
> connections can be correlated through traffic analysis, as one flow
> will suddenly cease at the moment another becomes active; when load
> balancing, the start and the end of the connection will cause all
> flows to start and stop simultaneously. (Smoke =3D> fire.)
>=20
> If you want to achieve anonymity of flows, I think a necessary (but
> probably still insufficient) constraint is for the connection ID in
> every packet to appear unique to a passive observer.
>=20
> That having been said, I'm still not sure that completely privacy on
> the public internet (that is, at the routing layer) is really
> possible: once your privacy requirements are strong enough, something
> like TOR with added chaff to throw off traffic analysis may be the
> only real option.
>=20
> Kyle
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic

--
Mark Nottingham   https://www.mnot.net/


From nobody Sun May 22 21:27:41 2016
Return-Path: 
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 9583212D62D for ; Sun, 22 May 2016 21:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 jLVLiy-v4v_z for ; Sun, 22 May 2016 21:27:38 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3197212D625 for ; Sun, 22 May 2016 21:27:38 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C5B1422E1FA; Mon, 23 May 2016 00:27:36 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Mon, 23 May 2016 14:27:34 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Jana Iyengar 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: quic@ietf.org
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 04:27:39 -0000

Hi Jana,

That's a good clarification.

The word "negotiation" can be read as a certain style of protocol =
operation by some people; could you just say "protocol versioning and =
configuration"?

Cheers,


> On 18 May 2016, at 10:37 AM, Jana Iyengar  wrote:
>=20
> Greetings,
>=20
> I am modifying the charter text that currently says "loss detection =
and recovery, congestion control, and negotiation" to say "loss =
detection and recovery, congestion control, version negotiation, and =
option negotiation", and I wanted to clarify the roles of version =
negotiation and option negotiation in the current version of QUIC, since =
it may be a source of a bit of confusion.
>=20
> Version negotiation is used for determining how to read and parse a =
QUIC packet. Any "on-the-wire" change to the core protocol or generally =
any change that impacts interoperability results in a version change. =
Version negotiation, as described in Section 7.1 of =
draft-tsvwg-quic-protocol-02, allows the two ends to agree on the =
version to use for communication. This is, as Christian puts it, a =
"blunt" instrument, and it should be treated as such. Versioning is not =
generally intended to be used for negotiating the equivalent of TCP =
options. The expectation is that versioning will also allow continued =
experimentation with QUIC.
>=20
> I believe that no current IETF transport has versioning.
>=20
> In addition to versioning, QUIC currently exchanges transport =
parameters -- the equivalent of TCP options -- during the handshake. =
This is described, though not in much detail, in Section 9 of =
draft-quic-protocol-02. Examples of things that may be negotiated via =
these parameters include max open streams, among other things. This =
mechanism may be used for negotiating features as well, such as use of =
multipath.
>=20
> The initial drafts will contain both of these mechanisms.
>=20
> - jana
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic

--
Mark Nottingham   https://www.mnot.net/


From nobody Sun May 22 21:32:11 2016
Return-Path: 
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 D32DF12D62F for ; Sun, 22 May 2016 21:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 sFSCM7vnWi5F for ; Sun, 22 May 2016 21:32:04 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB52512D62D for ; Sun, 22 May 2016 21:32:04 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4186122E253; Mon, 23 May 2016 00:32:02 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A2A80998D@bgb01xud1012>
Date: Mon, 23 May 2016 14:32:00 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <509EC821-B796-40A6-AE6D-C175D0F7F888@mnot.net>
References: <7CF7F94CB496BF4FAB1676F375F9666A2A80998D@bgb01xud1012>
To: Lucas Pardue 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] Supporting HTTP/2 extension: frames and semantics
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 04:32:11 -0000

+1; I share this concern. There are a growing number of H2 extensions =
that are either in progress [1] or coming [2][3]; it would be good to =
avoid too much of a mess here.

The same question arises for SETTINGSes.

Cheers,

1. https://httpwg.github.io/http-extensions/origin-frame.html
2. =
https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs
3. https://datatracker.ietf.org/doc/draft-kazuho-h2-cache-digest



> On 21 May 2016, at 1:22 AM, Lucas Pardue  =
wrote:
>=20
> Hello,
> =20
> I would like to gain further clarification on the mapping of HTTP/2 =
frames in QUIC, especially with regards to extension via new frame =
types. Is it anticipated that HTTP/2 extension frame types will be =
supported in QUIC and is there a feeling about how that would be =
defined?
> =20
> Previous QUIC documents have covered how to map HTTP/2 frame types =
such as HEADERS or DATA, however there was little explanation of how =
something like the ALTSVC frame [1] would be supported in QUIC (if at =
all). In the specific case of HTTP Alternative Services we can fallback =
on the header field crutch and use Alt-Svc to express the same service =
detail within a HEADERS frame. However, this does not hold true for =
other extensions such as the ORIGIN frame [2].
> =20
> I am also interested in understanding how QUIC might handle HTTP =
semantic extension such as proposed in the Peer-to-Peer Extension to =
HTTP/2 [3].
> =20
> Lucas
> =20
> [1] https://tools.ietf.org/html/rfc7838
> [2] https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/
> [3] https://tools.ietf.org/html/draft-benfield-http2-p2p
> =20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic

--
Mark Nottingham   https://www.mnot.net/


From nobody Sun May 22 21:38:40 2016
Return-Path: 
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 2610E12D62D for ; Sun, 22 May 2016 21:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 1MLjMe-cgr8u for ; Sun, 22 May 2016 21:38:37 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 4F54F12D62F for ; Sun, 22 May 2016 21:38:34 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id n129so57444312wmn.1 for ; Sun, 22 May 2016 21:38:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iSoeOqQOBuRGL+ZJTzCUmJSXmsSehvm6y3ithuina7I=; b=kB8xMQSP/ej5WVkXb/yMDNVPxcrSwhOCNG7YGl/3jhnlt3W9dXQOakzqUaDm1uP2Xk dCvF9VeVhXzJTerud+CKTdw98VCZxjWZj0NyTuRNFNiVKsZCwf+R2sa8JBHUCZEKF40A eOToyPkkHfodeyST4k8VNLTHqxADZ31vzjp6ZzVpE/r8dhJLeyr/L1lmOpp5T44hXBbW 9x+lkT+SVZ2fkhOY2RHzTy+icAr1rgoFfGu63B3Qi8zKOaf1a84kCbBy50OzcL+QPWvp OklKi0gvjT2U7KCjLspUpNXCm95Q+hFp7M+YOee65OuGmCfeQd8cDnZXMXacxKz2+6Ky E2VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iSoeOqQOBuRGL+ZJTzCUmJSXmsSehvm6y3ithuina7I=; b=aPortGk9iMkmqqTK1Hk5+s3VEDRWLLyJSlJdkXRxqoVJz+FwwUeHZj6kZHhAZClAna ZLOEx1yKe/lu706KaX3qHmKen4f09OMoBrtthHHwY2AHC06QP9vc85vb3CsqFAQRE4IA +RUE9G+eKQhGt56YRt/0wP8jgmRPXZFASnnJ80pLpCYv/dpj+BWvLYUMT9nPbGWrEY3u wh1bycjCN9ccsv9FV9YyT2hlDC4qxyPCwu4ZOiu26RpKj+ktOZiODK9OROq7lpdGomLJ 0LPQujWMIwMhZ5+bn8tjJoVtlE108A1DZdOiorh7II2Xmb6zkyOEID2SIP83b5F/pGCB HKeg==
X-Gm-Message-State: AOPr4FWTrpRW1Q52ITMxmC04ThBYQbySdDTNV8BawWBgc/VdnDqzMc3EDc/mYPqpMEWfAKnkc/ufHNIIoqbdixM2
X-Received: by 10.194.205.105 with SMTP id lf9mr14116867wjc.25.1463978312672;  Sun, 22 May 2016 21:38:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.46.151 with HTTP; Sun, 22 May 2016 21:38:31 -0700 (PDT)
In-Reply-To: <509EC821-B796-40A6-AE6D-C175D0F7F888@mnot.net>
References: <7CF7F94CB496BF4FAB1676F375F9666A2A80998D@bgb01xud1012> <509EC821-B796-40A6-AE6D-C175D0F7F888@mnot.net>
From: Ryan Hamilton 
Date: Sun, 22 May 2016 21:38:31 -0700
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=047d7b874c2449795005337b039e
Archived-At: 
Cc: Lucas Pardue , "quic@ietf.org" 
Subject: Re: [QUIC] Supporting HTTP/2 extension: frames and semantics
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 04:38:39 -0000

--047d7b874c2449795005337b039e
Content-Type: text/plain; charset=UTF-8

Agreed. Do you have any suggestions for language we could include in the
charter to ensure that this gets addressed satisfactorily?

On Sun, May 22, 2016 at 9:32 PM, Mark Nottingham  wrote:

> +1; I share this concern. There are a growing number of H2 extensions that
> are either in progress [1] or coming [2][3]; it would be good to avoid too
> much of a mess here.
>
> The same question arises for SETTINGSes.
>
> Cheers,
>
> 1. https://httpwg.github.io/http-extensions/origin-frame.html
> 2. https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs
> 3. https://datatracker.ietf.org/doc/draft-kazuho-h2-cache-digest
>
>
>
> > On 21 May 2016, at 1:22 AM, Lucas Pardue  wrote:
> >
> > Hello,
> >
> > I would like to gain further clarification on the mapping of HTTP/2
> frames in QUIC, especially with regards to extension via new frame types.
> Is it anticipated that HTTP/2 extension frame types will be supported in
> QUIC and is there a feeling about how that would be defined?
> >
> > Previous QUIC documents have covered how to map HTTP/2 frame types such
> as HEADERS or DATA, however there was little explanation of how something
> like the ALTSVC frame [1] would be supported in QUIC (if at all). In the
> specific case of HTTP Alternative Services we can fallback on the header
> field crutch and use Alt-Svc to express the same service detail within a
> HEADERS frame. However, this does not hold true for other extensions such
> as the ORIGIN frame [2].
> >
> > I am also interested in understanding how QUIC might handle HTTP
> semantic extension such as proposed in the Peer-to-Peer Extension to HTTP/2
> [3].
> >
> > Lucas
> >
> > [1] https://tools.ietf.org/html/rfc7838
> > [2] https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/
> > [3] https://tools.ietf.org/html/draft-benfield-http2-p2p
> >
> > _______________________________________________
> > QUIC mailing list
> > QUIC@ietf.org
> > https://www.ietf.org/mailman/listinfo/quic
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>

--047d7b874c2449795005337b039e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Agreed. Do you have any suggestions for language we could =
include in the charter to ensure that this gets addressed satisfactorily?

On Sun,=
 May 22, 2016 at 9:32 PM, Mark Nottingham <mnot@mnot.net> wrote:=

+1; I share this concern. There are a gr=
owing number of H2 extensions that are either in progress [1] or coming [2]=
[3]; it would be good to avoid too much of a mess here.



The same question arises for SETTINGSes.



Cheers,



1. https://httpwg.github.io/http-extension=
s/origin-frame.html

2. https://tools.ietf.org/htm=
l/draft-bishop-httpbis-http2-additional-certs

3. https://datatracker.ietf.org/doc/dra=
ft-kazuho-h2-cache-digest








> On 21 May 2016, at 1:22 AM, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:

>

> Hello,

>

> I would like to gain further clarification on the mapping of HTTP/2 fr=
ames in QUIC, especially with regards to extension via new frame types. Is =
it anticipated that HTTP/2 extension frame types will be supported in QUIC =
and is there a feeling about how that would be defined?

>

> Previous QUIC documents have covered how to map HTTP/2 frame types suc=
h as HEADERS or DATA, however there was little explanation of how something=
 like the ALTSVC frame [1] would be supported in QUIC (if at all). In the s=
pecific case of HTTP Alternative Services we can fallback on the header fie=
ld crutch and use Alt-Svc to express the same service detail within a HEADE=
RS frame. However, this does not hold true for other extensions such as the=
 ORIGIN frame [2].

>

> I am also interested in understanding how QUIC might handle HTTP seman=
tic extension such as proposed in the Peer-to-Peer Extension to HTTP/2 [3].=


>

> Lucas

>

> [1] https://tools.ietf.org/html/rfc7838

> [2] https://datatracker.ietf.o=
rg/doc/draft-ietf-httpbis-origin-frame/

> [3] https://tools.ietf.org/html/draft-benfi=
eld-http2-p2p

>


> _________________________________________=
______

> QUIC mailing list

> QUIC@ietf.org

> https://www.ietf.org/mailman/listinfo/quic



--

Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/




_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--047d7b874c2449795005337b039e--


From nobody Sun May 22 23:30:27 2016
Return-Path: 
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 CDA4812D12C for ; Sun, 22 May 2016 23:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 4hr2T1AkgQER for ; Sun, 22 May 2016 23:30:24 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D411512B010 for ; Sun, 22 May 2016 23:30:23 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 480D022E1FA; Mon, 23 May 2016 02:30:15 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Mon, 23 May 2016 16:30:14 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>
References: 
To: Ted Hardie 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , quic@ietf.org, Christian Huitema 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 06:30:27 -0000

Hi Ted,

Thanks, I can see where you (and Jana) are coming from, definitely.

If we assume that the vast bulk of the work is in defining the semantics =
of the transport (as many have said, building the functionality of TCP =
on top of UDP), it makes a lot of sense to do the work in Transport, =
even though to date, application protocols have lived in APPS/ART.

However, there's a latent decision in there -- that the next version of =
HTTP is only a change to transport, not to core semantics.

That may very well be the right decision to make, but it seems like it =
needs to be a very conscious one within the HTTP community (realising =
that the set of HTTP-focused people who choose to come to these =
discussions is smaller than that). There has been some discussion about =
making more bold changes in HTTP/3, and I think it's important to make =
sure there's buy-in about the scope of work, especially since doing it =
this way could effectively put such changes off the table for a fair =
amount of time (revving the protocol too often discourages deployment =
and investment).

I think we can do that by having a discussion in the HTTP WG, with some =
input from other HTTP implementers too. I'm happy to help facilitate =
that if you like.

I'll try to suggest some charter text separately regarding HTTP =
semantics.

One other thing - the rationale you gives makes a lot of sense for HTTP, =
as the "original" use case for QUIC. I'm not sure it does for further =
application mappings. If QUIC is going to be a successful =
transport(-ish) protocol, shouldn't other protocols be able to use it =
without coordination, and without being defined inside a "super-group"?

Cheers,


> On 18 May 2016, at 8:14 AM, Ted Hardie  wrote:
>=20
> I've changed the subject on this, since I want to focus on a =
particular topic.
>=20
> Comments in-line:
>=20
> On Tue, May 17, 2016 at 12:23 PM, Jana Iyengar  wrote:
> Thanks, Mark. Responses inline:
>  The third focus area will describe mappings between specific =
applications=E2=80=99 semantics and the transport facilities of QUIC. =
The first mapping will be a description of HTTP/2 semantics using QUIC, =
specifically with the goal of minimizing web latency using QUIC. Upon =
completion of that mapping, additional protocols may be added by =
updating this charter to include them.
>=20
>=20
> Defining application protocols in the Transport area is a pretty big =
change around here, even if it is just mapping existing semantics to a =
new transport.
>=20
> As everyone knows, such mappings are "leaky" -- changes under the hood =
can and will affect how people use the application. We had numerous =
examples of this in H2, and while QUIC appears to be a more =
straightforward change in this respect, it's still easy enough to have =
unintended side effects. HTTP is especially fragile in this regard, =
because of its complexity, history and breadth of use.
>=20
> Note that I'm not saying I'm firmly against this approach, just =
concerned; this WG is obviously going to be very deep in transport =
discussions, and it would be easy to lose the application perspective in =
it.
>=20
>=20
> I think you're right that this is a serious concern, but my thinking =
is that we have this concern either way.  You could avoid that by =
serializing the transport work to finish before any mapping started, but =
that would be slow.  It would also risk the transport developing without =
the driving use case focus that has helped the pre-standards work =
progress. =20
>=20
> If we try to do the mapping work in a different/area working group =
while the transport work is still ongoing, we need a very tight =
coordination between the two groups throughout the work.  Basically, =
everyone interested will have to be in both; given that it will not be =
the only topic in either group, that's going to be distracting as well =
as logistically difficult. =20
>=20
> If you're not willing to serialize,  in other words, I think you have =
to pick one to have the work.  Given that QUIC will eventually have more =
than one mapping, I think it makes sense to do it in a working group =
focused on QUIC.  There is no question that a QUIC working group with =
this charter would need the eyes of an HTTP-focused set of contributors =
for this mapping.  To some extent, that means we're asking the =
indulgence of the HTTP-focused community for splitting their attention =
for a time; ultimately, though, I think they would have had to do that =
anyway.
> =20
> Also, if this WG *is* to do the HTTP/2 mapping, more text about what =
semantics are being mapped would avoid a lot of argument down the road; =
if you say it's "all of them", that includes running HTTP without TLS.
>=20
> =20
> I think the intent is to cover HTTP/2 semantics for an encrypted =
transport, but further assistance in conveying that would be gratefully =
received.
>=20
> > Milestones
>=20
> It would be helpful to also propose the timing of the milestones, =
perhaps in the form of "date of chartering + n months."
>=20
> That's a great idea; I didn't want to put in dates when I didn't have =
a start date in hand, but we'll try to put a strawman together with that =
approach.
> =20
> regards,
>=20
> Ted

--
Mark Nottingham   https://www.mnot.net/


From nobody Mon May 23 00:28:30 2016
Return-Path: 
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 E661112D099 for ; Mon, 23 May 2016 00:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 pM-ZRTUm_dHk for ; Mon, 23 May 2016 00:28:27 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 0AF5B128B44 for ; Mon, 23 May 2016 00:28:26 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id a136so6129976wme.0 for ; Mon, 23 May 2016 00:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=qNJ4IAr1hfrAG6y6yWYs8uCmgO5XMrx8LMsm/BqA0W0=; b=Idr6Qn6lVTTg4mvWe0aBgXljpZTO9W9FYB+IdEue6zhnEGs2PNX7w9p83HY9uY+FlZ w1+q3/XyW6vyBbu1AT2Kd44A1g0CzCu0TKuLuBxSs31ECsGy9FZXNCXJPRxM5/XtppY5 sJ9hRtd05MkOm1vF1N+A8iAx3djkaXa9oyup2u7Yos4+eJpPJUwm5/txTUeJuyiPh79m 2TjbdrVn8/Vq5kaIvxwhDxPDEYV3vDNyVIvIXFgTUAgjDE6ZFrOH2ck3GgUgENaEHIH2 pLGxrdX/GQoLF4u0ksYc6JqGCO3Z4TOQNJOFqa6fN0eikENhXaJG3o4hid43AexfAuV5 zcfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qNJ4IAr1hfrAG6y6yWYs8uCmgO5XMrx8LMsm/BqA0W0=; b=kUrGh+rNUmt7uPHs0g814nEFu7DEL+Vc6Uhi0tPJHitAknSx1YXs32kae+dZhlP+wm ssOMTJeJoefpwO3dCp5N6nlZ7WFn9T9EKn2yBphb6mpguVudv7SkBo7DKRKi2PnOVmEN /2PBQYL+x/RHjyPUwPjGfdVTMY1pNwuJF+Q5uOCnBuz62nRcbX6k7U8St71ztyUWukRC u4hL/bdEnfXg2+/Mmi/rphWoss5DTyNkektnSgCp1phIruUPtxbjtsz4Ak05uO3OichH +YmIqPpHRkxPdjNd6Vno8EL1HnFUtMcczZKEneThSDYFw9IeZnf6Um617lUBm7S+E8F3 5lTQ==
X-Gm-Message-State: AOPr4FWmLrn4hzhbSXkQ/z837L1LaOmfHQ9BUAuuuDhWzdGsC6Eg/A8d+CM+K/5nfFU/NSGqepLDWfLJptZ3yQkbIoBXZ/5iJ46TSpViahzFjhoLayCM0y7M
X-Received: by 10.28.92.18 with SMTP id q18mr16540949wmb.48.1463988505447; Mon, 23 May 2016 00:28:25 -0700 (PDT)
Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be. [78.129.6.94]) by smtp.gmail.com with ESMTPSA id u4sm33719307wjz.4.2016.05.23.00.28.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 00:28:24 -0700 (PDT)
To: Mark Nottingham , Kyle Rose 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>
From: Olivier Bonaventure 
Message-ID: 
Date: Mon, 23 May 2016 09:28:23 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Brian Trammell , Jana Iyengar , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 07:28:29 -0000

Mark,

> Shooting for perfect privacy is always going to fail.

I totally agree

> What we should be aiming for is no worse than TCP -- having stable, well-=
understood behaviour is the important thing here. The Internet (and the Web=
) is a platform that people both design for and use with certain assumption=
s in mind; we shouldn't violate them without very carefully weighing the im=
pact.
>
> Making it better than TCP would be a good outcome too, of course.
>
> It would be nice to have something in the charter stating "no worse than =
TCP" for privacy and possibly other properties as well.

This is exactly the type of wording that we should have in the charter=20
for various mechanisms that already exist and are/will be included in QUIC.

For congestion control, QUIC should reuse the existing (single-path and=20
multipath) TCP congestion control schemes.

For privacy, QUIC should not be worse than existing transport protocols=20
(TCP, Multipath TCP, SCTP). For Multipath TCP, we took this approach for=20
security and it turned out to be good.

Same applies probably for the security features in relation with TLS 1.3=20
and perhaps HTTP/2 for the API discussion.

Olivier

--=20

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended=
=20
solely for the use of the individual or entity to whom they are addressed.=
=20
If you have received this email in error please notify the system manager.=
=20
This message contains confidential information and is intended only for the=
=20
individual named. If you are not the named addressee you should not=20
disseminate, distribute or copy this e-mail. Please notify the sender=20
immediately by e-mail if you have received this e-mail by mistake and=20
delete this e-mail from your system. If you are not the intended recipient=
=20
you are notified that disclosing, copying, distributing or taking any=20
action in reliance on the contents of this information is strictly=20
prohibited.


From nobody Mon May 23 00:31:36 2016
Return-Path: 
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 297B212D099 for ; Mon, 23 May 2016 00:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 yuF-rKPHh5a1 for ; Mon, 23 May 2016 00:31:34 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 1646112B068 for ; Mon, 23 May 2016 00:31:33 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id k23so57915139oih.0 for ; Mon, 23 May 2016 00:31:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tYWKWuume9iHijJ6E93PBDyAx9WdDCTMzl0NBw7M6C8=; b=ceI+23IVhNFp71rSSqs96FcwkM1I/KIXwTwmCG6ZMJzfr6EpUraYD0a2oQTTGMkiJm 1yFW5MeXmQwQVhHRupvImD0TMmOQErG0kVSKBSk720s0WB37XcF4xUQu84Auc3nsmZg/ dksHCGw395Yu1pSbezrs1z6DcQHhPgmmK0t/V3QzaJlwKMK6V+6MoUIRZIrbQYMkRQYr bXIXfPNa4SO2ntNqFOFMcfo+NfYxGsIYKTcMdq6pjU/bz9G0E7rRFf4J4J6gM5vehy/h AKeflQAVPdeb4irchyZQhcnEOm4OPT2wVUtyYzJYJ1rqnc/YHMNh6RX+vkgNtKaONeTF lszQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tYWKWuume9iHijJ6E93PBDyAx9WdDCTMzl0NBw7M6C8=; b=ZSqLI46DWAW2kGBPSAYy/MJWZQHYQ2xQW2MOLL6E7SWljQQcsFJOQOiwymCT4m9a2z YvIjFtF80Q1b1kQ9qV4AVrw84w0X0OunzaudnieNvZINmPf6Lv3WUZKfeKbrmrmbK6aC Vl0SJfTlZi2nsy+A5ieQi3nBxQKJtWtJfin6VsUIxihxqV4Vi/tDRNop+Zb/ItBRO59O v33cY0PMWstvHXR3+7tTx6XiI/8oLUyMqvJ+i7njPSpLQdZf+/yZa0ebhG0HQv8mlMO5 9itSiIXZ552yHaqBFL9GkHWy2Oon/QpXzZJ5RSngm42oCOzhBbjWk0I99G9IK4hzBxSG 67PQ==
X-Gm-Message-State: AOPr4FUeYPAsiHBcQ1sAG/WqlDniRs0cDm8kSxyE+7FhwuYzgBYfZJN3Hxk6ftHwmFlynCSbfky8teV2P+ahww==
X-Received: by 10.202.98.133 with SMTP id w127mr7299235oib.136.1463988692312;  Mon, 23 May 2016 00:31:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.195.137 with HTTP; Mon, 23 May 2016 00:31:12 -0700 (PDT)
In-Reply-To: <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>
From: Ted Hardie 
Date: Mon, 23 May 2016 03:31:12 -0400
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=001a113d3564f5f55905337d6dd5
Archived-At: 
Cc: Jana Iyengar , quic@ietf.org, Christian Huitema 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 07:31:36 -0000

--001a113d3564f5f55905337d6dd5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Mark,

Thanks for your thoughts on this.  Some additional musing below.

On Mon, May 23, 2016 at 2:30 AM, Mark Nottingham  wrote:

> Hi Ted,
>
> Thanks, I can see where you (and Jana) are coming from, definitely.
>
> If we assume that the vast bulk of the work is in defining the semantics
> of the transport (as many have said, building the functionality of TCP on
> top of UDP), it makes a lot of sense to do the work in Transport, even
> though to date, application protocols have lived in APPS/ART.
>
> However, there's a latent decision in there -- that the next version of
> HTTP is only a change to transport, not to core semantics.
>
> So, that's an interesting question, but not the way I'd understood the
intent here.  My reading of the intent was to map the current HTTP/2
semantics onto QUIC rather than create a new HTTP version.   My mental
model of the relationship was closer to defining HTTP over TLS vs. HTTP
over TCP, rather than shifting from HTTP 1.1. to HTTP/2.

That may be the wrong mental model, and you're quite right that this was a
latent in the description rather than made as a choice between two options.


> That may very well be the right decision to make, but it seems like it
> needs to be a very conscious one within the HTTP community (realising tha=
t
> the set of HTTP-focused people who choose to come to these discussions is
> smaller than that). There has been some discussion about making more bold
> changes in HTTP/3, and I think it's important to make sure there's buy-in
> about the scope of work, especially since doing it this way could
> effectively put such changes off the table for a fair amount of time
> (revving the protocol too often discourages deployment and investment).
>
> I think we can do that by having a discussion in the HTTP WG, with some
> input from other HTTP implementers too. I'm happy to help facilitate that
> if you like.
>
> I very much appreciate your offer to facilitate, and I think the
discussion should definitely occur.


> I'll try to suggest some charter text separately regarding HTTP semantics=
.
>
> One other thing - the rationale you gives makes a lot of sense for HTTP,
> as the "original" use case for QUIC. I'm not sure it does for further
> application mappings. If QUIC is going to be a successful transport(-ish)
> protocol, shouldn't other protocols be able to use it without coordinatio=
n,
> and without being defined inside a "super-group"?
>
> I think after we have a few worked examples, it will be possible to do
without that aspect of this group, much as X over TLS work occurs in
coordination with (rather than inside) TLS.

regards,

Ted

> Cheers,
>
>
> > On 18 May 2016, at 8:14 AM, Ted Hardie  wrote:
> >
> > I've changed the subject on this, since I want to focus on a particular
> topic.
> >
> > Comments in-line:
> >
> > On Tue, May 17, 2016 at 12:23 PM, Jana Iyengar  wrote:
> > Thanks, Mark. Responses inline:
> >  The third focus area will describe mappings between specific
> applications=E2=80=99 semantics and the transport facilities of QUIC. The=
 first
> mapping will be a description of HTTP/2 semantics using QUIC, specificall=
y
> with the goal of minimizing web latency using QUIC. Upon completion of th=
at
> mapping, additional protocols may be added by updating this charter to
> include them.
> >
> >
> > Defining application protocols in the Transport area is a pretty big
> change around here, even if it is just mapping existing semantics to a ne=
w
> transport.
> >
> > As everyone knows, such mappings are "leaky" -- changes under the hood
> can and will affect how people use the application. We had numerous
> examples of this in H2, and while QUIC appears to be a more straightforwa=
rd
> change in this respect, it's still easy enough to have unintended side
> effects. HTTP is especially fragile in this regard, because of its
> complexity, history and breadth of use.
> >
> > Note that I'm not saying I'm firmly against this approach, just
> concerned; this WG is obviously going to be very deep in transport
> discussions, and it would be easy to lose the application perspective in =
it.
> >
> >
> > I think you're right that this is a serious concern, but my thinking is
> that we have this concern either way.  You could avoid that by serializin=
g
> the transport work to finish before any mapping started, but that would b=
e
> slow.  It would also risk the transport developing without the driving us=
e
> case focus that has helped the pre-standards work progress.
> >
> > If we try to do the mapping work in a different/area working group whil=
e
> the transport work is still ongoing, we need a very tight coordination
> between the two groups throughout the work.  Basically, everyone interest=
ed
> will have to be in both; given that it will not be the only topic in eith=
er
> group, that's going to be distracting as well as logistically difficult.
> >
> > If you're not willing to serialize,  in other words, I think you have t=
o
> pick one to have the work.  Given that QUIC will eventually have more tha=
n
> one mapping, I think it makes sense to do it in a working group focused o=
n
> QUIC.  There is no question that a QUIC working group with this charter
> would need the eyes of an HTTP-focused set of contributors for this
> mapping.  To some extent, that means we're asking the indulgence of the
> HTTP-focused community for splitting their attention for a time;
> ultimately, though, I think they would have had to do that anyway.
> >
> > Also, if this WG *is* to do the HTTP/2 mapping, more text about what
> semantics are being mapped would avoid a lot of argument down the road; i=
f
> you say it's "all of them", that includes running HTTP without TLS.
> >
> >
> > I think the intent is to cover HTTP/2 semantics for an encrypted
> transport, but further assistance in conveying that would be gratefully
> received.
> >
> > > Milestones
> >
> > It would be helpful to also propose the timing of the milestones,
> perhaps in the form of "date of chartering + n months."
> >
> > That's a great idea; I didn't want to put in dates when I didn't have a
> start date in hand, but we'll try to put a strawman together with that
> approach.
> >
> > regards,
> >
> > Ted
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>

--001a113d3564f5f55905337d6dd5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Mark,

Thanks for your thoughts on thi=
s.=C2=A0 Some additional musing below.

On Mon, May 23, 2016 at 2:30 AM, Mark Nottingham <=
span dir=3D"ltr"><mno=
t@mnot.net> wrote:
Hi Ted,<=
br>


Thanks, I can see where you (and Jana) are coming from, definitely.



If we assume that the vast bulk of the work is in defining the semantics of=
 the transport (as many have said, building the functionality of TCP on top=
 of UDP), it makes a lot of sense to do the work in Transport, even though =
to date, application protocols have lived in APPS/ART.



However, there's a latent decision in there -- that the next version of=
 HTTP is only a change to transport, not to core semantics.


So, that's an interesting question, but not the w=
ay I'd understood the intent here.=C2=A0 My reading of the intent was t=
o map the current HTTP/2 semantics onto QUIC rather than create a new HTTP =
version.=C2=A0=C2=A0 My mental model of the relationship was closer to defi=
ning HTTP over TLS vs. HTTP over TCP, rather than shifting from HTTP 1.1. t=
o HTTP/2.=C2=A0 

That may be the wrong mental model, and =
you're quite right that this was a latent in the description rather tha=
n made as a choice between two options.
=C2=A0

That may very well be the right decision to make, but it seems like it need=
s to be a very conscious one within the HTTP community (realising that the =
set of HTTP-focused people who choose to come to these discussions is small=
er than that). There has been some discussion about making more bold change=
s in HTTP/3, and I think it's important to make sure there's buy-in=
 about the scope of work, especially since doing it this way could effectiv=
ely put such changes off the table for a fair amount of time (revving the p=
rotocol too often discourages deployment and investment).



I think we can do that by having a discussion in the HTTP WG, with some inp=
ut from other HTTP implementers too. I'm happy to help facilitate that =
if you like.


I very much appreciate your offer to facilitate, and =
I think the discussion should definitely occur. 
=C2=A0

I'll try to suggest some charter text separately regarding HTTP semanti=
cs.



One other thing - the rationale you gives makes a lot of sense for HTTP, as=
 the "original" use case for QUIC. I'm not sure it does for f=
urther application mappings. If QUIC is going to be a successful transport(=
-ish) protocol, shouldn't other protocols be able to use it without coo=
rdination, and without being defined inside a "super-group"?


I think after we have a few worked examples, it will =
be possible to do without that aspect of this group, much as X over TLS wor=
k occurs in coordination with (rather than inside) TLS. 

=

regards,

Ted

Cheers,





> On 18 May 2016, at 8:14 AM, Ted Hardie <ted.ietf@gmail.com> wrote:

>

> I've changed the subject on this, since I want to focus on a parti=
cular topic.

>

> Comments in-line:

>

> On Tue, May 17, 2016 at 12:23 PM, Jana Iyengar <jri@google.com> wrote:

> Thanks, Mark. Responses inline:

>=C2=A0 The third focus area will describe mappings between specific app=
lications=E2=80=99 semantics and the transport facilities of QUIC. The firs=
t mapping will be a description of HTTP/2 semantics using QUIC, specificall=
y with the goal of minimizing web latency using QUIC. Upon completion of th=
at mapping, additional protocols may be added by updating this charter to i=
nclude them.

>

>

> Defining application protocols in the Transport area is a pretty big c=
hange around here, even if it is just mapping existing semantics to a new t=
ransport.

>

> As everyone knows, such mappings are "leaky" -- changes unde=
r the hood can and will affect how people use the application. We had numer=
ous examples of this in H2, and while QUIC appears to be a more straightfor=
ward change in this respect, it's still easy enough to have unintended =
side effects. HTTP is especially fragile in this regard, because of its com=
plexity, history and breadth of use.

>

> Note that I'm not saying I'm firmly against this approach, jus=
t concerned; this WG is obviously going to be very deep in transport discus=
sions, and it would be easy to lose the application perspective in it.

>

>

> I think you're right that this is a serious concern, but my thinki=
ng is that we have this concern either way.=C2=A0 You could avoid that by s=
erializing the transport work to finish before any mapping started, but tha=
t would be slow.=C2=A0 It would also risk the transport developing without =
the driving use case focus that has helped the pre-standards work progress.=


>

> If we try to do the mapping work in a different/area working group whi=
le the transport work is still ongoing, we need a very tight coordination b=
etween the two groups throughout the work.=C2=A0 Basically, everyone intere=
sted will have to be in both; given that it will not be the only topic in e=
ither group, that's going to be distracting as well as logistically dif=
ficult.

>

> If you're not willing to serialize,=C2=A0 in other words, I think =
you have to pick one to have the work.=C2=A0 Given that QUIC will eventuall=
y have more than one mapping, I think it makes sense to do it in a working =
group focused on QUIC.=C2=A0 There is no question that a QUIC working group=
 with this charter would need the eyes of an HTTP-focused set of contributo=
rs for this mapping.=C2=A0 To some extent, that means we're asking the =
indulgence of the HTTP-focused community for splitting their attention for =
a time; ultimately, though, I think they would have had to do that anyway.<=
br>
>

> Also, if this WG *is* to do the HTTP/2 mapping, more text about what s=
emantics are being mapped would avoid a lot of argument down the road; if y=
ou say it's "all of them", that includes running HTTP without=
 TLS.

>

>

> I think the intent is to cover HTTP/2 semantics for an encrypted trans=
port, but further assistance in conveying that would be gratefully received=
.

>

> > Milestones

>

> It would be helpful to also propose the timing of the milestones, perh=
aps in the form of "date of chartering + n months."

>

> That's a great idea; I didn't want to put in dates when I didn=
't have a start date in hand, but we'll try to put a strawman toget=
her with that approach.

>

> regards,

>

> Ted



--

Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/







--001a113d3564f5f55905337d6dd5--


From nobody Mon May 23 00:37:31 2016
Return-Path: 
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 895FD12D099 for ; Mon, 23 May 2016 00:37:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 p5Z3pYnm4qtG for ; Mon, 23 May 2016 00:37:28 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7E112B032 for ; Mon, 23 May 2016 00:37:28 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8B64C22E257; Mon, 23 May 2016 03:37:21 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Mon, 23 May 2016 17:37:18 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net> 
To: Ted Hardie 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , quic@ietf.org, Christian Huitema 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 07:37:30 -0000

> On 23 May 2016, at 5:31 PM, Ted Hardie  wrote:
>=20
>> So, that's an interesting question, but not the way I'd understood =
the intent here.  My reading of the intent was to map the current HTTP/2 =
semantics onto QUIC rather than create a new HTTP version.   My mental =
model of the relationship was closer to defining HTTP over TLS vs. HTTP =
over TCP, rather than shifting from HTTP 1.1. to HTTP/2. =20
>=20
> That may be the wrong mental model, and you're quite right that this =
was a latent in the description rather than made as a choice between two =
options.

AIUI (and please correct me if I'm wrong), the plan is to advertise =
availability of the new mapping using a new ALPN token over Alt-Svc; if =
that's the case, it can't be "h2" because that denotes HTTP/2 over TLS =
over TCP.

Of course, we could define the new thing as "h2-udp".

Cheers,


--
Mark Nottingham   https://www.mnot.net/


From nobody Mon May 23 01:43:11 2016
Return-Path: 
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 C86D412D099 for ; Mon, 23 May 2016 00:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.427
X-Spam-Level: 
X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=kkXgKl1j; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=kkXgKl1j
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 Nt3dVj1PjahF for ; Mon, 23 May 2016 00:41:37 -0700 (PDT)
Received: from mail.greenbytes.de (mail.greenbytes.de [5.10.171.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C65712B032 for ; Mon, 23 May 2016 00:41:36 -0700 (PDT)
Received: by mail.greenbytes.de (Postfix, from userid 117) id CE61815A059F; Mon, 23 May 2016 09:41:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1463989294; bh=ZJaGXdci4KQYJVqC5YeFDlHGlc4BUJCv+57wPzp69uw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=kkXgKl1jUXzNK9Jf3iHgpELnSbwwHCY/Kn4nX760TqUAGCkv7miIg2pVkch3mDvFj rmKV+W3LiYrBYzlNFS0qR+xQCi+VTgz0/cUer5OM88NQ4EhK3ijzW4Zk7HgDZ8EI1H aMWlKx9xEsAj9fX6kx0lgcOvjlPOnirmQItjT6AY=
Received: from [192.168.178.20] (unknown [93.217.124.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id C7FF515A02D6; Mon, 23 May 2016 09:41:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1463989294; bh=ZJaGXdci4KQYJVqC5YeFDlHGlc4BUJCv+57wPzp69uw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=kkXgKl1jUXzNK9Jf3iHgpELnSbwwHCY/Kn4nX760TqUAGCkv7miIg2pVkch3mDvFj rmKV+W3LiYrBYzlNFS0qR+xQCi+VTgz0/cUer5OM88NQ4EhK3ijzW4Zk7HgDZ8EI1H aMWlKx9xEsAj9fX6kx0lgcOvjlPOnirmQItjT6AY=
To: Mark Nottingham , Ted Hardie 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>
From: Julian Reschke 
Message-ID: 
Date: Mon, 23 May 2016 09:41:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
X-Mailman-Approved-At: Mon, 23 May 2016 01:43:09 -0700
Cc: Jana Iyengar , quic@ietf.org, Christian Huitema 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 07:41:39 -0000

On 2016-05-23 08:30, Mark Nottingham wrote:
> Hi Ted,
>
> Thanks, I can see where you (and Jana) are coming from, definitely.
>
> If we assume that the vast bulk of the work is in defining the semantics of the transport (as many have said, building the functionality of TCP on top of UDP), it makes a lot of sense to do the work in Transport, even though to date, application protocols have lived in APPS/ART.
>
> However, there's a latent decision in there -- that the next version of HTTP is only a change to transport, not to core semantics.
> ...

I think it would be unfortunate to couple wire protocol changes with 
application level changes if we don't need to.

Q: do you expect that HTTP over Quic will be negotiated with something 
similar to ALPN, and that we'll need a new token for that?

Best regards, Julian


From nobody Mon May 23 07:15:35 2016
Return-Path: 
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 BE7A112D8DB for ; Mon, 23 May 2016 07:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lukasa-co-uk.20150623.gappssmtp.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 YCgDMAtzBfmF for ; Mon, 23 May 2016 07:15:27 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 20F3612D921 for ; Mon, 23 May 2016 07:15:26 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id n129so73949365wmn.1 for ; Mon, 23 May 2016 07:15:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=5aL/cXwM7mNc1cn9Ct91j0Dz2LUhGdc7IDihM4smbxA=; b=SU3KG+V4AzLzswwS7Wqirn0VjfqW8IqmsAS92AE9Z0DDJh673ZSMwtTPe15snIzJmX vn+RT7xls7ZXEVOZvEb3nHDFXWImsGZaMSefuNBYRrE7m4Hvg4y9Jc59VZQMyf4gmODV kV2g2CxRLCudLBNDovX1K+weOwNQ3aO/ycylLXVYm5GtFNfVozZNafkrWSdw5n0dVFMn nyscvoj9jvDu28jSqpQSQp1/9HHGFsODFyVD8KyhgTQd/fHbdXnIhNMlRJMqNnxzP8CL 4mdCS8LUm1mJZLNJblZaxsXAIhnfKvZEqNJWust3/rAs9aqKJQBxEZ/dmW9aN0aKYy8D KVKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=5aL/cXwM7mNc1cn9Ct91j0Dz2LUhGdc7IDihM4smbxA=; b=YSMOglSYRGYGs9qnDfn6JCYX1SgzRgqOylkL3ofh0prGKobPJ18OCCstKKHxJYnOLz GxtXGiUJfffmZCROTWPI5ZjUc9uUn+DJeYz2CokSjsIDC2TGYE1KfxENK1K/F8JMSkMH DGrVB7XQJQd0QSTaLakQuxeDALKhh8wbGQP2sDVN6JewapDYExpVq7sfN/dpFUkA955R vJluXf27Y5UWel4pD8HsykTrWGupdaVtLuRKa9n/EAouJTppJtJp9IM6H7uPBuvoTLtq 97LwzcvCycGpOHuOxqOLBe7LDZgoQBHRUX57rTvPAFyYPRiHA7vqgy7k+E1bSHlqOCdN frtw==
X-Gm-Message-State: AOPr4FVqsWP/n5FDYKiiDZJGB4ZUDPSqfNAUh5mdXO583uJQh1ObtIxAjd15RMyTtMshZw==
X-Received: by 10.28.217.79 with SMTP id q76mr17181259wmg.83.1464012924492; Mon, 23 May 2016 07:15:24 -0700 (PDT)
Received: from [192.168.1.6] (41.65.125.91.dyn.plus.net. [91.125.65.41]) by smtp.gmail.com with ESMTPSA id jp2sm35611240wjc.16.2016.05.23.07.15.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 May 2016 07:15:23 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_DFAD861C-F7BD-4F4A-B6DE-5040AA0A2C86"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.6b2
From: Cory Benfield 
In-Reply-To: 
Date: Mon, 23 May 2016 15:15:20 +0100
Message-Id: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net> 
To: Julian Reschke 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , Mark Nottingham , quic@ietf.org, Ted Hardie , Christian Huitema 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 14:15:34 -0000

--Apple-Mail=_DFAD861C-F7BD-4F4A-B6DE-5040AA0A2C86
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 23 May 2016, at 08:41, Julian Reschke =
 wrote:
>=20
> I think it would be unfortunate to couple wire protocol changes with =
application level changes if we don't need to.

What does =E2=80=9Capplication level changes=E2=80=9D mean here? My =
understanding is that no-one is planning to make *semantic* changes to =
HTTP as part of this work, but necessarily there is going to be some =
divergence from RFC 7540 if only because the nature of the transport =
will be meaningfully different from TCP.

I would expect that an application that was protected from working with =
HTTP directly, or that works with it at a semantic level (e.g. a Python =
WSGI application) wouldn=E2=80=99t change in response to QUIC, but any =
application that actually speaks HTTP is going to have to change at =
least a little bit.

Cory

--Apple-Mail=_DFAD861C-F7BD-4F4A-B6DE-5040AA0A2C86
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXQxB4AAoJEHD+F/imQ+FbAHUQAKeROBf+k2t0I5J+oRtT+T+/
kJkQmvQ1Wg8PgrLdLBbcsToA717HrqhNN7i+Z76heP0SOoQpCJPdjkp6Tyfdgj5g
fPaIJFlLZognZSgNUe6y9OnsTsBwpvVtHqA4cL9EP9JGl/Onnbrd+yEgtWUFJ234
5OsqjJDWGVYOG3sQaISdsxhTbonfr0XxeN+Bu+If/Fj1bp+yhnQHKBy8+gGcMhm6
uuhdIbONS7M/A2+qpXcBShi8WC/NDRqIvO2T6lm+nKq4a+TfHoy9MNOlVNBKi3s1
xgt2VJjpDrWceJJ3tXlyRzGpJMbDjpSx2gv5LJM0Zks4qyDekbfjXLpDAmwBewcw
I1L3wvwL0HDRrppdLI4Oxk9O+k97qZQezI6h+x+2XdHpahwPHPOns01LQIxN1V3u
RxWofi51W5TgxUSbGye2BZSfKQnQtNDihgGprZoiin5PEvIyneiZHa4XHWrWasml
G53S1XwfeSvfzW7QPFttanzEvjL6xxObfg7lx+r60JMfwQH2ZztXKvYF/Y4Fap/f
1t+Qe8PLRP/i8rIAauaZdPHh9/1459VPNDtVjQzhetIE4WbpQfsBT5uWCbNR1tkD
8k0QDr2QTLv46L2pZ5qcUYDHtgKUACTgcsIxJHJ3REex2PZcL9b4qfXgGzZQhF76
GNl5VfzR1ueIJFZk61NN
=Lt4R
-----END PGP SIGNATURE-----

--Apple-Mail=_DFAD861C-F7BD-4F4A-B6DE-5040AA0A2C86--


From nobody Mon May 23 07:17:15 2016
Return-Path: 
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 60D3F12D929 for ; Mon, 23 May 2016 07:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.127
X-Spam-Level: 
X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 EpzO2E8ivbth for ; Mon, 23 May 2016 07:17:12 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 081BE12D921 for ; Mon, 23 May 2016 07:17:11 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1BDFD433423; Mon, 23 May 2016 14:17:11 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 02546433401; Mon, 23 May 2016 14:17:11 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1464013031; bh=TPkH2ZubUHgfjXWZg3lzMI+XjwZ5MQchj25sd4Pg7Bc=; l=572; h=From:To:CC:Date:References:In-Reply-To:From; b=PWvY3tP2B+OuhqVKhm7spolN9U1t80Pg2ZvFVMV1IOdt3c2GlYDDaACs8T02PpFp/ CeE0ebUp3k5mEnrsIK779O2HqXltruYqMmg0d13c2w1/zrvAZPf6LCAt+PdYlvxciR jwygLEZHVzRAvLvimQaPOSsEeh9xcTv0QcECrOf0=
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id EF7FB1FC8E; Mon, 23 May 2016 14:17:10 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 23 May 2016 07:17:10 -0700
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Mon, 23 May 2016 10:17:10 -0400
From: "Salz, Rich" 
To: Cory Benfield , Julian Reschke 
Thread-Topic: [QUIC] Choice of area (and scope of work)
Thread-Index: AQHRtLy/3Y+re4slRkGw1cb3gPJByp/GZqUAgABuAgD//702UA==
Date: Mon, 23 May 2016 14:17:09 +0000
Message-ID: <8fbdc597ae1749e7816fae2f399504ac@usma1ex-dag1mb1.msg.corp.akamai.com>
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.47.92]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: Jana Iyengar , Mark Nottingham , "quic@ietf.org" , Ted Hardie , Christian Huitema 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 14:17:14 -0000

DQo+IEkgd291bGQgZXhwZWN0IHRoYXQgYW4gYXBwbGljYXRpb24gdGhhdCB3YXMgcHJvdGVjdGVk
IGZyb20gd29ya2luZyB3aXRoDQo+IEhUVFAgZGlyZWN0bHksIG9yIHRoYXQgd29ya3Mgd2l0aCBp
dCBhdCBhIHNlbWFudGljIGxldmVsIChlLmcuIGEgUHl0aG9uIFdTR0kNCj4gYXBwbGljYXRpb24p
IHdvdWxkbuKAmXQgY2hhbmdlIGluIHJlc3BvbnNlIHRvIFFVSUMsIGJ1dCBhbnkgYXBwbGljYXRp
b24gdGhhdA0KPiBhY3R1YWxseSBzcGVha3MgSFRUUCBpcyBnb2luZyB0byBoYXZlIHRvIGNoYW5n
ZSBhdCBsZWFzdCBhIGxpdHRsZSBiaXQuDQoNCkkgdGhpbmsgeW91IGhhdmUsIGluIGVzc2VuY2Us
IGRlc2NyaWJlZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHN5bnRhY3RpYyBhbmQgc2VtYW50aWMg
ZGlmZmVyZW5jZXMuIDopDQo=


From nobody Mon May 23 07:22:12 2016
Return-Path: 
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 9397212D90E for ; Mon, 23 May 2016 07:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lukasa-co-uk.20150623.gappssmtp.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 FtnpR9zr9SmH for ; Mon, 23 May 2016 07:22:04 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 DC98D12D910 for ; Mon, 23 May 2016 07:21:57 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id z87so50548400wmh.0 for ; Mon, 23 May 2016 07:21:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=Cy4fwKLkiBedVC8DZdfyW/CD7fB+ROA/LM3LmwQ3yKs=; b=uGD2LM8Bh+CVQgyNZ8s969HHjxeuNdg0FIxqUjG0VM6EGJzR6zQ4ZAecUUaOQlUUKK 65j33sPSd3GWnvZnGgk4ANpfIUwFfG4cK9pwlGKGYN13bPa1EwD1ONYSCN7XMYTQViS6 76EGz2G2wcWxSlxEXYUtYe7z5qClgc0EyWGQ43+JL1Y3larkoKUay0IloAcfYSeuxsPB aN4Vl8CgBx4PsNPThvnN8j+4FJd0vKRLuc9xb6OdyJVm9/nKye5fKFmb9bWSMq6YKH5/ 35O7vWXET8vaoE5G3CwKG88uBOkxwdOIAzAvoqOaQS1vC++nL+FhNHWewq7kRVHoOATG gfRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=Cy4fwKLkiBedVC8DZdfyW/CD7fB+ROA/LM3LmwQ3yKs=; b=Kd5WS63wSliu9MRTExU/faJRDQzCQ0w6wkhRrkKpkB1gMyRGBUXHKQDLvgtfUmMnNN bxCNpLRfkTpGQtnn4YJQIBOy9T/+IuoGVvmiC4oy72YKjQfiV3MLv1sMvdi4m1gtBVE7 QUkQBk3zbUGYIDchNI/Yc9FwgdWYpqy44vLp4uUHJDpN1GuFqfAoIuAt0frK3mHbua+p 08HVhUc/xW2022b1WZBT95wdcbFAJRs8HKHe6ndsdCoTpGvnT3GKjB6lhWnOefyf1ZBa SdLHkSeaX/3Xd5IKBQ0U0+Lajkwlc4N78bZSG+cEhA/DXG+SsUV7dH0TxwQF6qN8ODya 3WQQ==
X-Gm-Message-State: AOPr4FV8WOggjS7OU3ldw+Bd/NMXHkf8oH1rFavQxfxAF0DyFgC22s4SFcIjqr1Nv26/TA==
X-Received: by 10.28.27.151 with SMTP id b145mr17951292wmb.7.1464013315797; Mon, 23 May 2016 07:21:55 -0700 (PDT)
Received: from [192.168.1.6] (41.65.125.91.dyn.plus.net. [91.125.65.41]) by smtp.gmail.com with ESMTPSA id h14sm10527137wme.1.2016.05.23.07.21.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 May 2016 07:21:54 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_3CEF1EB2-28C4-4500-91B6-8C4F9C4A8797"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.6b2
From: Cory Benfield 
In-Reply-To: <8fbdc597ae1749e7816fae2f399504ac@usma1ex-dag1mb1.msg.corp.akamai.com>
Date: Mon, 23 May 2016 15:21:53 +0100
Message-Id: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <8fbdc597ae1749e7816fae2f399504ac@usma1ex-dag1mb1.msg.corp.akamai.com>
To: "Salz, Rich" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Ted Hardie , Julian Reschke , Mark Nottingham , Christian Huitema , Jana Iyengar , "quic@ietf.org" 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 14:22:10 -0000

--Apple-Mail=_3CEF1EB2-28C4-4500-91B6-8C4F9C4A8797
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 23 May 2016, at 15:17, Salz, Rich  wrote:
>=20
>=20
>> I would expect that an application that was protected from working =
with
>> HTTP directly, or that works with it at a semantic level (e.g. a =
Python WSGI
>> application) wouldn=E2=80=99t change in response to QUIC, but any =
application that
>> actually speaks HTTP is going to have to change at least a little =
bit.
>=20
> I think you have, in essence, described the difference between =
syntactic and semantic differences. :)

Heh, I have. But Julian said =E2=80=9Cwire protocol changes=E2=80=9D and =
=E2=80=9Capplication level changes=E2=80=9D, and it=E2=80=99s not =
*trivially* clear to me that he was using those words in a way that =
corresponds one-to-one with syntactic and semantic. =3D) That=E2=80=99s =
why I followed up: I wanted to make sure I understood what Julian was =
saying before responding further.

Cory


--Apple-Mail=_3CEF1EB2-28C4-4500-91B6-8C4F9C4A8797
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXQxIBAAoJEHD+F/imQ+Fb1rUP/1mnUdeab4CidcICBkEw71FG
1u7AJgL2Ez1xzwNkPymezjZ+7H/suWwBpKB5AMLI5rz0+ROo5QJmBJMqlxhBjhBS
u53w4U/BSDFRtxDqy6CGgpNMEJpof6fZiAYeUqaEKoTLdauF973vRdFrIRWOcP6+
znAIUlerPeuEmUUk4nGZpiHuI2GgauT4hE+JIrK9hDVFSwkks3O7ORbnjL49lssa
RMR8ooC2fkkCEJvmjhziDMmI1sWwICNVP2fng9mZNI6APhp20QxLRMqS5Ap+AO1y
3utX/2LoJhpYwm5+n403JZmZWd3qwoKuH8BVMgozJpCQWBB9mM/ugpgvx2Ax+Px1
kw/JlwWLBXRadDtc8gAL8dgPrJWbblj2pOZEXVhuLfYiWg8a6TBmk3ZT6q/77FL3
fM4MEQdVe9rOQvKQqF5li84aS0Qh60o/4jfGnu5VG7elA2tlxqjsmPjiM6y2wUZe
LnCS12zIbUZE5yuU0HNzUJ6Ff344BEaCErr+Ru8AMuLSO+RhfZSwg2sWdw31dIKQ
LFWiNaHBzUihTxyRPAFOdIK+CYan413szFU70+/C9Yr9xVs9TbWThNv5MFUMCALM
fgSTFHuJ4ZghOoZXBIxZEdc6gJ/XO6qt03Y8HqusKckAbtvYDWFmBEhzlUpmR2qW
iX15i9voqD+NsCDtkN9k
=1w1z
-----END PGP SIGNATURE-----

--Apple-Mail=_3CEF1EB2-28C4-4500-91B6-8C4F9C4A8797--


From nobody Mon May 23 07:27:31 2016
Return-Path: 
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 6387E12D936 for ; Mon, 23 May 2016 07:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 h-RfvQC7rVFg for ; Mon, 23 May 2016 07:27:26 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2571112D937 for ; Mon, 23 May 2016 07:27:25 -0700 (PDT)
Received: from [192.168.1.123] ([5.10.171.186]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MFAaV-1bJRnY07PH-00GM2i; Mon, 23 May 2016 16:27:11 +0200
To: Cory Benfield 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>  
From: Julian Reschke 
Message-ID: <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>
Date: Mon, 23 May 2016 16:27:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:8L1adROPCVEsatSMrvdaQMjHoEcwtk3y68N6V6EHQZ5IIGrknY3 fKZbTBWaoei2VkUwUaBRfjHj072EmxUX2alNmwfCgGSTsBHUI6U7xJSUkRXndWByD/fpn6E Gp4b84E2Rt89VzykxzQOrgt4nYiFcJC2G6GxMH235a3Xut5mozN34Kipj/LgqzCfnGHN9VF yIbcjNahRyowIeVY4nXIA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:WW7r0zw1AB4=:m6iWkPd2VEGMRRpxm3Xbvj FxVjMDH2ZgICTiD0ZrTg9OOpnLxSkXJwO7At3/mwmyW2qAjE/T24sU/ZAjZv4WOadc/3dulan eEUpqGMajWGnU/S4LrHyZbwJ/6L2+nBTMIxeXJ4kxK1o/WWfgaVRHSk4sCV4bcysPU6jLtes2 83FRVO32JcUG+SFtTUshnTJus+b1wb5SDhRBIe7HdCQAHpZP+hRHYjxk4870W/Hgq1F8zM0Dr U2/MicIIryofx6kdav4HKMPgxZ+vA2nT2SElYqBgBSFQUNBs9eaJC3xqIOGQZ4dTuTpBhe+6e ENdHVAmbYAAduNc7oDXKuM/b38LdT88gf4X/KPelQOoqIojtu8c+Cn6Of+NQ2ghL+77rqTYjo ailh5pZXUVCFydP6LOvET4+tRIOc6hWP/AUtAtAy4Ja1PM1GVI53/5kzqZbb/TNtIVGq8LjYm y7/6e8zsRTazSmWeB5DSqbq2eSPQ9vkM0zzHl/vihwPKQTMnZWj5oYvDo3vX09e9V+LMrYDsz zIwTLMTwGMOotGhzCNJE4DaFdWtLSSEAuE5oNqQWKVgZ81gRQLYqEBwXaQFD7+T7/R2kK6ARG ueKKzAOkf2gSm/kvlXH0sD5uLepghk7akKIeVCETha2Vi+aCiL4ms9mSVhVMGtGTKiEzUVx+0 76l1wzR7ZY+14HY/db8uK2XOZf1fulqOdfr6PDQAiYucO/GvUKwUWL5nth2uGN0Bg7Gi32Dfs TvNmBB6+d8TN3HFvK41qTZ8ISmfSZLKZRw1XL3vVxqoFwcc1jhUJXSIJQ227O/k/94B6iY73k qPsnW83
Archived-At: 
Cc: Jana Iyengar , Mark Nottingham , quic@ietf.org, Ted Hardie , Christian Huitema 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 14:27:30 -0000

On 2016-05-23 16:15, Cory Benfield wrote:
>
>> On 23 May 2016, at 08:41, Julian Reschke  wrote:
>>
>> I think it would be unfortunate to couple wire protocol changes with application level changes if we don't need to.
>
> What does “application level changes” mean here? My understanding is that no-one is planning to make *semantic* changes to HTTP as part of this work, but necessarily there is going to be some divergence from RFC 7540 if only because the nature of the transport will be meaningfully different from TCP.

I was referring to what Mark said -- people have been talking about what 
HTTP/3 could be, and these discussions (AFAIR) also touched features 
above the transport layer.

So the question is: is the result of mapping HTTP/2 to Quik what will be 
referred to as "HTTP/3"? And so, will it *just* affect the mapping, and 
leave everything else unmodified?

 > ...

Best regards, Julian


From nobody Mon May 23 07:28:33 2016
Return-Path: 
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 DE0A712D937 for ; Mon, 23 May 2016 07:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lukasa-co-uk.20150623.gappssmtp.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 xdQBh4dQ7acV for ; Mon, 23 May 2016 07:28:28 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 2E13512D939 for ; Mon, 23 May 2016 07:28:27 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id s131so3023491wme.0 for ; Mon, 23 May 2016 07:28:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=otY5JoJ1JVlkQo91Bgbf0EHxvZiwkBcugfWYKU29K24=; b=TJS8gffliGNk/ezoBuXTYSHLrwplSbWs3Is11PhS4nXjvIyDJZYmjku/fKeUTJVF+X Bl5d81pJoN90MaaJESK8R8rV61l79p96psybAkTofPxmDf+G4cmPR/E6SLeEzbcojmiQ iQfd2t9mpYC8l/RUvNEEMp3JwTbLVWI8RbHMlcoQoAFfLsoV3vCfIMWvESO7OC7EbLAw kKMTC/btCejoBM+ZK0chWgEl8psNDw7ygvDjg/1tRPVtf92tZLv7+uiyEVqj0DI3Ckqt DUMnet5cSq+rem725AiPa8Dwsc74EmzcPicsAoVSD+VYjrYIM0RPJQXR5fjlVrV5+u01 XKPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=otY5JoJ1JVlkQo91Bgbf0EHxvZiwkBcugfWYKU29K24=; b=SD5ywp8rQvicPsZ7bMvyHEhtryY2FxqX1rU0VR+GwIFfnMQMvzmca3tgjdsMEX2zkP JSz3FV6Kof6d+J7w6pnMX44z5wfx57yobNRxtzV/ejJPq9FGOJIRBIUEqsWCWWXQAzG2 /n8ZUjbkduOdtet2JUHnhgjBpmwIkDJ7+be5+yqredvNFb6uHo3JYQLPSeBB+5954GoD ZVDQq0S49laCj2hHSHdCuh6SIebw4br+TPgXF+M3vUPyWtJAYFeqFUNI4xeqwihaN79X cKxoOuYfA47o8J2E5WP68L0MDWbMo1mGTlPHeyWZ9Z7NQ2gLJmBrHcTZ1r//VN2y8HX6 3aBQ==
X-Gm-Message-State: ALyK8tLhBXOFGbe0Pe7b7a6AqjYRynXl2pHI6mtnNZXltkCjePa8EonvF/FjvmF0aZOBhw==
X-Received: by 10.28.234.221 with SMTP id g90mr3621697wmi.30.1464013705703; Mon, 23 May 2016 07:28:25 -0700 (PDT)
Received: from [192.168.1.6] (41.65.125.91.dyn.plus.net. [91.125.65.41]) by smtp.gmail.com with ESMTPSA id c16sm14073631wme.16.2016.05.23.07.28.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 May 2016 07:28:24 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_12B08FBF-0227-41F3-9EA1-A02BDF00591F"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.6b2
From: Cory Benfield 
In-Reply-To: <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>
Date: Mon, 23 May 2016 15:28:23 +0100
Message-Id: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>
To: Julian Reschke 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , Mark Nottingham , quic@ietf.org, Ted Hardie , Christian Huitema 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 14:28:32 -0000

--Apple-Mail=_12B08FBF-0227-41F3-9EA1-A02BDF00591F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 23 May 2016, at 15:27, Julian Reschke  =
wrote:
>=20
> I was referring to what Mark said -- people have been talking about =
what HTTP/3 could be, and these discussions (AFAIR) also touched =
features above the transport layer.
>=20
> So the question is: is the result of mapping HTTP/2 to Quik what will =
be referred to as "HTTP/3"? And so, will it *just* affect the mapping, =
and leave everything else unmodified?
>=20

Thanks for that clarification Julian. I definitely have similar concerns =
to you here.

Cory

--Apple-Mail=_12B08FBF-0227-41F3-9EA1-A02BDF00591F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXQxOHAAoJEHD+F/imQ+FbFEAP/jY1f61F+0L67P2FRYBUe2v4
OglwQygTj0I7HBn0nMKfZWIpjoNCIDJ/t6b25VGCtXawUlLkXZcPusb/e8+cv1Zt
qFIR3KNpVO9mJiM7Ezpjv2Srt+QVqmDkJZ08zlBKZste8dU0Unf19QPvOArf16y/
8JJWxfUgzoYAV0rONGAE/arUWeKtL0t1xT2LSxOWO0BV48qXWbD3T0KCXspivKQv
liSwV1Sbfp24B5bZUbJBJBjV5ZQkeE1XB36C1Txnt/hADPbZTGIBSVdWxuFlvKoC
bFngym5zNPWX6nPREbOY/VJk0G57Ue9amTCDzF99DYU6rIqRmVhr0qsJc38XIli3
UDazOPB9py6nhxuBZjnk4vTjHcANiPamlT/ozbO8DJu1FcjR0TsQlqvFFfOgut/f
KTr2NnrvndMrmB7ieHG7AIzX4PTAv2zmUiTueM7uZd7j9KEZfF4sej6WUgTVP47B
b6LLthRDQ4U5ywu8Y8NppWa8+2a9bfkiXBlngRL4b6XE3GaWVHCXHxKCLFqhTvaw
Py0GtnSCAfxnPnP0xQk/HZkdvKa05BGtW/BkKNlEHFbRERSbIomZt1W80uzBl6eM
vKFDQQbTxBL/u5Rd+/GpS/eJQPQMzv5vkPUgzJTC0XwhiUlVCWjBY4q+7nlEUEJs
ZsVIhwAzKdwdOlJHrCtx
=xkjT
-----END PGP SIGNATURE-----

--Apple-Mail=_12B08FBF-0227-41F3-9EA1-A02BDF00591F--


From nobody Mon May 23 08:49:02 2016
Return-Path: 
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 3CAAB12D998 for ; Mon, 23 May 2016 08:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 x_KKjuqP2s4u for ; Mon, 23 May 2016 08:48:47 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 90CE612D636 for ; Mon, 23 May 2016 08:48:46 -0700 (PDT)
Received: by mail-ig0-x231.google.com with SMTP id l10so26417844igk.0 for ; Mon, 23 May 2016 08:48:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VI9PSPJcCqWB6oYPuNuYj8iYeTWUvb6VS11pyq73EKk=; b=d4VzFR6ZlKHgHIPVEX69PCs5fHXDXYocJZCENBTneQ8tEy8WVQNSjEZDjobKOBw24o rzJOpRIMPFNqb87Dr9mWuZU8LSKYWNQS5rsnsCXGHGCkkal6nA2uXhOlvwFXDHRuF1vX W/mVe3D7MsCrSPQL+acgPyF/fOg+7BtIFX/kKYn71Dn/rHsVi4pN9yDblZHGlgp8wcd/ pBUu9vgB57kHp5G9Zhka7wIJfM51f3J4z1eCDm/AhAt6yFyOr5t2A+uVjzLDXO67GbOQ XUatJ5iLYIyCgIg40eAjimkPrZPuuBBcvQAu+WOzPJ0Uh3KD708rX4NfIR3qiNYP1UOr idXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VI9PSPJcCqWB6oYPuNuYj8iYeTWUvb6VS11pyq73EKk=; b=Stu6+qCAk8R09aXjAw1NMlaY+HaRlr9hSL+GEEs1YBohD9KcbRVwo7inRhnu0MYLZK aI2lwdTYF5PF8dafBan7StemRMWAb2qwWoPIxyidE2L+eRhUvZal/gOOadY0qVUEoAeR tyhz1j4oXD4qVxVaA58X8Jfw+dPW1I5OIG8BDZmEMmAkwecJQSdUvNLeEEPQGIfB1rmK KYhGeE4epVaXXtfkXs51lV7TK+ua9mkV4u4nhNJ85LQm2LM8aHw/T/8IZLHh673WsMAd B99lFaj1oNnV/qHyJ/eFdehMdv9Gxmw8VPzgFtt756xklPIwEqojDBhWiO9nzS8VkAVI fong==
X-Gm-Message-State: AOPr4FW/PL9HXztOCtWkzZ5THep9V/NZQ8S2zXA0ZvaNqO4f8LyVIBJtUkhcYONqg3B8eYx/qbuVikOtBrQCQncm
X-Received: by 10.50.3.36 with SMTP id 4mr13732741igz.3.1464018525673; Mon, 23 May 2016 08:48:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.227.227 with HTTP; Mon, 23 May 2016 08:48:25 -0700 (PDT)
In-Reply-To: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de> 
From: Ian Swett 
Date: Mon, 23 May 2016 11:48:25 -0400
Message-ID: 
To: Cory Benfield 
Content-Type: multipart/alternative; boundary=089e0122a4802b7bd705338460db
Archived-At: 
Cc: Ted Hardie , Julian Reschke , Mark Nottingham , Christian Huitema , Jana Iyengar , quic@ietf.org
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 15:48:49 -0000

--089e0122a4802b7bd705338460db
Content-Type: text/plain; charset=UTF-8

A very interesting question Mark.  A few thoughts.

In regards to alt-svc, my thinking is that this would be h2-udp or
something similar.  That assumes QUIC has no semantic changes to H2.

If QUIC enables semantic changes to h2 that are valuable and are difficult
or impossible with TCP, then this becomes a very challenging question
indeed.  So far, the largest divergence we've considered from h2 in QUIC's
mapping is the best way to map headers and still minimize HoL blocking.
But that doesn't change semantics.  Developers build applications with the
tools presented to them, so lack of use is no indication that there aren't
semantic changes of interest, but I'm not aware of any QUIC specific ones
at the moment.

If the concern is that there's interest in an h3, but little appetite to
deploy h3 over TCP and h2-QUIC and h3-QUIC all in close time proximity,
that's a fair concern.

However, from a deployment perspective, I expect H2 over TCP is going to
have a relatively long life.   So there will be almost as much complexity
to support H2-TCP and H3-QUIC as H2-TCP, H3-TCP, H2-QUIC and H3-QUIC,
unless there are features of QUIC which make H3 profoundly easier to
implement.


On Mon, May 23, 2016 at 10:28 AM, Cory Benfield  wrote:

>
> > On 23 May 2016, at 15:27, Julian Reschke  wrote:
> >
> > I was referring to what Mark said -- people have been talking about what
> HTTP/3 could be, and these discussions (AFAIR) also touched features above
> the transport layer.
> >
> > So the question is: is the result of mapping HTTP/2 to Quik what will be
> referred to as "HTTP/3"? And so, will it *just* affect the mapping, and
> leave everything else unmodified?
> >
>
> Thanks for that clarification Julian. I definitely have similar concerns
> to you here.
>
> Cory
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>

--089e0122a4802b7bd705338460db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


A very interesting question Mark.=C2=A0 A few thoughts.
In regards to alt-svc, my thinking is that this would be h=
2-udp or something similar.=C2=A0 That assumes QUIC has no semantic changes=
 to H2.

If QUIC enables semantic changes to h2 tha=
t are valuable and are difficult or impossible with TCP, then this becomes =
a very challenging question indeed.=C2=A0 So far, the largest divergence we=
've considered from h2 in QUIC's mapping is the best way to map hea=
ders and still minimize HoL blocking.=C2=A0 But that doesn't change sem=
antics.=C2=A0 Developers build applications with the tools presented to the=
m, so lack of use is no indication that there aren't semantic changes o=
f interest, but I'm not aware of any QUIC specific ones at the moment.<=
/div>

If the concern is that there's interest in an =
h3, but little appetite to deploy h3 over TCP and h2-QUIC and h3-QUIC all i=
n close time proximity, that's a fair concern.

However, from a deployment perspective, I expect H2 over TCP is going to h=
ave a relatively long life. =C2=A0 So there will be almost as much complexi=
ty to support H2-TCP and H3-QUIC as H2-TCP, H3-TCP, H2-QUIC and H3-QUIC, un=
less there are features of QUIC which make H3 profoundly easier to implemen=
t.


On Mon, May 23, 2016 at 10:28 AM, Cory Benfield <cory@lukasa.c=
o.uk> wrote:


> On 23 May 2016, at 15:27, Julian Reschke <julian.reschke@gmx.de> wrote:

>

> I was referring to what Mark said -- people have been talking about wh=
at HTTP/3 could be, and these discussions (AFAIR) also touched features abo=
ve the transport layer.

>

> So the question is: is the result of mapping HTTP/2 to Quik what will =
be referred to as "HTTP/3"? And so, will it *just* affect the map=
ping, and leave everything else unmodified?

>



Thanks for that clarification Julian. I definitely have similar conc=
erns to you here.



Cory


_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--089e0122a4802b7bd705338460db--


From nobody Mon May 23 10:04:29 2016
Return-Path: 
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 E36F812D11D for ; Mon, 23 May 2016 10:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 8WJWmdd4xPaI for ; Mon, 23 May 2016 10:04:26 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 451B712D10E for ; Mon, 23 May 2016 10:04:26 -0700 (PDT)
Received: by mail-ig0-x22d.google.com with SMTP id l10so27668732igk.0 for ; Mon, 23 May 2016 10:04:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4Wj5+aM+l8tm8vhRvx3CdaTAp9ELt8pSLuZtO8ZzteM=; b=g8hv7trPMKPuRJOPPWop99O+XVQ7zhtYf6L9Z3NLGAq3wfEqavTJb0IkHVVZOkII2E yLEZr16imiXZ7AteJygNRn1Yt9leGDwCk0gMc3T5PBpeVt4lElhMNjsHd/Q6TUqFcZa8 a1rNWEwMTjUHrQy6/6thSoeH8W8ntitRcnYlzquuNGI9wo3pPDCX0jXflxWNZd7ioI9M rDZhpAGy1WFsdLIORzZBK8PRvGdx5fklszCaVUz5P/Je3cR7RqDJG99KpS0wqycHqgRB s1/DyIptqwuCl3ROQzlnRSlBnWl89LooBc6bVLDJXvikKAiX0h9XyRKf2QYm7np/Nbr0 u0Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4Wj5+aM+l8tm8vhRvx3CdaTAp9ELt8pSLuZtO8ZzteM=; b=Vj1E7UvJ0J/D4zmvoXE3fM39VytQTJ/Shenk2RAQ2DiS76x67o0Gx8CfsDudwk4syf qjJM1nCFhtdFK9s2sB7aQBpFZiDdmaD4S5dcPO5OBcKJ2sbBG84htSnQNVaL5lz57FBl lCEf1sns5n2WAZOddr9Sc2G4IaJsiL9Or8MYWJZuS/RDusrEEbB9xTjKBiv/hDAi0U+7 MdB35MUwtRNqApvvGutpzSJeLK8VwzOkm3hBl25+WhJJx/hvl4db5ATjDugXDh7NKqBZ 8N+ueUMwaTKrvrSfvIfVwc+eHPVImfiJWnj/Vw2L1XTv2iF0O5ttC6/mQcRGszsxVweH LOeQ==
X-Gm-Message-State: AOPr4FX2Y6PT25qqC7tLCKM3BAbeXYpkZIpeEjZTU3p0iCaFCWw0yV1qz/FN5WzRiWe2sVnqbE+1d5YWKPLMxA==
MIME-Version: 1.0
X-Received: by 10.50.33.81 with SMTP id p17mr14028949igi.58.1464023065506; Mon, 23 May 2016 10:04:25 -0700 (PDT)
Received: by 10.36.43.23 with HTTP; Mon, 23 May 2016 10:04:25 -0700 (PDT)
In-Reply-To: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>  
Date: Mon, 23 May 2016 13:04:25 -0400
Message-ID: 
From: Martin Thomson 
To: Ian Swett 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Ted Hardie , Julian Reschke , Cory Benfield , Mark Nottingham , Christian Huitema , Jana Iyengar , quic@ietf.org
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 17:04:28 -0000

On 23 May 2016 at 11:48, Ian Swett  wrote:
> In regards to alt-svc, my thinking is that this would be h2-udp or something
> similar.  That assumes QUIC has no semantic changes to H2.

I don't want to distract from this, because this is a good intention.
However, I'm not yet convinced that this is even possible.  QUIC does
... things to the mapping of frames to streams that might alter the
way some h2 extensions work.  I don't quite know what we would do with
(for example) this: https://mikebishop.github.io/http2-certs/


From nobody Mon May 23 10:22:28 2016
Return-Path: 
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 CA42312B069 for ; Mon, 23 May 2016 10:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 acIXW8M-fjgT for ; Mon, 23 May 2016 10:22:24 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 B5B1212D0CC for ; Mon, 23 May 2016 10:22:24 -0700 (PDT)
Received: by mail-ig0-x230.google.com with SMTP id bi2so37616721igb.0 for ; Mon, 23 May 2016 10:22:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r4K8bAhrBd7Tz27x0xo2WJGiJCrlZ1Q2tJl8ta72gMM=; b=iYtREx3xyZAlRNXGqlMRefPL9V00rpZThMYiYLGnaVRFbB9MS1I0ijBpTIEGoOWcbt HwWzgdbs3PN9Q/rmg42CIj2lMhV9OUY82hdaArmVoYIilhvGDXdX4JNoYZStTvnjMULG qOPOR6JSH0ANdckF8pJXCePpG/MhKP8ek5i1avkUb/ZIWVYuXDjIGV2epAQu4KHNhreT ekDNMXLSZsYN86btKmDxvbPY4iso9OoIqeicJW4joFTjzuhaKiJp+1pZPIgxDLXFhOC7 igcuOnfRRWcLbsnEwUgH3FtMsc5lUsAGsSlBizwf6FiliSrz4sXXee5fL0pH6RzSWso7 XF9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r4K8bAhrBd7Tz27x0xo2WJGiJCrlZ1Q2tJl8ta72gMM=; b=aptDiFdiwxGgyfYe+mQa9jtHbqQANCvs41bJWoRP1TAY9Hc5hCaZUZ8x17TaYgCrgS bpxk39NUrSbJrCMb70wDMuONM7i3kxHmY+AxA0+KMNFAnii4+tJMuUt5wRtwjvorb1Td 9CDvnF7qgjx0xWHJ8WOwbNGtQVDjSDoKnwXCLvUmkrosadaacoDj0M3tknxqgCyPyt8K lMtUsDpmeoV4Fv6QfUeXkRdOr1hUvcRSo8KvW59rL/ZIT4UZelQ15xMWSGxlR/WSv9u6 KZgKq2Vow3x4EF9Ie3hDWkY9T0xbDu8M76v2QzHJ273r/oHjt8vvRK3JHeY5aGzuO1do 7ppA==
X-Gm-Message-State: AOPr4FUTmqED4sQJ8KgUkWWQwxN4UpDZpLrBTCcLtGRsHAFZ4EkpkQyrpHfZ3n7VszqghL1zTbmMrRRK+urhHOFq
X-Received: by 10.50.41.97 with SMTP id e1mr14096642igl.3.1464024143861; Mon, 23 May 2016 10:22:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.227.227 with HTTP; Mon, 23 May 2016 10:22:04 -0700 (PDT)
In-Reply-To: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>   
From: Ian Swett 
Date: Mon, 23 May 2016 13:22:04 -0400
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=089e0116074a09f999053385af4e
Archived-At: 
Cc: Ted Hardie , Julian Reschke , Cory Benfield , Mark Nottingham , Christian Huitema , Jana Iyengar , quic@ietf.org
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 17:22:27 -0000

--089e0116074a09f999053385af4e
Content-Type: text/plain; charset=UTF-8

Can you describe the particular QUIC specific challenge with the
http2-certs draft?  I'm familiar with the draft, and no issues come to mind.

On Mon, May 23, 2016 at 1:04 PM, Martin Thomson 
wrote:

> On 23 May 2016 at 11:48, Ian Swett  wrote:
> > In regards to alt-svc, my thinking is that this would be h2-udp or
> something
> > similar.  That assumes QUIC has no semantic changes to H2.
>
> I don't want to distract from this, because this is a good intention.
> However, I'm not yet convinced that this is even possible.  QUIC does
> ... things to the mapping of frames to streams that might alter the
> way some h2 extensions work.  I don't quite know what we would do with
> (for example) this: https://mikebishop.github.io/http2-certs/
>

--089e0116074a09f999053385af4e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Can you describe the particular QUIC specific challenge wi=
th the http2-certs draft?=C2=A0 I'm familiar with the draft, and no iss=
ues come to mind.

On Mon, May 23, 2016 at 1:04 PM, Martin Thomson <=
;martin.thoms=
on@gmail.com> wrote:
On 23 May 2016 at 11:48, Ian Swett <ianswett@google.com> wrote:

> In regards to alt-svc, my thinking is that this would be h2-udp or som=
ething

> similar.=C2=A0 That assumes QUIC has no semantic changes to H2.



I don't want to distract from this, because this is a good inten=
tion.

However, I'm not yet convinced that this is even possible.=C2=A0 QUIC d=
oes

... things to the mapping of frames to streams that might alter the

way some h2 extensions work.=C2=A0 I don't quite know what we would do =
with

(for example) this: https://mikebishop.github.io/http2-cert=
s/





--089e0116074a09f999053385af4e--


From nobody Mon May 23 10:28:37 2016
Return-Path: 
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 5A31A12D11A for ; Mon, 23 May 2016 10:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 0OzweulTtP_Q for ; Mon, 23 May 2016 10:28:35 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 0834F12B059 for ; Mon, 23 May 2016 10:28:35 -0700 (PDT)
Received: by mail-ig0-x22e.google.com with SMTP id fh2so26653137igd.1 for ; Mon, 23 May 2016 10:28:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=trtLBrFG14Vjwj+Wq2zUoJYtkMmZSy3v7uGgzBAX/A0=; b=wO3tLOD8sNt90SA+nPPaK9/6VsvbEFSrWARjso6VzWSCRG+5YFI1I2gr2OkBEqi8fp iXP+U0yFHkRBqaxBXVg0i+4o+mlMiFX6F/V+RYirezFgXtQDMrfvjkBIFpxbtUYW9kJ3 nm+xcgiVJR+IjIIp+5/1SmVDBhxUxRbwnXMwj7ABSbKR69b8DGLoFMPfHgCdfFdhaGup 8EmIDhiMieP7Hfbl8fdx7XDxIh9rhdJ3iQSstsb109a86eXaThxFTtDjwFcItZoCj1hb QeQeC7ZbP8Ra64glcmCmnvgFXQeRMWD5Ot+pKiwTJjmlV1smvQZmEo//qPJxOvFoKGOm 3CQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=trtLBrFG14Vjwj+Wq2zUoJYtkMmZSy3v7uGgzBAX/A0=; b=CcnbexFRKiyxaOvbAeijza9Nd1oAm32IHH4gJRlubLiDnPZKNpwR53MEojKDbWB+D0 YHlAdUNwUUN7BH+JaA12uXhEBFDUg9pyzS23QTguyG5Ul90CZt4qkWMbzre8UHidEDOL dpOmHGa9zpifEKceqGTNm+Zei0KLgwCHRDq/gXxb58HGE7vfiPNn0YrhXw14jSe8SbjW 16AfiSuBmKJ10Jgcs6l4Tz99Oae8f7WnLHqPo+M1OCzSu6andyuGOd5uD20yWzW1Qv1G 3u4KPXcPSUVc0jssQJ/RIHf+xOMfLZomZMy1O7sGuzcbJnt5tkg/nKLUEQNBbxj6joS7 wW8A==
X-Gm-Message-State: AOPr4FWB6F5DVoaHgC9TAvkLb4TWJ9lBhiMJkquKH8zrHc4mQ68cCDo2O4fGRaQffA5x/VVdBm0/qPuYhbkwPg==
MIME-Version: 1.0
X-Received: by 10.50.122.68 with SMTP id lq4mr14391256igb.77.1464024514436; Mon, 23 May 2016 10:28:34 -0700 (PDT)
Received: by 10.36.43.23 with HTTP; Mon, 23 May 2016 10:28:34 -0700 (PDT)
In-Reply-To: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>    
Date: Mon, 23 May 2016 13:28:34 -0400
Message-ID: 
From: Martin Thomson 
To: Ian Swett 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Ted Hardie , Julian Reschke , Cory Benfield , Mark Nottingham , Christian Huitema , Jana Iyengar , quic@ietf.org
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 17:28:36 -0000

On 23 May 2016 at 13:22, Ian Swett  wrote:
> Can you describe the particular QUIC specific challenge with the http2-certs
> draft?  I'm familiar with the draft, and no issues come to mind.

The draft requires exchanges on the affected stream and stream 0.  I'm
concerned that the change to move header fields to stream 3 will
negatively affect the sequencing of things.  I haven't thought it
through completely, maybe it's even an improvement.

Even if this is OK, I'm concerned that changes like the placement of
header blocks will have an impact on h2 extensions generally.


From nobody Mon May 23 10:32:31 2016
Return-Path: 
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 A866612D989 for ; Mon, 23 May 2016 10:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 kFHFAKJQ4gd5 for ; Mon, 23 May 2016 10:32:28 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 235DC12D123 for ; Mon, 23 May 2016 10:32:28 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id f8so65370755ioe.3 for ; Mon, 23 May 2016 10:32:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VC+Pmodc9ioETycpu3MmAa9yLXWjTpR4vFXDCFFl0zA=; b=jDGe5clNDOyr5Jfb8+uuTWUSwTUO1RP3DuRUoB2dwy0zjzov8WTv6XV/rzPsbgzhms mIuwkn9bqUoMB0MfC5OGQ/uo6Z+pzj/SHadjhC0h8UsDGTwNxxvw0N9R2zWX+KAPeOWw RyiQVxlzicsJT58nzhAN5VWB+gb1wYa2aGJD3CcT1ejCNC4UqR6pneTo9nCDEtX2Qk+j YDomO8oKMj2edIkvPpf4ChBW8XWadzBJ33FYcaYdqYGjmO1k8YRftFslAImu7JtOjOOL Jfq69FMxilIomEX4fi7IUuAAykMDuRTgRlc1l8eVCt0a3LIpV75TsI0zcsrcRBkhvKzU 8Dsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VC+Pmodc9ioETycpu3MmAa9yLXWjTpR4vFXDCFFl0zA=; b=ZYTMQz//aA25aafSKCq2Mfy4JU7tv/uC/kWX0+mGAR8GonM8qCcXwZgbeQQAOd/1zn L/Dd+yefQvElUmAcqy0uC+XSoXfXGcN0I0YSIZa8WpEeoXJ4jxRt5+DYZnDoAtpX74I8 owqbGQQJDASQBNGfJ0iuGXTYa0aqdu8Ad3ch90RwBdWWdkbHX3yjY6jdV6527pwjCQpc 3S91JS6e8mAQ4yAFt5tSUBdr4b+0cJ6rfTQ4/kR02PenNVNMYYXAm28og7Ro+1/q9ICk sxzi2N/HYzG1pxfrgBGmA2BItNZIZbTnfeZyT62CLiKFUi5rfI7yp9Eb4Qd8DEw07NPK sPVg==
X-Gm-Message-State: AOPr4FW9UYg35GFMNkr1mH6lLfFBEkcPUWgPr8CNaqG5XiXgKwVOSa2o+mntQg4m27DlCcuNo+NdPYUVDPsUOD4z
X-Received: by 10.107.140.133 with SMTP id o127mr13811149iod.32.1464024747303;  Mon, 23 May 2016 10:32:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.227.227 with HTTP; Mon, 23 May 2016 10:32:07 -0700 (PDT)
In-Reply-To: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>     
From: Ian Swett 
Date: Mon, 23 May 2016 13:32:07 -0400
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=94eb2c05c94802089e053385d313
Archived-At: 
Cc: Ted Hardie , Julian Reschke , Cory Benfield , Mark Nottingham , Christian Huitema , Jana Iyengar , quic@ietf.org
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 17:32:30 -0000

--94eb2c05c94802089e053385d313
Content-Type: text/plain; charset=UTF-8

Agreed, the ability of QUIC to fix head of line blocking creates a variety
of challenges for specifications which relied on head of line
blocking(including, but not limited to headers).

The simple fix is to put all H2 frames requiring HoL blocking onto the
headers stream.  I 'think' that's sufficient as a viable approach, and in
some cases we may be able to do better.

On Mon, May 23, 2016 at 1:28 PM, Martin Thomson 
wrote:

> On 23 May 2016 at 13:22, Ian Swett  wrote:
> > Can you describe the particular QUIC specific challenge with the
> http2-certs
> > draft?  I'm familiar with the draft, and no issues come to mind.
>
> The draft requires exchanges on the affected stream and stream 0.  I'm
> concerned that the change to move header fields to stream 3 will
> negatively affect the sequencing of things.  I haven't thought it
> through completely, maybe it's even an improvement.
>
> Even if this is OK, I'm concerned that changes like the placement of
> header blocks will have an impact on h2 extensions generally.
>

--94eb2c05c94802089e053385d313
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Agreed, the ability of QUIC to fix head of line blocking c=
reates a variety of challenges for specifications which relied on head of l=
ine blocking(including, but not limited to headers).

The=
 simple fix is to put all H2 frames requiring HoL blocking onto the headers=
 stream.=C2=A0 I 'think' that's sufficient as a viable approach=
, and in some cases we may be able to do better.

On Mon, May 23, 2016 at 1:28 PM,=
 Martin Thomson <martin.thomson@gmail.com> wrote:
=

On 23 May 2016 at 13:22, Ia=
n Swett <ianswett@google.com&=
gt; wrote:

> Can you describe the particular QUIC specific challenge with the http2=
-certs

> draft?=C2=A0 I'm familiar with the draft, and no issues come to mi=
nd.



The draft requires exchanges on the affected stream and stream 0.=C2=
=A0 I'm

concerned that the change to move header fields to stream 3 will

negatively affect the sequencing of things.=C2=A0 I haven't thought it<=
br>
through completely, maybe it's even an improvement.



Even if this is OK, I'm concerned that changes like the placement of
header blocks will have an impact on h2 extensions generally.





--94eb2c05c94802089e053385d313--


From nobody Mon May 23 10:53:08 2016
Return-Path: 
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 085B712D874 for ; Mon, 23 May 2016 10:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 7Et33uuRloeG for ; Mon, 23 May 2016 10:53:03 -0700 (PDT)
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 2BDF712D7E8 for ; Mon, 23 May 2016 10:53:03 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id x189so178119920ywe.3 for ; Mon, 23 May 2016 10:53:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cVylzins0EEOQcoNBrGxkQBxAGQFCmR9ZCVLgwXFS3A=; b=NZKzsmVMmPdGA4k4nidn+xks5Azd9L/hDwegFOKxfsL2/dohFt9LFSECaRuhpripZ6 na2rSTFIPu+ttzz51TtfIdrMVVxEYSze5rypQ851vAbm3cEKpy27y5Z++dfTveAGesU3 uUt4G9Lzq3qfVeiEwMlbtXygJv5t53kuYUbcrkshK5qwSG0UJra32AeXWqQAc6nUd2X5 938qB7ognOt/N6QbCpEzkodW4e+97UNhZguBjQelcpCCxBp550tsBLFNcuxi/b9GAwm8 w8yiPikxYaYDdYwcuk+L+FgbzND8nAtg7sV0F+T6F+S4qP4+tRPDzbj1rpvo3rTZWaPP Q0Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cVylzins0EEOQcoNBrGxkQBxAGQFCmR9ZCVLgwXFS3A=; b=QgSkge2P+D2P3CRZlPbyGQYp+iRxoxi2JKdaccD8evGXqjCheq6/TbEcWpQlFwn7wm JSq4LQA0/qe8SLViyN5yxRcv/+m5v0+oqVWXvJ1b8z3y1nWMzcyryvOqLXkzkOR4mboW SLkJAGSgiRpzDvlxfIxDryBeWTmm4789uH8Q3vsuxGBIOgJ4aThxboLAieyO7/aVsTcd RIVCY6WF1LsW69YpAibM6IPHSyNRZ+A+y1dLZQtUZnXA9lgagwu2GVljh+3RNEhEzq0k jqCatnTtbccdNgzHL5vSURSGkH7WUp8veLcbhOfl+aI3J7sti7C/GTmvRom21vp76Ykp XLtA==
X-Gm-Message-State: ALyK8tKVcJy1LMRrOfzD99PUqp0JaWibWnHJc7uYpTJF/INKNdMDnMN/gkT8SRuHlp+fCk7oUHxdjeovJIygLlDq
X-Received: by 10.129.165.135 with SMTP id c129mr56183ywh.67.1464025982198; Mon, 23 May 2016 10:53:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 10:53:01 -0700 (PDT)
In-Reply-To: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    
From: Jana Iyengar 
Date: Mon, 23 May 2016 10:53:01 -0700
Message-ID: 
To: Christian Huitema 
Content-Type: multipart/alternative; boundary=94eb2c12a0629d0b520533861c8a
Archived-At: 
Cc: "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 17:53:07 -0000

--94eb2c12a0629d0b520533861c8a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, May 21, 2016 at 8:44 PM, Christian Huitema 
wrote:

> Just to be clear, I did use the term =E2=80=9Csuper cookie=E2=80=9D in th=
e context of
> multi-path and mobility. That was triggered by the SPUD discussion, durin=
g
> which a proposition surfaced to use a QUIC-like connection ID for mobilit=
y
> and multipath, and to standardize that as part of the SPUD header. I thin=
k
> using the same statistically unique 64-bit number in the clear text
> envelope of packets sent from different IP addresses is a really bad idea=
.
> It is a bad idea for MP-TCP, and it would be bad idea for QUIC or SPUD.
>

I'll disagree that it's a really bad idea, but I'll agree that this is a
conversation worth having. And as you point out, we should and will talk
about this during the multipath conversation.

- jana



> I do agree with Jana and Ryan that there is no such problem if the unique
> number is only used for a single pair of source and destination addresses=
.
> And I also agree that the proper time to study privacy-preserving multipa=
th
> mechanisms is during the study of multipath.
>
>
>
> -- Christian Huitema
>
>
>
>
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar
> *Sent:* Saturday, May 21, 2016 5:20 PM
> *To:* Ryan Hamilton 
> *Cc:* Scharf, Michael (Nokia - DE) ;
> quic@ietf.org
> *Subject:* Re: [QUIC] QUIC privacy impact
>
>
>
> Michael,
>
>
>
> Just caught up on the SPUD thread, and I'd like to correct something you
> said there that I'll quote here for context:
>
> *"if there is now a new clear text identifier that just happens to be
> unique per subscriber. What a great improvement for privacy in the
> Internet! And even better that it seems compatible with QUIC..."*
>
>
>
> QUIC's connection ID is NOT unique per subscriber. It's per connection. A=
s
> I said on the other thread, in the single-path case, it reveals no more
> informtion than TCP. In the multipath case, it effectively reveals no mor=
e
> than MPTCP, since the ID is used to tie the multiple, using MPTCP
> parlance, "sub-flows", together. It is possible to consider a different
> design that uses multiple connection IDs for the multiple sub-flows, but =
to
> be clear, that makes this new multipath strictly better than MPTCP at
> privacy-preservation.
>
>
>
> At any rate, I wanted to make sure that we're talking about the same
> issue. I'll also note that it's plain wrong to use the term "clear text
> super cookie" in relation to the QUIC connection ID (see
> https://www.techopedia.com/definition/27310/super-cookie for what I think
> a supercookie is.)
>
>
>
> - jana
>
>
>
> On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar  wrote:
>
> That's a design element that should and will definitely be discussed in
> the WG.
>
> Specifically this applies to use of connection IDs during multipath, and =
I
> expect that conversation to happen when we discuss multipath.
>
> On May 21, 2016 6:56 AM, "Ryan Hamilton"  wrote:
>
> Definitely.
>
>
>
> On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) <
> michael.scharf@nokia.com> wrote:
>
> Is it planned to discuss potential privacy implications of the =E2=80=9EQ=
UIC
> connection identifier=E2=80=9C (also named =E2=80=9Cclear text super cook=
ie=E2=80=9D on the SPUD
> list)?
>
>
>
> Thanks
>
>
>
> Michael
>
>
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *EXT Ted Hardie
> *Sent:* Saturday, May 14, 2016 1:27 AM
> *To:* quic@ietf.org; Jana Iyengar; Christian Huitema
> *Subject:* [QUIC] Draft charter
>
>
>
> Howdy,
>
> As part of the BoF preparation, we put together a stab at a draft
> charter.  It's available as html and markdown on github at:
>
> https://github.com/IETF-QUIC/Charter
>
> I've attached the HTML version as well.
>
> It would be great to have some of the discussion on the list before the
> BoF.  Comments to the list or issues/pull requests at the github repo are
> welcome.  We will periodically reflect any issues or suggestion from the
> Repo back to the list, but this will be manual, so expect some lag.
>
>
>
> regards,
>
> Ted
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>
>

--94eb2c12a0629d0b520533861c8a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On S=
at, May 21, 2016 at 8:44 PM, Christian Huitema <huitema@microsoft.com<=
/a>> wrote:













=
Just to be clear, I did use the term =E2=80=9Csuper cookie=
=E2=80=9D in the context of multi-path and mobility. That was triggered
 by the SPUD discussion, during which a proposition surfaced to use a QUIC-=
like connection ID for mobility and multipath, and to standardize that as p=
art of the SPUD header. I think using the same statistically unique 64-bit =
number in the clear text envelope
 of packets sent from different IP addresses is a really bad idea. It is a =
bad idea for MP-TCP, and it would be bad idea for QUIC or SPUD.

I'll disagree that i=
t's a really bad idea, but I'll agree that this is a conversation w=
orth having. And as you point out, we should and will talk about this durin=
g the multipath conversation.

- jana
=C2=A0


=
I do agree with Jana and Ryan that there is no such problem =
if the unique number is only used for a single pair
 of source and destination addresses. And I also agree that the proper time=
 to study privacy-preserving multipath mechanisms is during the study of mu=
ltipath.


=
=C2=A0


=
-- Christian Huitema


=
=C2=A0


=
=C2=A0


=C2=
=A0









From:
 QUIC [mailto:qu=
ic-bounces@ietf.org] On Behalf Of
Jana Iyengar

Sent: Saturday, May 21, 2016=
 5:20 PM

To: Ryan Hamilton <rch@google.com>

Cc: Scharf, Michael (Nokia -=
 DE) <mich=
ael.scharf@nokia.com>; quic@ietf.org

Subject: Re: [QUIC] QUIC pri=
vacy impact






=C2=A0






Michael,






=C2=A0




Just caught up on the SPUD thread, and I'd like =
to correct something you said there that I'll quote here for context:=
=C2=A0




"if there is now a new cle=
ar text identifier that just happens to be unique per subscriber. What a gr=
eat improvement for privacy in the Internet!
 And even better that it seems compatible with QUIC..."<=
/i>






=C2=A0






QUIC's connection ID is NOT unique per subscribe=
r. It's per connection. As I said on the other thread, in the single-pa=
th case, it reveals no more informtion than TCP.
 In the multipath case, it effectively reveals no more than MPTCP, since th=
e ID is used to tie the multiple, using MPTCP parlance,=C2=A0"sub-flow=
s", together. It is possible to consider a different design that uses =
multiple connection IDs for the multiple sub-flows,
 but to be clear, that makes this new multipath strictly better than MPTCP=
=C2=A0at privacy-preservation.






=C2=A0






At any rate, I wanted to make sure that we're ta=
lking about the same issue. I'll also note that it's plain wrong to=
 use the term "clear text super cookie" in relation
 to the QUIC connection ID (see=C2=A0https://www.techopedia.com=
/definition/27310/super-cookie=C2=A0for what I think a supercookie is.)=







=C2=A0






- jana








=C2=A0




On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar <jri@google.com> wr=
ote:




That's a design element that should and will definitely be discussed=
 in the WG.


Specifically this applies to use of connection IDs during multipath, and=
 I expect that conversation to happen when we discuss multipath.<=
/u>








On May 21, 2016 6:56 AM, "Ryan Hamilton" &=
lt;rch@google.com&g=
t; wrote:








Defin=
itely.








=C2=A0




On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (N=
okia - DE) <michael.scharf@nokia.com> wrote:








=
Is it planned to discuss potential privacy implications
 of the =E2=80=9EQUIC connection identifier=E2=80=9C (also named =E2=80=9Cc=
lear text super cookie=E2=80=9D on the SPUD list)?


=
=C2=A0<=
/p>

=
Thanks<=
/p>

=
=C2=A0<=
/p>

=
Michael=



=
=C2=A0<=
/p>

=
=C2=A0<=
/p>








From:
 QUIC [mailto:qu=
ic-bounces@ietf.org]
On Behalf Of EXT Ted Hardie<=
br>
Sent: Saturday, May 14, 2016=
 1:27 AM

To: 
quic@ietf.org; Jana Iyengar; Christian Huitema

Subject: [QUIC] Draft charte=
r






=C2=A0












Howdy,=





As part o=
f the BoF preparation, we put together a stab at a draft charter.=C2=A0 It&=
#39;s available
 as html and markdown on github at:



https://=
github.com/IETF-QUIC/Charter




I've =
attached the HTML version as well.=C2=A0







It would be great to have some of the di=
scussion on the list before the BoF.=C2=A0
 Comments to the list or issues/pull requests at the github repo are welcom=
e.=C2=A0 We will periodically reflect any issues or suggestion from the Rep=
o back to the list, but this will be manual, so expect some lag.<=
/u>






=C2=A0




regards,<=
u>




Ted












_______________________________________________

QUIC mailing list

QUIC@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/quic





=C2=A0






_______________________________________________

QUIC mailing list

QUIC@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/quic













=C2=A0














--94eb2c12a0629d0b520533861c8a--


From nobody Mon May 23 10:55:16 2016
Return-Path: 
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 0181C12DA39 for ; Mon, 23 May 2016 10:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 9Ey72RNHsmBo for ; Mon, 23 May 2016 10:55:13 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 59EBC12DA19 for ; Mon, 23 May 2016 10:55:13 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id h19so25279091ywc.0 for ; Mon, 23 May 2016 10:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F0FouAhHEGNsRsudveyw9DA9xiMP9jqtFXr+FlhGnSE=; b=PCmNJ7JYTtlc1ig3lUwi1lbqckDrdKWeGYgYU8+KHBru8m/UF5bBs+aITHxoMhka0y /rrsiRmofUpEtJm99DhkTjqyGbkJVBHGIYbhEc8dpfBToCKY31CnNu8yHHWBxcSIRkgU KhgVXJ8vPJtB/8EXebOHxYGHb3PI3B9gfuMrFTC957Q16pthYN25jtfXetpZCldKVs8T 51m6lVuxF/5nvikTnWCu6/WPpaus9SqHucmgLakauNLjkSWtvmrQUbgkEgD5uoNqCe2c BeoKo6UcKk79Fq/1SiA1pEcCPt6u2oYxXJYfMbBul8fpqQPJmZ0/haUZV9yFb6xKVngP J7ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F0FouAhHEGNsRsudveyw9DA9xiMP9jqtFXr+FlhGnSE=; b=BKxfSiWlwhQmefopfzDakWnAeFZ5DJagx8WNb6N0f90fqCAYG5cNFeCbYNprhqlS3c UUNyEc9dIhUGU22ntYmFK/+1wH1guXD9caaczuAyfv6G3z1+61ZUDBbCAq53UXs3UBDN cOtlqkUd0pHBTQTbcbn4OjokhqJovnpB6IXMbIeebGezTIsxh+UP4EILrUAdmbR3ga2e o7X54UiHBW7/YvPFgVCAhhZ+SxdF1XotukPJLgldSlY5Aceqrj4Ew1aI6dL8Q1m9PfC+ ZKtpzFFv5vQ5hU01+Db0tUDDczbIhdoH9b1d9HcR2uUhqLEVLCMbYhzmVTgcbb/SlFpu roKA==
X-Gm-Message-State: ALyK8tKh8sUyaUe/OtRRYbUx53aG4+4cwWzxGNqNXTtVWB48x7tqh/qfTJl8pXh58dKmnzEOIFSn7KhU/ZBqaKdu
X-Received: by 10.129.121.81 with SMTP id u78mr41652ywc.239.1464026112542; Mon, 23 May 2016 10:55:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 10:55:11 -0700 (PDT)
In-Reply-To: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>     
From: Jana Iyengar 
Date: Mon, 23 May 2016 10:55:11 -0700
Message-ID: 
To: =?UTF-8?Q?G=C3=B6ran_Eriksson_AP?= 
Content-Type: multipart/alternative; boundary=94eb2c0a7b6861afef05338624c6
Archived-At: 
Cc: Christian Huitema , "Scharf, Michael \(Nokia - DE\)" , "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 17:55:15 -0000

--94eb2c0a7b6861afef05338624c6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, May 22, 2016 at 12:43 AM, G=C3=B6ran Eriksson AP <
goran.ap.eriksson@ericsson.com> wrote:

>
>
> >I do agree with Jana and Ryan that there is no such problem if the uniqu=
e
> >number is only used for a single pair of source and destination
> >addresses.
>
> So if the device move into an area with a new network and obtains another
> host address, then a new connection id would be created by the client?
>
> draft-tsvwg-quic-protocol-02 claims the connection id remain the same eve=
n
> during migration: =E2=80=9CQUIC can survive IP address changes and NAT
>    re-bindings since the Connection ID remains the same across these
> migrations.=E2=80=9D.
>
> This does not fit together does it?
>
> I must be missing something...



The current version of QUIC does use the same connection ID, as you point
out. This is a design decision that will be revisited during the IETF
standardization of QUIC multipath.


> >And I also agree that the proper time to study privacy-preserving
> >multipath mechanisms is during the study of multipath.
>
> +1 And when considering the increased attention to end user privacy and
> security in IETF and W3C, this may mean a renewed look at the these
> aspects of multi path not covered in previous security considerations.
>

+1.

- jana

--94eb2c0a7b6861afef05338624c6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On S=
un, May 22, 2016 at 12:43 AM, G=C3=B6ran Eriksson AP <=
goran.a=
p.eriksson@ericsson.com> wrote:




>I do agree with Jana and Ryan that there is no such problem if the uniq=
ue

>number is only used for a single pair of source and destination

>addresses.



So if the device move into an area with a new network and obtains an=
other

host address, then a new connection id would be created by the client?



draft-tsvwg-quic-protocol-02 claims the connection id remain the same even<=
br>
during migration: =E2=80=9CQUIC can survive IP address changes and NAT

=C2=A0 =C2=A0re-bindings since the Connection ID remains the same across th=
ese

migrations.=E2=80=9D.



This does not fit together does it?



I must be missing something...


The current version of QUIC does use the same connection ID, as you poin=
t out. This is a design decision that will be revisited during the IETF sta=
ndardization of QUIC multipath.
=C2=A0
>And I also agree that the proper time to stu=
dy privacy-preserving

>multipath mechanisms is during the study of multipath.



+1 And when considering the increased attention to end user privacy =
and

security in IETF and W3C, this may mean a renewed look at the these

aspects of multi path not covered in previous security considerations.
<=
/blockquote>

+1.

- jana=C2=A0



--94eb2c0a7b6861afef05338624c6--


From nobody Mon May 23 11:02:05 2016
Return-Path: 
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 99A4212D7E8 for ; Mon, 23 May 2016 11:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 yursIVzmf6t6 for ; Mon, 23 May 2016 11:01:52 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 ACB6A12DA3A for ; Mon, 23 May 2016 11:01:52 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id o16so60774660ywd.2 for ; Mon, 23 May 2016 11:01:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nslXOfAlAVx4/5c1YRFqCL5cdkZdbZPr15vJONUIldk=; b=KEeBpR/TC7NYegGyIuV8WiQmU/kHNdum6BBs4HwQgHyzExylpVeTXBDfq6itU11Kbv GNFd38fl/UGJtKeVsQmrrS33FTHma36HPCXdcC5vm6pQHuFZVKAi4Eq55+YPSxCgDWIt uk1MuDRzkdXZHZNWKJ5Jf1Z1pVL9qKn3qfawwV0lx881QtatW91qBQVk9nRjgN61PUq7 nGHa/yM+LUE6WWD4Sb3NA5GAyz3OjYm2jiydb3v12kNkUPF92hTLCw6Evmv9daUZsmEj B8yoQDaurrahzAW+jScNut/6u35jQncXobAg0bAhDY8/M9hhicCLdR4poY7cQLTRgwqM p3ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nslXOfAlAVx4/5c1YRFqCL5cdkZdbZPr15vJONUIldk=; b=V/F5hdiYFaT/g4GvHPlDCnBMQxLoS+869EGBX/AaYzwISSxomFxU/D+X0KNgYcLgT7 0xDH+NrvEhc0GccvsZQSh4nDTG+i+jmAoAJ4mP7lboZGvIMs+1DmhG6dU/BDMqRt1mkL nEy1ws3qxxt9MzPKmltNM8SBX3/vEG3l0pSrBkZyTZgJ970pHKnLaR0GIfEcXd2GbPc6 IKyRavlsf27tjX+Dvsw6z8yP8GXrzfwxqcTqNuIdc4NiFr/FIe/K+mhFi4cGFtuk6X6F /KzEKr9/caqwkuJh3/rRvXzz0akDns8la6rzjWF/cy9yHSwHGm9Ys8kL/ggZpCDkds4T gE6Q==
X-Gm-Message-State: ALyK8tKiPyboMFA/e7nDmkRT7Sf8thPcIZi58PyzGUk8k4f9avXGAl8yQVZNlZC1xSBpv/fD+Df1lQQFy3XJurcP
X-Received: by 10.37.82.131 with SMTP id g125mr80916ybb.104.1464026511864; Mon, 23 May 2016 11:01:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 11:01:50 -0700 (PDT)
In-Reply-To: <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com>
From: Jana Iyengar 
Date: Mon, 23 May 2016 11:01:50 -0700
Message-ID: 
To: "Scharf, Michael (Nokia - DE)" 
Content-Type: multipart/alternative; boundary=001a11422de42eef190533863c0d
Archived-At: 
Cc: "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 18:02:03 -0000

--001a11422de42eef190533863c0d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, May 22, 2016 at 10:32 AM, Scharf, Michael (Nokia - DE) <
michael.scharf@nokia.com> wrote:

> draft-tsvwg-quic-protocol-02 says:
>
>
>
>   QUIC connections are identified by a 64-bit Connection ID, randomly
>
>    generated by the client.  QUIC can survive IP address changes and NAT
>
>    re-bindings since the Connection ID remains the same across these
>
>    migrations.
>
>
>
> So, can we agree that this statement is very, very vague?
>
>
>
> For instance, could I write a QUIC implementation compliant to
> draft-tsvwg-quic-protocol-02 that e.g. uses a static and a random part of
> the connection ID, and e.g. stores the static part permanently on the
> user=E2=80=99s computer? Or, could I pick as a static part the MAC addres=
s? The
> total ID would still be random. I have difficulties to understand how thi=
s
> sort of ID generation would be different from a =E2=80=9Cclear text super=
 cookie=E2=80=9D
> and what is defined in the reference you provide.
>
>
>
> I am sure that this is not what the current QUIC implementation does. But
> since we are in IETF context, talking about a potential standard, I am
> concerned what other implementers of a new protocol could do, and what us=
e
> cases they could find for this ID.
>
>
>
> And if there was some interesting use of having an entirely user-defined
> clear text value at some constant offset in the packet, for a widely used
> Internet transport protocol, I am pretty sure some implementers would not
> care about some MUSTs in an RFC saying =E2=80=9Cplease, please, please se=
lect every
> bit in the ID randomly=E2=80=9D.
>
>
>
> Or do I miss something obvious?
>

Yes. The fact that you can't keep stupid implementations from hurting user
privacy. The TCP ISN is unspecified, and it can always be used for packing
whatever user-privacy-revealing information you want. That would be very
very dumb, but it's not out of spec for TCP.

I'll agree that we can and should have text in the spec that says
implementations SHOULD not do stupid things.

- jana


>
> Michael
>
>
>
>
>
>
>
>
>
> *From:* Jana Iyengar [mailto:jri@google.com]
> *Sent:* Sunday, May 22, 2016 5:20 AM
> *To:* Ryan Hamilton
> *Cc:* quic@ietf.org; Scharf, Michael (Nokia - DE)
> *Subject:* Re: [QUIC] QUIC privacy impact
>
>
>
> Michael,
>
>
>
> Just caught up on the SPUD thread, and I'd like to correct something you
> said there that I'll quote here for context:
>
> *"if there is now a new clear text identifier that just happens to be
> unique per subscriber. What a great improvement for privacy in the
> Internet! And even better that it seems compatible with QUIC..."*
>
>
>
> QUIC's connection ID is NOT unique per subscriber. It's per connection. A=
s
> I said on the other thread, in the single-path case, it reveals no more
> informtion than TCP. In the multipath case, it effectively reveals no mor=
e
> than MPTCP, since the ID is used to tie the multiple, using MPTCP
> parlance, "sub-flows", together. It is possible to consider a different
> design that uses multiple connection IDs for the multiple sub-flows, but =
to
> be clear, that makes this new multipath strictly better than MPTCP at
> privacy-preservation.
>
>
>
> At any rate, I wanted to make sure that we're talking about the same
> issue. I'll also note that it's plain wrong to use the term "clear text
> super cookie" in relation to the QUIC connection ID (see
> https://www.techopedia.com/definition/27310/super-cookie for what I think
> a supercookie is.)
>
>
>
> - jana
>
>
>
> On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar  wrote:
>
> That's a design element that should and will definitely be discussed in
> the WG.
>
> Specifically this applies to use of connection IDs during multipath, and =
I
> expect that conversation to happen when we discuss multipath.
>
> On May 21, 2016 6:56 AM, "Ryan Hamilton"  wrote:
>
> Definitely.
>
>
>
> On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) <
> michael.scharf@nokia.com> wrote:
>
> Is it planned to discuss potential privacy implications of the =E2=80=9EQ=
UIC
> connection identifier=E2=80=9C (also named =E2=80=9Cclear text super cook=
ie=E2=80=9D on the SPUD
> list)?
>
>
>
> Thanks
>
>
>
> Michael
>
>
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *EXT Ted Hardie
> *Sent:* Saturday, May 14, 2016 1:27 AM
> *To:* quic@ietf.org; Jana Iyengar; Christian Huitema
> *Subject:* [QUIC] Draft charter
>
>
>
> Howdy,
>
> As part of the BoF preparation, we put together a stab at a draft
> charter.  It's available as html and markdown on github at:
>
> https://github.com/IETF-QUIC/Charter
>
> I've attached the HTML version as well.
>
> It would be great to have some of the discussion on the list before the
> BoF.  Comments to the list or issues/pull requests at the github repo are
> welcome.  We will periodically reflect any issues or suggestion from the
> Repo back to the list, but this will be manual, so expect some lag.
>
>
>
> regards,
>
> Ted
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>
>

--001a11422de42eef190533863c0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On S=
un, May 22, 2016 at 10:32 AM, Scharf, Michael (Nokia - DE) <michael=
.scharf@nokia.com> wrote:











draft-tsvw=
g-quic-protocol-02 says:



=C2=
=A0


=C2=A0=C2=A0QUIC connections are identified=
 by a 64-bit Connection ID, randomly


=C2=A0=C2=A0 generated by the client.=C2=A0=
 QUIC can survive IP address changes and NAT


=C2=A0=C2=A0 re-bindings since the Connecti=
on ID remains the same across these


=C2=A0=C2=A0
migrations. 



=C2=A0


So,=
 can we agree that this statement is very, very vague?=



=C2=
=A0


For instan=
ce, could I write a QUIC implementation compliant to draft-tsvwg-quic-proto=
col-02 that e.g. uses a static and a random part of the connection
 ID, and e.g. stores the static part permanently on the user=E2=80=99s comp=
uter? Or, could I pick as a static part the MAC address? The total ID would=
 still be random. I have difficulties to understand how this sort of ID gen=
eration would be different from a =E2=80=9Cclear
 text super cookie=E2=80=9D and what is defined in the reference you provid=
e.


=C2=
=A0


I am sure =
that this is not what the current QUIC implementation does. But since we ar=
e in IETF context, talking about a potential standard, I am
 concerned what other implementers of a new protocol could do, and what use=
 cases they could find for this ID.


=C2=
=A0


And if the=
re was some interesting use of having an entirely user-defined clear text v=
alue at some constant offset in the packet, for a widely used
 Internet transport protocol, I am pretty sure some implementers would not =
care about some MUSTs in an RFC saying =E2=80=9Cplease, please, please sele=
ct every bit in the ID randomly=E2=80=9D.



=C2=
=A0


Or do I mi=
ss something obvious?

Yes. The fact that you can't keep stupid implementations from hurting=
 user privacy. The TCP ISN is unspecified, and it can always be used for pa=
cking whatever user-privacy-revealing information you want. That would be v=
ery very dumb, but it's not out of spec for TCP.

I'll agree that we can and should have text in the spec that says im=
plementations SHOULD not do stupid things.

- jana<=
/div>

=C2=A0

Michael=



=C2=A0


=C2=A0


=C2=
=A0


=C2=
=A0








From: Jana Iye=
ngar [mailto:jri@google=
.com]


Sent: Sunday, May 22, 2016 5:20 AM

To: Ryan Hamilton

Cc: quic@ietf.org=
; Scharf, Michael (Nokia - DE)

Subject: Re: [QUIC] QUIC privacy impact<=
/p>





=C2=A0






Michael,






=C2=A0




Just caught up on the SPUD thread, and I'd like =
to correct something you said there that I'll quote here for context:=
=C2=A0




"if there is now a new clear text identifier=
 that just happens to be unique per subscriber. What a great improvement fo=
r privacy in the Internet! And even better that it seems compatible with QU=
IC..."






=C2=A0






QUIC's connection ID is NOT unique per subscribe=
r. It's per connection. As I said on the other thread, in the single-pa=
th case, it reveals no more informtion than TCP. In the multipath case, it =
effectively reveals no more than MPTCP, since
 the ID is used to tie the multiple, using MPTCP parlance,=C2=A0"sub-f=
lows", together. It is possible to consider a different design that us=
es multiple connection IDs for the multiple sub-flows, but to be clear, tha=
t makes this new multipath strictly better than
 MPTCP=C2=A0at privacy-preservation.






=C2=A0






At any rate, I wanted to make sure that we're ta=
lking about the same issue. I'll also note that it's plain wrong to=
 use the term "clear text super cookie" in relation to the QUIC c=
onnection ID (see=C2=A0https://www.techopedia.com/definition/27=
310/super-cookie=C2=A0for
 what I think a supercookie is.)






=C2=A0






- jana








=C2=A0




On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar <jri@google.com> wr=
ote:


That's a design element that should and will definitely be discussed=
 in the WG.


Specifically this applies to use of connection IDs during multipath, and=
 I expect that conversation to happen when we discuss multipath.<=
/u>








On May 21, 2016 6:56 AM, "Ryan Hamilton" &=
lt;rch@google.com&g=
t; wrote:






Definitely.








=C2=A0




On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (N=
okia - DE) <michael.scharf@nokia.com> wrote:






Is it plan=
ned to discuss potential privacy implications of the =E2=80=9EQUIC connecti=
on identifier=E2=80=9C
 (also named =E2=80=9Cclear text super cookie=E2=80=9D on the SPUD list)?


=C2=A0


Thanks


=C2=A0


Michael


=C2=A0


=C2=A0








From: QUIC [ma=
ilto:quic-bounce=
s@ietf.org]
On Behalf Of EXT Ted Hardie

Sent: Saturday, May 14, 2016 1:27 AM

To: quic@ietf.org=
; Jana Iyengar; Christian Huitema

Subject: [QUIC] Draft charter






=C2=A0












Howdy,<=
/p>



As part of the BoF pr=
eparation, we put together a stab at a draft charter.=C2=A0 It's availa=
ble as html and markdown on github at:



https://=
github.com/IETF-QUIC/Charter




I've attached the=
 HTML version as well.=C2=A0







It would be great to have some of the discussion on =
the list before the BoF.=C2=A0 Comments to the list or issues/pull requests=
 at the github repo are welcome.=C2=A0 We will periodically
 reflect any issues or suggestion from the Repo back to the list, but this =
will be manual, so expect some lag.






=C2=A0




regards,




Ted












_______________________________________________

QUIC mailing list

QUIC@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/quic




=C2=A0






_______________________________________________

QUIC mailing list

QUIC@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/quic










=C2=A0














--001a11422de42eef190533863c0d--


From nobody Mon May 23 11:36:48 2016
Return-Path: 
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 439FD12D1B0 for ; Mon, 23 May 2016 11:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 EVho66v8b_88 for ; Mon, 23 May 2016 11:36:46 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 6832E12D159 for ; Mon, 23 May 2016 11:36:46 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id c127so62489542ywb.1 for ; Mon, 23 May 2016 11:36:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AJHVJQ8fwCEv7Agc1s09TIKRst1E09NGE/G1+4KOoMM=; b=G/kmBu/RMRVNS9efzEILC4VG7ZHYPmptFw6f2JzFExdQSOqDR8HW9/R220TzRG+eAH ILZxaCXz0701PHQaRrGO+t50WSsP9LyaopA9Vpb1Lke/WTMfHb4nJIDf22pS0/9FJbOC e/yEMlzu4bh945Ie3UeflA7ljBQgvPI0RYa98UArimBpts3XWS8lCkS6Z6Kw+SblpnWj F6ivvfcKFVj2hiMlwnIRpW9+ueYPFw2hxCa2BYTk5ey007EflmuSUImsVfphmOewrtmE VXTqIIZphqKOyt7ybsXDKrAt4dnVjnWogIiTxH3b4W9/rUh9JRO7VxkVy7jKNHsTJV9z Z9gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AJHVJQ8fwCEv7Agc1s09TIKRst1E09NGE/G1+4KOoMM=; b=km+nRZSGIbov6oAVYGrdByOWFSaopba+2Gg155CloJaPlmuuLGtLrnm8ETpYRTmRts BP/WtnxCv7gVbkUQ/Ml+aFIkw62vZbUQjLEfGM0QTfHDQCsUPshbEjfQAVm7OJ+wY04J vPlZdXwRlooRQ+w0CpgZ3GlX9rL2ko75xzkS5aVgNGT+ibRfA23Um4QF0og0ASbID8dO RA9hNhtT033YRzUpPagDQowW2xwWHvhFPjmOb20e+alkrQg8srnKSyKN1qcUw1oUJtgv e/2a2sBsn+qp0Hoe3lA9C6rKdfbRu1ejxTZhheyZc5l6En7WTYsLHZgNJ+1IuZxxRYVV iwjA==
X-Gm-Message-State: ALyK8tKT5Vnm9egE3+G8asjBfJpNNgPm3Y05Sk4USQcscv/cQpxB23EemfVM3lZ2GSn0oYGn75JkfCCCuZM6uMwA
X-Received: by 10.37.49.193 with SMTP id x184mr164784ybx.57.1464028605453; Mon, 23 May 2016 11:36:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 11:36:44 -0700 (PDT)
In-Reply-To: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net> 
From: Jana Iyengar 
Date: Mon, 23 May 2016 11:36:44 -0700
Message-ID: 
To: Olivier Bonaventure 
Content-Type: multipart/alternative; boundary=001a1148af18f8aad7053386b81f
Archived-At: 
Cc: "Scharf, Michael \(Nokia - DE\)" , Kyle Rose , Ryan Hamilton , Mark Nottingham , Brian Trammell , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 18:36:48 -0000

--001a1148af18f8aad7053386b81f
Content-Type: text/plain; charset=UTF-8

I agree with the spirit of Mark's and Olivier's assessments. I'm happy to
add wording to the charter but we'd have to be careful. QUIC's comparisons
are not to TCP, MPTCP, SCTP, or TLS1.3 individually, since they all
implement different functions that are all combined in QUIC. I'm happy to
state something along the lines of QUIC using TLS1.3 should have privacy
and security properties that are no worse than a stack comprised of TLS1.3
over one of {TCP, MPTCP, or SCTP}.

Does that sound reasonable?

I'll point out that there's nothing in the current design of QUIC that runs
afoul of this statement (including use of the same connection ID for
multipath). Of course, we can make it better, so let's have that
conversation when specific design questions are being considered.

- jana

On Mon, May 23, 2016 at 12:28 AM, Olivier Bonaventure <
olivier.bonaventure@tessares.net> wrote:

> Mark,
>
> Shooting for perfect privacy is always going to fail.
>>
>
> I totally agree
>
> What we should be aiming for is no worse than TCP -- having stable,
>> well-understood behaviour is the important thing here. The Internet (and
>> the Web) is a platform that people both design for and use with certain
>> assumptions in mind; we shouldn't violate them without very carefully
>> weighing the impact.
>>
>> Making it better than TCP would be a good outcome too, of course.
>>
>> It would be nice to have something in the charter stating "no worse than
>> TCP" for privacy and possibly other properties as well.
>>
>
> This is exactly the type of wording that we should have in the charter for
> various mechanisms that already exist and are/will be included in QUIC.
>
> For congestion control, QUIC should reuse the existing (single-path and
> multipath) TCP congestion control schemes.
>
> For privacy, QUIC should not be worse than existing transport protocols
> (TCP, Multipath TCP, SCTP). For Multipath TCP, we took this approach for
> security and it turned out to be good.
>
> Same applies probably for the security features in relation with TLS 1.3
> and perhaps HTTP/2 for the API discussion.
>
> Olivier
>
> --
>
> ------------------------------
> DISCLAIMER.
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> This message contains confidential information and is intended only for the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. If you are not the intended recipient
> you are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this information is strictly
> prohibited.
>

--001a1148af18f8aad7053386b81f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I agree with the spirit of Mark's and Olivier's as=
sessments. I'm happy to add wording to the charter but we'd have to=
 be careful. QUIC's comparisons are not to TCP, MPTCP, SCTP, or TLS1.3 =
individually, since they all implement different functions that are all com=
bined in QUIC. I'm happy to state something along the lines of QUIC usi=
ng TLS1.3 should have privacy and security properties that are no worse tha=
n a stack comprised of TLS1.3 over one of=C2=A0{TCP, MPTCP, or SCTP}.=C2=A0=


Does that sound reasonable?

I'll point out that there's nothing in the current design of QUIC=
 that runs afoul of this statement (including use of the same connection ID=
 for multipath). Of course, we can make it better, so let's have that c=
onversation when specific design questions are being considered.

- jana

On Mon, May 23, 2016 at 12:28 AM, Olivier=
 Bonaventure <olivier.bonaventure@tessares.net> wrote:
Mark,





Shooting for perfect privacy is always going to fail.





I totally agree





What we should be aiming for is no worse than TCP -- having stable, well-un=
derstood behaviour is the important thing here. The Internet (and the Web) =
is a platform that people both design for and use with certain assumptions =
in mind; we shouldn't violate them without very carefully weighing the =
impact.



Making it better than TCP would be a good outcome too, of course.



It would be nice to have something in the charter stating "no worse th=
an TCP" for privacy and possibly other properties as well.





This is exactly the type of wording that we should have in the charter for =
various mechanisms that already exist and are/will be included in QUIC.



For congestion control, QUIC should reuse the existing (single-path and mul=
tipath) TCP congestion control schemes.



For privacy, QUIC should not be worse than existing transport protocols (TC=
P, Multipath TCP, SCTP). For Multipath TCP, we took this approach for secur=
ity and it turned out to be good.



Same applies probably for the security features in relation with TLS 1.3 an=
d perhaps HTTP/2 for the API discussion.



Olivier



-- 



------------------------------

DISCLAIMER.

This email and any files transmitted with it are confidential and intended =
solely for the use of the individual or entity to whom they are addressed. =
If you have received this email in error please notify the system manager. =
This message contains confidential information and is intended only for the=
 individual named. If you are not the named addressee you should not dissem=
inate, distribute or copy this e-mail. Please notify the sender immediately=
 by e-mail if you have received this e-mail by mistake and delete this e-ma=
il from your system. If you are not the intended recipient you are notified=
 that disclosing, copying, distributing or taking any action in reliance on=
 the contents of this information is strictly prohibited.





--001a1148af18f8aad7053386b81f--


From nobody Mon May 23 12:16:39 2016
Return-Path: 
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 C718F12D094 for ; Mon, 23 May 2016 12:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 JqdKjPwAjmcm for ; Mon, 23 May 2016 12:16:33 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207C312D4FC for ; Mon, 23 May 2016 12:16:33 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 1E14C5990A402; Mon, 23 May 2016 19:16:27 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NJGUtV003971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 19:16:30 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NJGTmK007880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 21:16:29 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 23 May 2016 21:16:29 +0200
From: "Scharf, Michael (Nokia - DE)" 
To: Jana Iyengar 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynFCnTysxHU/0GFj3E4WoIavJ/DSSMAgAAj/ACAALzBAIABBqOQgAGB/gCAACh9YA==
Date: Mon, 23 May 2016 19:16:28 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48863C11@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48863C11FR712WXCHMBA15z_"
MIME-Version: 1.0
Archived-At: 
Cc: "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 19:16:37 -0000

--_000_655C07320163294895BBADA28372AF5D48863C11FR712WXCHMBA15z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhbSBjZXJ0YWlubHkgbm90IGNvbmNlcm5lZCBhYm91dCDigJxzdHVwaWTigJ0gaW1wbGVtZW50
YXRpb25zLiBJIGFtIGNvbmNlcm5lZCBhYm91dCBpbXBsZW1lbnRhdGlvbnMgdGhhdCB1bmRlcnN0
YW5kIGhvdyB0byDigJxpbnRlbGxpZ2VudGx54oCdIGxldmVyYWdlIHRoaXMgaWRlbnRpZmllciBh
bmQgdGhpcyBpcyB0aGUgdHlwZSBvZiBhbmFseXNpcyBJIGV4cGVjdCBpbiBhIGNvbXByZWhlbnNp
dmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uLiBTb21lIG9mIHRoZSBtYWxpY2lvdXMg
dXNlIGlmIHRoaXMgSUQgbWF5IHBlcmhhcHMgYmUgY2xhc3NpZmllZCBieSBhcyBhbiBhY3RpdmUg
YXR0YWNrIG9uIHVzZXIgcHJpdmFjeSBidXQgc3RpbGwgdGhlIGF0dGFjayB2ZWN0b3Igc2VlbXMg
dG8gbWUgcXVpdGUgZGlmZmVyZW50IHRvIHdoYXQgYW4gYXR0YWNrZXIgY2FuIGRvIHdpdGggc2lt
aWxhciBtZWFucyB3aXRoIFRDUC4NCg0KQXQgZmlyc3Qgc2lnaHQgSSBzZWUgcXVpdGUgYSBudW1i
ZXIgb2YgYWRkaXRpb25hbCBwcm9ibGVtcyBjb21wYXJlZCB0byB0aGUgVENQIElTTjoNCg0KDQrC
tyAgICAgICAgIEFzIFRDUCBzdGFja3MgZG8gbm90IG9mZmVyIGFuIEFQSSBmb3Igc2V0dGluZyB0
aGUgSVNOLCBtb2RpZmljYXRpb24gb2YgdGhlIFRDUCBJU04gd291bGQgcmVxdWlyZSBhIGtlcm5l
bCBwYXRjaCwgYWRtaW5pc3RyYXRvciByaWdodHMsIGV0Yy4gVGhlIGJhcnJpZXIgZm9yIHRoYXQg
aXMgaGlnaC4gVGhlIGRlcGxveW1lbnQgbW9kZWwgb2YgYSB1c2VyIHNwYWNlIFVEUCBwcm90b2Nv
bCBzdGFjayBzZWVtcyBkaWZmZXJlbnQgdG8gdGhhdC4NCg0KwrcgICAgICAgICBUaGUgVENQIElT
TiB3aWxsIG5vdCBiZSBjb252ZXllZCBvdmVyIFRDUC9IVFRQIHByb3hpZXMgYW5kIHRoZXJlIGFy
ZSBmaXJld2FsbHMgdGhhdCByYW5kb21pemUgdGhlIElTTi4gU28sIHVzaW5nIHRoZSBUQ1AgSVNO
IGFzIGEgY292ZXJ0IGNoYW5uZWwgb3Ig4oCcY2xlYXIgdGV4dCBzdXBlciBjb29raWXigJ0gd291
bGQgbm90IHdvcmsgaW4gbWFueSBlbnZpcm9ubWVudHMNCg0KwrcgICAgICAgICBUaGUgSVNOIG9u
bHkgYXBwbGllcyB0byB0aGUgU1lOIGFuZCBub3QgdG8gZXZlcnkgcGFja2V0LCBzbyBhdCBsZWFz
dCBtb25pdG9yaW5nIG9mIHRoZSBJU04gYnkgYSBwYXNzaXZlIGF0dGFjayBzZWVtcyBtb3JlIGRp
ZmZpY3VsdA0KDQrCtyAgICAgICAgIFRoZXJlIGFyZSBvbmx5IDMyIGJpdHMgKHBvc3NpYmx5IHNv
bWUgbW9yZSB3aGVuIHVzaW5nIG90aGVyIGhlYWRlciBmaWVsZHMpDQoNCsK3ICAgICAgICAgSSBm
YWlsIHRvIHVuZGVyc3RhbmQgaG93IGEgcGFzc2l2ZSBhdHRhY2tlciBjYW4gdXNlIHRoZSBJU04g
cGFzc2l2ZWx5IGZvciB1c2VyIGxvY2F0aW9uIHRyYWNraW5nIGV0Yy4NCg0KQW55d2F5LCBJIGJl
bGlldmUgdGhhdCB0aGUgUVVJQyBjb25uZWN0aW9uIElEIGhhcyB0byBiZSBjYXJlZnVsbHkgcmV2
aWV3ZWQgYnkgYmV0dGVyIHNlY3VyaXR5IGV4cGVydHMgdGhhbiBtZSwgc28gSSBhbSBjZXJ0YWlu
bHkgd2lsbGluZyB0byBsZWFybiBpZiBJIG1pc3Mgc29tZXRoaW5nLg0KDQpNaWNoYWVsDQoNCg0K
RnJvbTogSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21dDQpTZW50OiBNb25kYXks
IE1heSAyMywgMjAxNiA4OjAyIFBNDQpUbzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKQ0K
Q2M6IFJ5YW4gSGFtaWx0b247IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbUVVJQ10gUVVJ
QyBwcml2YWN5IGltcGFjdA0KDQpPbiBTdW4sIE1heSAyMiwgMjAxNiBhdCAxMDozMiBBTSwgU2No
YXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPG1haWx0
bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20+PiB3cm90ZToNCmRyYWZ0LXRzdndnLXF1aWMtcHJv
dG9jb2wtMDIgc2F5czoNCg0KICBRVUlDIGNvbm5lY3Rpb25zIGFyZSBpZGVudGlmaWVkIGJ5IGEg
NjQtYml0IENvbm5lY3Rpb24gSUQsIHJhbmRvbWx5DQogICBnZW5lcmF0ZWQgYnkgdGhlIGNsaWVu
dC4gIFFVSUMgY2FuIHN1cnZpdmUgSVAgYWRkcmVzcyBjaGFuZ2VzIGFuZCBOQVQNCiAgIHJlLWJp
bmRpbmdzIHNpbmNlIHRoZSBDb25uZWN0aW9uIElEIHJlbWFpbnMgdGhlIHNhbWUgYWNyb3NzIHRo
ZXNlDQogICBtaWdyYXRpb25zLg0KDQpTbywgY2FuIHdlIGFncmVlIHRoYXQgdGhpcyBzdGF0ZW1l
bnQgaXMgdmVyeSwgdmVyeSB2YWd1ZT8NCg0KRm9yIGluc3RhbmNlLCBjb3VsZCBJIHdyaXRlIGEg
UVVJQyBpbXBsZW1lbnRhdGlvbiBjb21wbGlhbnQgdG8gZHJhZnQtdHN2d2ctcXVpYy1wcm90b2Nv
bC0wMiB0aGF0IGUuZy4gdXNlcyBhIHN0YXRpYyBhbmQgYSByYW5kb20gcGFydCBvZiB0aGUgY29u
bmVjdGlvbiBJRCwgYW5kIGUuZy4gc3RvcmVzIHRoZSBzdGF0aWMgcGFydCBwZXJtYW5lbnRseSBv
biB0aGUgdXNlcuKAmXMgY29tcHV0ZXI/IE9yLCBjb3VsZCBJIHBpY2sgYXMgYSBzdGF0aWMgcGFy
dCB0aGUgTUFDIGFkZHJlc3M/IFRoZSB0b3RhbCBJRCB3b3VsZCBzdGlsbCBiZSByYW5kb20uIEkg
aGF2ZSBkaWZmaWN1bHRpZXMgdG8gdW5kZXJzdGFuZCBob3cgdGhpcyBzb3J0IG9mIElEIGdlbmVy
YXRpb24gd291bGQgYmUgZGlmZmVyZW50IGZyb20gYSDigJxjbGVhciB0ZXh0IHN1cGVyIGNvb2tp
ZeKAnSBhbmQgd2hhdCBpcyBkZWZpbmVkIGluIHRoZSByZWZlcmVuY2UgeW91IHByb3ZpZGUuDQoN
CkkgYW0gc3VyZSB0aGF0IHRoaXMgaXMgbm90IHdoYXQgdGhlIGN1cnJlbnQgUVVJQyBpbXBsZW1l
bnRhdGlvbiBkb2VzLiBCdXQgc2luY2Ugd2UgYXJlIGluIElFVEYgY29udGV4dCwgdGFsa2luZyBh
Ym91dCBhIHBvdGVudGlhbCBzdGFuZGFyZCwgSSBhbSBjb25jZXJuZWQgd2hhdCBvdGhlciBpbXBs
ZW1lbnRlcnMgb2YgYSBuZXcgcHJvdG9jb2wgY291bGQgZG8sIGFuZCB3aGF0IHVzZSBjYXNlcyB0
aGV5IGNvdWxkIGZpbmQgZm9yIHRoaXMgSUQuDQoNCkFuZCBpZiB0aGVyZSB3YXMgc29tZSBpbnRl
cmVzdGluZyB1c2Ugb2YgaGF2aW5nIGFuIGVudGlyZWx5IHVzZXItZGVmaW5lZCBjbGVhciB0ZXh0
IHZhbHVlIGF0IHNvbWUgY29uc3RhbnQgb2Zmc2V0IGluIHRoZSBwYWNrZXQsIGZvciBhIHdpZGVs
eSB1c2VkIEludGVybmV0IHRyYW5zcG9ydCBwcm90b2NvbCwgSSBhbSBwcmV0dHkgc3VyZSBzb21l
IGltcGxlbWVudGVycyB3b3VsZCBub3QgY2FyZSBhYm91dCBzb21lIE1VU1RzIGluIGFuIFJGQyBz
YXlpbmcg4oCccGxlYXNlLCBwbGVhc2UsIHBsZWFzZSBzZWxlY3QgZXZlcnkgYml0IGluIHRoZSBJ
RCByYW5kb21seeKAnS4NCg0KT3IgZG8gSSBtaXNzIHNvbWV0aGluZyBvYnZpb3VzPw0KDQpZZXMu
IFRoZSBmYWN0IHRoYXQgeW91IGNhbid0IGtlZXAgc3R1cGlkIGltcGxlbWVudGF0aW9ucyBmcm9t
IGh1cnRpbmcgdXNlciBwcml2YWN5LiBUaGUgVENQIElTTiBpcyB1bnNwZWNpZmllZCwgYW5kIGl0
IGNhbiBhbHdheXMgYmUgdXNlZCBmb3IgcGFja2luZyB3aGF0ZXZlciB1c2VyLXByaXZhY3ktcmV2
ZWFsaW5nIGluZm9ybWF0aW9uIHlvdSB3YW50LiBUaGF0IHdvdWxkIGJlIHZlcnkgdmVyeSBkdW1i
LCBidXQgaXQncyBub3Qgb3V0IG9mIHNwZWMgZm9yIFRDUC4NCg0KSSdsbCBhZ3JlZSB0aGF0IHdl
IGNhbiBhbmQgc2hvdWxkIGhhdmUgdGV4dCBpbiB0aGUgc3BlYyB0aGF0IHNheXMgaW1wbGVtZW50
YXRpb25zIFNIT1VMRCBub3QgZG8gc3R1cGlkIHRoaW5ncy4NCg0KLSBqYW5hDQoNCg0KTWljaGFl
bA0KDQoNCg0KDQpGcm9tOiBKYW5hIEl5ZW5nYXIgW21haWx0bzpqcmlAZ29vZ2xlLmNvbTxtYWls
dG86anJpQGdvb2dsZS5jb20+XQ0KU2VudDogU3VuZGF5LCBNYXkgMjIsIDIwMTYgNToyMCBBTQ0K
VG86IFJ5YW4gSGFtaWx0b24NCkNjOiBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3Jn
PjsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKQ0KU3ViamVjdDogUmU6IFtRVUlDXSBRVUlD
IHByaXZhY3kgaW1wYWN0DQoNCk1pY2hhZWwsDQoNCkp1c3QgY2F1Z2h0IHVwIG9uIHRoZSBTUFVE
IHRocmVhZCwgYW5kIEknZCBsaWtlIHRvIGNvcnJlY3Qgc29tZXRoaW5nIHlvdSBzYWlkIHRoZXJl
IHRoYXQgSSdsbCBxdW90ZSBoZXJlIGZvciBjb250ZXh0Og0KImlmIHRoZXJlIGlzIG5vdyBhIG5l
dyBjbGVhciB0ZXh0IGlkZW50aWZpZXIgdGhhdCBqdXN0IGhhcHBlbnMgdG8gYmUgdW5pcXVlIHBl
ciBzdWJzY3JpYmVyLiBXaGF0IGEgZ3JlYXQgaW1wcm92ZW1lbnQgZm9yIHByaXZhY3kgaW4gdGhl
IEludGVybmV0ISBBbmQgZXZlbiBiZXR0ZXIgdGhhdCBpdCBzZWVtcyBjb21wYXRpYmxlIHdpdGgg
UVVJQy4uLiINCg0KUVVJQydzIGNvbm5lY3Rpb24gSUQgaXMgTk9UIHVuaXF1ZSBwZXIgc3Vic2Ny
aWJlci4gSXQncyBwZXIgY29ubmVjdGlvbi4gQXMgSSBzYWlkIG9uIHRoZSBvdGhlciB0aHJlYWQs
IGluIHRoZSBzaW5nbGUtcGF0aCBjYXNlLCBpdCByZXZlYWxzIG5vIG1vcmUgaW5mb3JtdGlvbiB0
aGFuIFRDUC4gSW4gdGhlIG11bHRpcGF0aCBjYXNlLCBpdCBlZmZlY3RpdmVseSByZXZlYWxzIG5v
IG1vcmUgdGhhbiBNUFRDUCwgc2luY2UgdGhlIElEIGlzIHVzZWQgdG8gdGllIHRoZSBtdWx0aXBs
ZSwgdXNpbmcgTVBUQ1AgcGFybGFuY2UsICJzdWItZmxvd3MiLCB0b2dldGhlci4gSXQgaXMgcG9z
c2libGUgdG8gY29uc2lkZXIgYSBkaWZmZXJlbnQgZGVzaWduIHRoYXQgdXNlcyBtdWx0aXBsZSBj
b25uZWN0aW9uIElEcyBmb3IgdGhlIG11bHRpcGxlIHN1Yi1mbG93cywgYnV0IHRvIGJlIGNsZWFy
LCB0aGF0IG1ha2VzIHRoaXMgbmV3IG11bHRpcGF0aCBzdHJpY3RseSBiZXR0ZXIgdGhhbiBNUFRD
UCBhdCBwcml2YWN5LXByZXNlcnZhdGlvbi4NCg0KQXQgYW55IHJhdGUsIEkgd2FudGVkIHRvIG1h
a2Ugc3VyZSB0aGF0IHdlJ3JlIHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUgaXNzdWUuIEknbGwgYWxz
byBub3RlIHRoYXQgaXQncyBwbGFpbiB3cm9uZyB0byB1c2UgdGhlIHRlcm0gImNsZWFyIHRleHQg
c3VwZXIgY29va2llIiBpbiByZWxhdGlvbiB0byB0aGUgUVVJQyBjb25uZWN0aW9uIElEIChzZWUg
aHR0cHM6Ly93d3cudGVjaG9wZWRpYS5jb20vZGVmaW5pdGlvbi8yNzMxMC9zdXBlci1jb29raWUg
Zm9yIHdoYXQgSSB0aGluayBhIHN1cGVyY29va2llIGlzLikNCg0KLSBqYW5hDQoNCk9uIFNhdCwg
TWF5IDIxLCAyMDE2IGF0IDk6MDQgQU0sIEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb208bWFp
bHRvOmpyaUBnb29nbGUuY29tPj4gd3JvdGU6DQoNClRoYXQncyBhIGRlc2lnbiBlbGVtZW50IHRo
YXQgc2hvdWxkIGFuZCB3aWxsIGRlZmluaXRlbHkgYmUgZGlzY3Vzc2VkIGluIHRoZSBXRy4NCg0K
U3BlY2lmaWNhbGx5IHRoaXMgYXBwbGllcyB0byB1c2Ugb2YgY29ubmVjdGlvbiBJRHMgZHVyaW5n
IG11bHRpcGF0aCwgYW5kIEkgZXhwZWN0IHRoYXQgY29udmVyc2F0aW9uIHRvIGhhcHBlbiB3aGVu
IHdlIGRpc2N1c3MgbXVsdGlwYXRoLg0KT24gTWF5IDIxLCAyMDE2IDY6NTYgQU0sICJSeWFuIEhh
bWlsdG9uIiA8cmNoQGdvb2dsZS5jb208bWFpbHRvOnJjaEBnb29nbGUuY29tPj4gd3JvdGU6DQpE
ZWZpbml0ZWx5Lg0KDQpPbiBGcmksIE1heSAyMCwgMjAxNiBhdCAxMToyNiBQTSwgU2NoYXJmLCBN
aWNoYWVsIChOb2tpYSAtIERFKSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPG1haWx0bzptaWNo
YWVsLnNjaGFyZkBub2tpYS5jb20+PiB3cm90ZToNCklzIGl0IHBsYW5uZWQgdG8gZGlzY3VzcyBw
b3RlbnRpYWwgcHJpdmFjeSBpbXBsaWNhdGlvbnMgb2YgdGhlIOKAnlFVSUMgY29ubmVjdGlvbiBp
ZGVudGlmaWVy4oCcIChhbHNvIG5hbWVkIOKAnGNsZWFyIHRleHQgc3VwZXIgY29va2ll4oCdIG9u
IHRoZSBTUFVEIGxpc3QpPw0KDQpUaGFua3MNCg0KTWljaGFlbA0KDQoNCkZyb206IFFVSUMgW21h
aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5d
IE9uIEJlaGFsZiBPZiBFWFQgVGVkIEhhcmRpZQ0KU2VudDogU2F0dXJkYXksIE1heSAxNCwgMjAx
NiAxOjI3IEFNDQpUbzogcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz47IEphbmEg
SXllbmdhcjsgQ2hyaXN0aWFuIEh1aXRlbWENClN1YmplY3Q6IFtRVUlDXSBEcmFmdCBjaGFydGVy
DQoNCkhvd2R5LA0KQXMgcGFydCBvZiB0aGUgQm9GIHByZXBhcmF0aW9uLCB3ZSBwdXQgdG9nZXRo
ZXIgYSBzdGFiIGF0IGEgZHJhZnQgY2hhcnRlci4gIEl0J3MgYXZhaWxhYmxlIGFzIGh0bWwgYW5k
IG1hcmtkb3duIG9uIGdpdGh1YiBhdDoNCg0KaHR0cHM6Ly9naXRodWIuY29tL0lFVEYtUVVJQy9D
aGFydGVyDQpJJ3ZlIGF0dGFjaGVkIHRoZSBIVE1MIHZlcnNpb24gYXMgd2VsbC4NCkl0IHdvdWxk
IGJlIGdyZWF0IHRvIGhhdmUgc29tZSBvZiB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBiZWZv
cmUgdGhlIEJvRi4gIENvbW1lbnRzIHRvIHRoZSBsaXN0IG9yIGlzc3Vlcy9wdWxsIHJlcXVlc3Rz
IGF0IHRoZSBnaXRodWIgcmVwbyBhcmUgd2VsY29tZS4gIFdlIHdpbGwgcGVyaW9kaWNhbGx5IHJl
ZmxlY3QgYW55IGlzc3VlcyBvciBzdWdnZXN0aW9uIGZyb20gdGhlIFJlcG8gYmFjayB0byB0aGUg
bGlzdCwgYnV0IHRoaXMgd2lsbCBiZSBtYW51YWwsIHNvIGV4cGVjdCBzb21lIGxhZy4NCg0KcmVn
YXJkcywNClRlZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KUVVJQyBtYWlsaW5nIGxpc3QNClFVSUNAaWV0Zi5vcmc8bWFpbHRvOlFVSUNAaWV0Zi5v
cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3F1aWMNCg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUVVJQyBtYWlsaW5n
IGxpc3QNClFVSUNAaWV0Zi5vcmc8bWFpbHRvOlFVSUNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3F1aWMNCg0KDQo=

--_000_655C07320163294895BBADA28372AF5D48863C11FR712WXCHMBA15z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw
YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0
eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y
bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox
Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss
IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy
bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ
dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRl
LCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IlNwcmVjaGJsYXNlbnRleHQgWmNobiI7DQoJbWFyZ2luOjBjbTsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ
YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN
CgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNt
Ow0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNw
YW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZv
cmxhZ2UxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5TcHJlY2hibGFz
ZW50ZXh0WmNobg0KCXttc28tc3R5bGUtbmFtZToiU3ByZWNoYmxhc2VudGV4dCBaY2huIjsNCglt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6U3ByZWNoYmxhc2VudGV4dDsN
Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp
b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3MTMzODY4NzU7DQoJbXNvLWxpc3QtdHlw
ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEzOTk2NDc5MTYgNjc1Njc2MTcgNjc1
Njc2MTkgNjc1Njc2MjEgNjc1Njc2MTcgNjc1Njc2MTkgNjc1Njc2MjEgNjc1Njc2MTcgNjc1Njc2
MTkgNjc1Njc2MjE7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJ
e21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+
PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4
dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh
eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkkgYW0gY2VydGFpbmx5IG5vdCBjb25jZXJuZWQgYWJvdXQg4oCcc3R1cGlk
4oCdIGltcGxlbWVudGF0aW9ucy4gSSBhbSBjb25jZXJuZWQgYWJvdXQgaW1wbGVtZW50YXRpb25z
IHRoYXQgdW5kZXJzdGFuZCBob3cgdG8g4oCcaW50ZWxsaWdlbnRseeKAnSBsZXZlcmFnZQ0KIHRo
aXMgaWRlbnRpZmllciBhbmQgdGhpcyBpcyB0aGUgdHlwZSBvZiBhbmFseXNpcyBJIGV4cGVjdCBp
biBhIGNvbXByZWhlbnNpdmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uLiBTb21lIG9m
IHRoZSBtYWxpY2lvdXMgdXNlIGlmIHRoaXMgSUQgbWF5IHBlcmhhcHMgYmUgY2xhc3NpZmllZCBi
eSBhcyBhbiBhY3RpdmUgYXR0YWNrIG9uIHVzZXIgcHJpdmFjeSBidXQgc3RpbGwgdGhlIGF0dGFj
ayB2ZWN0b3Igc2VlbXMgdG8gbWUgcXVpdGUNCiBkaWZmZXJlbnQgdG8gd2hhdCBhbiBhdHRhY2tl
ciBjYW4gZG8gd2l0aCBzaW1pbGFyIG1lYW5zIHdpdGggVENQLiA8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+QXQgZmlyc3Qgc2lnaHQgSSBzZWUgcXVpdGUgYSBudW1iZXIgb2Yg
YWRkaXRpb25hbCBwcm9ibGVtcyBjb21wYXJlZCB0byB0aGUgVENQIElTTjo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBw
dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xv
cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm
b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl
bmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5BcyBUQ1Agc3RhY2tzIGRvIG5vdCBvZmZlciBhbiBBUEkgZm9yIHNldHRpbmcgdGhlIElT
TiwgbW9kaWZpY2F0aW9uIG9mIHRoZSBUQ1AgSVNOIHdvdWxkIHJlcXVpcmUgYSBrZXJuZWwgcGF0
Y2gsIGFkbWluaXN0cmF0b3IgcmlnaHRzLA0KIGV0Yy4gVGhlIGJhcnJpZXIgZm9yIHRoYXQgaXMg
aGlnaC4gVGhlIGRlcGxveW1lbnQgbW9kZWwgb2YgYSB1c2VyIHNwYWNlIFVEUCBwcm90b2NvbCBz
dGFjayBzZWVtcyBkaWZmZXJlbnQgdG8gdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp
c3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3
RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBw
dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhl
IFRDUCBJU04gd2lsbCBub3QgYmUgY29udmV5ZWQgb3ZlciBUQ1AvSFRUUCBwcm94aWVzIGFuZCB0
aGVyZSBhcmUgZmlyZXdhbGxzIHRoYXQgcmFuZG9taXplIHRoZSBJU04uIFNvLCB1c2luZyB0aGUg
VENQIElTTiBhcyBhIGNvdmVydA0KIGNoYW5uZWwgb3Ig4oCcY2xlYXIgdGV4dCBzdXBlciBjb29r
aWXigJ0gd291bGQgbm90IHdvcmsgaW4gbWFueSBlbnZpcm9ubWVudHM8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0x
OC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7
Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHls
ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+
PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+VGhlIElTTiBvbmx5IGFwcGxpZXMgdG8gdGhlIFNZTiBhbmQgbm90IHRvIGV2ZXJ5
IHBhY2tldCwgc28gYXQgbGVhc3QgbW9uaXRvcmluZyBvZiB0aGUgSVNOIGJ5IGEgcGFzc2l2ZSBh
dHRhY2sgc2VlbXMgbW9yZSBkaWZmaWN1bHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6
bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+
PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm
cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUg
YXJlIG9ubHkgMzIgYml0cyAocG9zc2libHkgc29tZSBtb3JlIHdoZW4gdXNpbmcgb3RoZXIgaGVh
ZGVyIGZpZWxkcyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn
cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi
PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z
by1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg
Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBmYWlsIHRvIHVuZGVyc3RhbmQg
aG93IGEgcGFzc2l2ZSBhdHRhY2tlciBjYW4gdXNlIHRoZSBJU04gcGFzc2l2ZWx5IGZvciB1c2Vy
IGxvY2F0aW9uIHRyYWNraW5nIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+QW55d2F5LCBJIGJlbGlldmUgdGhhdCB0aGUgUVVJQyBjb25uZWN0aW9uIElEIGhhcyB0byBi
ZSBjYXJlZnVsbHkgcmV2aWV3ZWQgYnkgYmV0dGVyIHNlY3VyaXR5IGV4cGVydHMgdGhhbiBtZSwg
c28gSSBhbSBjZXJ0YWlubHkgd2lsbGluZyB0byBsZWFybg0KIGlmIEkgbWlzcyBzb21ldGhpbmcu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n
OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmFuYSBJeWVuZ2FyIFttYWls
dG86anJpQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXkgMjMsIDIw
MTYgODowMiBQTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTxi
cj4NCjxiPkNjOjwvYj4gUnlhbiBIYW1pbHRvbjsgcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl
Y3Q6PC9iPiBSZTogW1FVSUNdIFFVSUMgcHJpdmFjeSBpbXBhY3Q8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4s
IE1heSAyMiwgMjAxNiBhdCAxMDozMiBBTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSAm
bHQ7PGEgaHJlZj0ibWFpbHRvOm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxh
bmsiPm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ZHJhZnQtdHN2d2ctcXVpYy1w
cm90b2NvbC0wMiBzYXlzOg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDtRVUlDIGNvbm5lY3Rpb25zIGFy
ZSBpZGVudGlmaWVkIGJ5IGEgNjQtYml0IENvbm5lY3Rpb24gSUQsIHJhbmRvbWx5PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPiZuYnNwOyZuYnNwOyBnZW5lcmF0ZWQgYnkgdGhlIGNsaWVudC4mbmJzcDsgUVVJQyBjYW4g
c3Vydml2ZSBJUCBhZGRyZXNzIGNoYW5nZXMgYW5kIE5BVDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz
cDsgcmUtYmluZGluZ3Mgc2luY2UgdGhlIENvbm5lY3Rpb24gSUQgcmVtYWlucyB0aGUgc2FtZSBh
Y3Jvc3MgdGhlc2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm1p
Z3JhdGlvbnMuIDwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPlNvLCBjYW4gd2UgYWdyZWUgdGhhdCB0aGlzIHN0YXRlbWVudCBpcyB2ZXJ5LCB2ZXJ5
IHZhZ3VlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIGluc3Rh
bmNlLCBjb3VsZCBJIHdyaXRlIGEgUVVJQyBpbXBsZW1lbnRhdGlvbiBjb21wbGlhbnQgdG8gZHJh
ZnQtdHN2d2ctcXVpYy1wcm90b2NvbC0wMg0KIHRoYXQgZS5nLiB1c2VzIGEgc3RhdGljIGFuZCBh
IHJhbmRvbSBwYXJ0IG9mIHRoZSBjb25uZWN0aW9uIElELCBhbmQgZS5nLiBzdG9yZXMgdGhlIHN0
YXRpYyBwYXJ0IHBlcm1hbmVudGx5IG9uIHRoZSB1c2Vy4oCZcyBjb21wdXRlcj8gT3IsIGNvdWxk
IEkgcGljayBhcyBhIHN0YXRpYyBwYXJ0IHRoZSBNQUMgYWRkcmVzcz8gVGhlIHRvdGFsIElEIHdv
dWxkIHN0aWxsIGJlIHJhbmRvbS4gSSBoYXZlIGRpZmZpY3VsdGllcyB0byB1bmRlcnN0YW5kIGhv
dw0KIHRoaXMgc29ydCBvZiBJRCBnZW5lcmF0aW9uIHdvdWxkIGJlIGRpZmZlcmVudCBmcm9tIGEg
4oCcY2xlYXIgdGV4dCBzdXBlciBjb29raWXigJ0gYW5kIHdoYXQgaXMgZGVmaW5lZCBpbiB0aGUg
cmVmZXJlbmNlIHlvdSBwcm92aWRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+SSBhbSBzdXJlIHRoYXQgdGhpcyBpcyBub3Qgd2hhdCB0aGUgY3VycmVudCBRVUlDIGlt
cGxlbWVudGF0aW9uIGRvZXMuIEJ1dCBzaW5jZSB3ZSBhcmUNCiBpbiBJRVRGIGNvbnRleHQsIHRh
bGtpbmcgYWJvdXQgYSBwb3RlbnRpYWwgc3RhbmRhcmQsIEkgYW0gY29uY2VybmVkIHdoYXQgb3Ro
ZXIgaW1wbGVtZW50ZXJzIG9mIGEgbmV3IHByb3RvY29sIGNvdWxkIGRvLCBhbmQgd2hhdCB1c2Ug
Y2FzZXMgdGhleSBjb3VsZCBmaW5kIGZvciB0aGlzIElELjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+QW5kIGlmIHRoZXJlIHdhcyBzb21lIGludGVyZXN0aW5nIHVzZSBv
ZiBoYXZpbmcgYW4gZW50aXJlbHkgdXNlci1kZWZpbmVkIGNsZWFyIHRleHQNCiB2YWx1ZSBhdCBz
b21lIGNvbnN0YW50IG9mZnNldCBpbiB0aGUgcGFja2V0LCBmb3IgYSB3aWRlbHkgdXNlZCBJbnRl
cm5ldCB0cmFuc3BvcnQgcHJvdG9jb2wsIEkgYW0gcHJldHR5IHN1cmUgc29tZSBpbXBsZW1lbnRl
cnMgd291bGQgbm90IGNhcmUgYWJvdXQgc29tZSBNVVNUcyBpbiBhbiBSRkMgc2F5aW5nIOKAnHBs
ZWFzZSwgcGxlYXNlLCBwbGVhc2Ugc2VsZWN0IGV2ZXJ5IGJpdCBpbiB0aGUgSUQgcmFuZG9tbHni
gJ0uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9yIGRvIEkgbWlz
cyBzb21ldGhpbmcgb2J2aW91cz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLiBUaGUgZmFjdCB0aGF0IHlvdSBj
YW4ndCBrZWVwIHN0dXBpZCBpbXBsZW1lbnRhdGlvbnMgZnJvbSBodXJ0aW5nIHVzZXIgcHJpdmFj
eS4gVGhlIFRDUCBJU04gaXMgdW5zcGVjaWZpZWQsIGFuZCBpdCBjYW4gYWx3YXlzIGJlIHVzZWQg
Zm9yIHBhY2tpbmcgd2hhdGV2ZXIgdXNlci1wcml2YWN5LXJldmVhbGluZyBpbmZvcm1hdGlvbiB5
b3Ugd2FudC4gVGhhdCB3b3VsZCBiZSB2ZXJ5IHZlcnkgZHVtYiwgYnV0DQogaXQncyBub3Qgb3V0
IG9mIHNwZWMgZm9yIFRDUC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSdsbCBhZ3JlZSB0aGF0IHdlIGNhbiBhbmQgc2hvdWxkIGhhdmUgdGV4
dCBpbiB0aGUgc3BlYyB0aGF0IHNheXMgaW1wbGVtZW50YXRpb25zIFNIT1VMRCBub3QgZG8gc3R1
cGlkIHRoaW5ncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+LSBqYW5hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz
LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPiBKYW5hIEl5ZW5nYXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20i
IHRhcmdldD0iX2JsYW5rIj5qcmlAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g
U3VuZGF5LCBNYXkgMjIsIDIwMTYgNToyMCBBTTxicj4NCjxiPlRvOjwvYj4gUnlhbiBIYW1pbHRv
bjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5xdWljQGlldGYub3JnPC9hPjsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1FVSUNdIFFVSUMgcHJpdmFjeSBpbXBhY3Q8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj
ODg4ODg4Ij5NaWNoYWVsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5KdXN0IGNhdWdodCB1cCBvbiB0aGUgU1BV
RCB0aHJlYWQsIGFuZCBJJ2QgbGlrZSB0byBjb3JyZWN0IHNvbWV0aGluZyB5b3Ugc2FpZCB0aGVy
ZSB0aGF0IEknbGwgcXVvdGUgaGVyZSBmb3IgY29udGV4dDombmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPiZxdW90O2lmIHRoZXJlIGlzIG5vdyBh
IG5ldyBjbGVhciB0ZXh0IGlkZW50aWZpZXIgdGhhdCBqdXN0IGhhcHBlbnMgdG8gYmUgdW5pcXVl
IHBlciBzdWJzY3JpYmVyLiBXaGF0IGEgZ3JlYXQgaW1wcm92ZW1lbnQgZm9yIHByaXZhY3kgaW4g
dGhlIEludGVybmV0ISBBbmQgZXZlbiBiZXR0ZXIgdGhhdCBpdCBzZWVtcw0KIGNvbXBhdGlibGUg
d2l0aCBRVUlDLi4uJnF1b3Q7PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UVVJQydzIGNvbm5lY3Rpb24gSUQgaXMgTk9UIHVuaXF1
ZSBwZXIgc3Vic2NyaWJlci4gSXQncyBwZXIgY29ubmVjdGlvbi4gQXMgSSBzYWlkIG9uIHRoZSBv
dGhlciB0aHJlYWQsIGluIHRoZSBzaW5nbGUtcGF0aCBjYXNlLCBpdCByZXZlYWxzIG5vIG1vcmUg
aW5mb3JtdGlvbiB0aGFuIFRDUC4gSW4gdGhlIG11bHRpcGF0aA0KIGNhc2UsIGl0IGVmZmVjdGl2
ZWx5IHJldmVhbHMgbm8gbW9yZSB0aGFuIE1QVENQLCBzaW5jZSB0aGUgSUQgaXMgdXNlZCB0byB0
aWUgdGhlIG11bHRpcGxlLCB1c2luZyBNUFRDUCBwYXJsYW5jZSwmbmJzcDsmcXVvdDtzdWItZmxv
d3MmcXVvdDssIHRvZ2V0aGVyLiBJdCBpcyBwb3NzaWJsZSB0byBjb25zaWRlciBhIGRpZmZlcmVu
dCBkZXNpZ24gdGhhdCB1c2VzIG11bHRpcGxlIGNvbm5lY3Rpb24gSURzIGZvciB0aGUgbXVsdGlw
bGUgc3ViLWZsb3dzLCBidXQgdG8gYmUgY2xlYXIsDQogdGhhdCBtYWtlcyB0aGlzIG5ldyBtdWx0
aXBhdGggc3RyaWN0bHkgYmV0dGVyIHRoYW4gTVBUQ1AmbmJzcDthdCBwcml2YWN5LXByZXNlcnZh
dGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPkF0IGFueSByYXRlLCBJIHdhbnRlZCB0byBtYWtlIHN1cmUgdGhhdCB3ZSdyZSB0YWxr
aW5nIGFib3V0IHRoZSBzYW1lIGlzc3VlLiBJJ2xsIGFsc28gbm90ZSB0aGF0IGl0J3MgcGxhaW4g
d3JvbmcgdG8gdXNlIHRoZSB0ZXJtICZxdW90O2NsZWFyIHRleHQgc3VwZXIgY29va2llJnF1b3Q7
IGluIHJlbGF0aW9uIHRvIHRoZSBRVUlDDQogY29ubmVjdGlvbiBJRCAoc2VlJm5ic3A7PGEgaHJl
Zj0iaHR0cHM6Ly93d3cudGVjaG9wZWRpYS5jb20vZGVmaW5pdGlvbi8yNzMxMC9zdXBlci1jb29r
aWUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy50ZWNob3BlZGlhLmNvbS9kZWZpbml0aW9u
LzI3MzEwL3N1cGVyLWNvb2tpZTwvYT4mbmJzcDtmb3Igd2hhdCBJIHRoaW5rIGEgc3VwZXJjb29r
aWUgaXMuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+LSBqYW5hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTYXQsIE1h
eSAyMSwgMjAxNiBhdCA5OjA0IEFNLCBKYW5hIEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpq
cmlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpyaUBnb29nbGUuY29tPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8cD5UaGF0J3MgYSBkZXNpZ24gZWxlbWVudCB0aGF0IHNob3Vs
ZCBhbmQgd2lsbCBkZWZpbml0ZWx5IGJlIGRpc2N1c3NlZCBpbiB0aGUgV0cuPG86cD48L286cD48
L3A+DQo8cD5TcGVjaWZpY2FsbHkgdGhpcyBhcHBsaWVzIHRvIHVzZSBvZiBjb25uZWN0aW9uIElE
cyBkdXJpbmcgbXVsdGlwYXRoLCBhbmQgSSBleHBlY3QgdGhhdCBjb252ZXJzYXRpb24gdG8gaGFw
cGVuIHdoZW4gd2UgZGlzY3VzcyBtdWx0aXBhdGguPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1heSAyMSwgMjAxNiA2OjU2IEFN
LCAmcXVvdDtSeWFuIEhhbWlsdG9uJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmNoQGdvb2ds
ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5yY2hAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+RGVmaW5pdGVseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIE1heSAyMCwgMjAxNiBhdCAxMToy
NiBQTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1p
Y2hhZWwuc2NoYXJmQG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pY2hhZWwuc2NoYXJmQG5v
a2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+SXMgaXQgcGxhbm5lZCB0byBkaXNjdXNzIHBvdGVudGlhbCBwcml2
YWN5IGltcGxpY2F0aW9ucyBvZiB0aGUg4oCeUVVJQyBjb25uZWN0aW9uIGlkZW50aWZpZXLigJwN
CiAoYWxzbyBuYW1lZCDigJxjbGVhciB0ZXh0IHN1cGVyIGNvb2tpZeKAnSBvbiB0aGUgU1BVRCBs
aXN0KT88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk
aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBRVUlDIFttYWlsdG86
PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1
aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVYVCBUZWQgSGFy
ZGllPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBNYXkgMTQsIDIwMTYgMToyNyBBTTxicj4N
CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5xdWljQGlldGYub3JnPC9hPjsgSmFuYSBJeWVuZ2FyOyBDaHJpc3RpYW4gSHVpdGVtYTxicj4N
CjxiPlN1YmplY3Q6PC9iPiBbUVVJQ10gRHJhZnQgY2hhcnRlcjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w
cHQiPkhvd2R5LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkFzIHBh
cnQgb2YgdGhlIEJvRiBwcmVwYXJhdGlvbiwgd2UgcHV0IHRvZ2V0aGVyIGEgc3RhYiBhdCBhIGRy
YWZ0IGNoYXJ0ZXIuJm5ic3A7IEl0J3MgYXZhaWxhYmxlIGFzIGh0bWwgYW5kIG1hcmtkb3duIG9u
IGdpdGh1YiBhdDo8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vSUVURi1R
VUlDL0NoYXJ0ZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vSUVURi1RVUlD
L0NoYXJ0ZXI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SSd2
ZSBhdHRhY2hlZCB0aGUgSFRNTCB2ZXJzaW9uIGFzIHdlbGwuJm5ic3A7DQo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgd291bGQgYmUgZ3Jl
YXQgdG8gaGF2ZSBzb21lIG9mIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGJlZm9yZSB0aGUg
Qm9GLiZuYnNwOyBDb21tZW50cyB0byB0aGUgbGlzdCBvciBpc3N1ZXMvcHVsbCByZXF1ZXN0cyBh
dCB0aGUgZ2l0aHViIHJlcG8gYXJlIHdlbGNvbWUuJm5ic3A7IFdlIHdpbGwgcGVyaW9kaWNhbGx5
DQogcmVmbGVjdCBhbnkgaXNzdWVzIG9yIHN1Z2dlc3Rpb24gZnJvbSB0aGUgUmVwbyBiYWNrIHRv
IHRoZSBsaXN0LCBidXQgdGhpcyB3aWxsIGJlIG1hbnVhbCwgc28gZXhwZWN0IHNvbWUgbGFnLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5yZWdhcmRzLDxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRlZDxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi
cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
UVVJQyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86UVVJQ0BpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPlFVSUNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9xdWljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9xdWljPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KUVVJQyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls
dG86UVVJQ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlFVSUNAaWV0Zi5vcmc8L2E+PGJyPg0K
PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9xdWljIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9xdWljPC9h
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_655C07320163294895BBADA28372AF5D48863C11FR712WXCHMBA15z_--


From nobody Mon May 23 12:50:03 2016
Return-Path: 
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 A5B3A12DB05 for ; Mon, 23 May 2016 12:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 roJFjj19UzA0 for ; Mon, 23 May 2016 12:49:58 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209A112DAE3 for ; Mon, 23 May 2016 12:49:36 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 3E6722610950C; Mon, 23 May 2016 19:49:30 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NJnDJi015132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 19:49:13 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NJnBGi008361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 21:49:12 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 23 May 2016 21:49:11 +0200
From: "Scharf, Michael (Nokia - DE)" 
To: Jana Iyengar , Olivier Bonaventure 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynFCnTysxHU/0GFj3E4WoIavJ/DSSMAgAAj/ACAAcge0IAAJ6KAgAAp5oCAAEbugIAAM9KAgAC6vACAAC0kAA==
Date: Mon, 23 May 2016 19:49:10 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48863C89@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>  
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48863C89FR712WXCHMBA15z_"
MIME-Version: 1.0
Archived-At: 
Cc: Brian Trammell , Mark Nottingham , Kyle Rose , "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 19:50:00 -0000

--_000_655C07320163294895BBADA28372AF5D48863C89FR712WXCHMBA15z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2hhdCBpcyBhY2NlcHRhYmxlIHRvIG1lIGlzIOKAnm5vdCB3b3JzZSB0aGFuIFRDUCBhbmQgVExT
IDEuMyBieSBkZWZhdWx04oCdLiBJIGZhaWwgdG8gdW5kZXJzdGFuZCB3aHkgdGhlIElFVEYgc2hv
dWxkIGxvd2VyIHRoZSBzdGFuZGFyZHMgZm9yIHNlY3VyaXR5IGFuZCBwcml2YWN5IGtub3duIGZy
b20gVENQIGZvciBhbnkgZGF0YSB0cmFuc3BvcnQgaW4gdGhlIGZpeGVkIEludGVybmV0Lg0KDQpJ
dCBtYXkgbWFrZSBzZW5zZSBpZiB1c2VycyBjYW4gb3B0IGluIGZvciBhZGRpdGlvbmFsIHByb3Rv
Y29sICBmZWF0dXJlcywgZS5nLiwgc2ltaWxhciB0byBNUFRDUCBhbmQgU0NUUCwgZS5nLiBvbiBt
b2JpbGUgZGV2aWNlcy4gSW4gdGhhdCBjYXNlLCDigJxhZnRlciBleHBsaWNpdCBvcHQtaW4gbm90
IHdvcnNlIHRoYW4gVExTMS4zIG92ZXIgb25lIG9mIHtUQ1AsIE1QVENQLCBTQ1RQfeKAnSBzZWVt
cyByZWFzb25hYmxlLCBwcm92aWRlZCBpdCBpcyBvcHQtaW4uDQoNCk1pY2hhZWwNCg0KDQpGcm9t
OiBKYW5hIEl5ZW5nYXIgW21haWx0bzpqcmlAZ29vZ2xlLmNvbV0NClNlbnQ6IE1vbmRheSwgTWF5
IDIzLCAyMDE2IDg6MzcgUE0NClRvOiBPbGl2aWVyIEJvbmF2ZW50dXJlDQpDYzogTWFyayBOb3R0
aW5naGFtOyBLeWxlIFJvc2U7IFJ5YW4gSGFtaWx0b247IEJyaWFuIFRyYW1tZWxsOyBTY2hhcmYs
IE1pY2hhZWwgKE5va2lhIC0gREUpOyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1FVSUNd
IFFVSUMgcHJpdmFjeSBpbXBhY3QNCg0KSSBhZ3JlZSB3aXRoIHRoZSBzcGlyaXQgb2YgTWFyaydz
IGFuZCBPbGl2aWVyJ3MgYXNzZXNzbWVudHMuIEknbSBoYXBweSB0byBhZGQgd29yZGluZyB0byB0
aGUgY2hhcnRlciBidXQgd2UnZCBoYXZlIHRvIGJlIGNhcmVmdWwuIFFVSUMncyBjb21wYXJpc29u
cyBhcmUgbm90IHRvIFRDUCwgTVBUQ1AsIFNDVFAsIG9yIFRMUzEuMyBpbmRpdmlkdWFsbHksIHNp
bmNlIHRoZXkgYWxsIGltcGxlbWVudCBkaWZmZXJlbnQgZnVuY3Rpb25zIHRoYXQgYXJlIGFsbCBj
b21iaW5lZCBpbiBRVUlDLiBJJ20gaGFwcHkgdG8gc3RhdGUgc29tZXRoaW5nIGFsb25nIHRoZSBs
aW5lcyBvZiBRVUlDIHVzaW5nIFRMUzEuMyBzaG91bGQgaGF2ZSBwcml2YWN5IGFuZCBzZWN1cml0
eSBwcm9wZXJ0aWVzIHRoYXQgYXJlIG5vIHdvcnNlIHRoYW4gYSBzdGFjayBjb21wcmlzZWQgb2Yg
VExTMS4zIG92ZXIgb25lIG9mIHtUQ1AsIE1QVENQLCBvciBTQ1RQfS4NCg0KRG9lcyB0aGF0IHNv
dW5kIHJlYXNvbmFibGU/DQoNCkknbGwgcG9pbnQgb3V0IHRoYXQgdGhlcmUncyBub3RoaW5nIGlu
IHRoZSBjdXJyZW50IGRlc2lnbiBvZiBRVUlDIHRoYXQgcnVucyBhZm91bCBvZiB0aGlzIHN0YXRl
bWVudCAoaW5jbHVkaW5nIHVzZSBvZiB0aGUgc2FtZSBjb25uZWN0aW9uIElEIGZvciBtdWx0aXBh
dGgpLiBPZiBjb3Vyc2UsIHdlIGNhbiBtYWtlIGl0IGJldHRlciwgc28gbGV0J3MgaGF2ZSB0aGF0
IGNvbnZlcnNhdGlvbiB3aGVuIHNwZWNpZmljIGRlc2lnbiBxdWVzdGlvbnMgYXJlIGJlaW5nIGNv
bnNpZGVyZWQuDQoNCi0gamFuYQ0KDQpPbiBNb24sIE1heSAyMywgMjAxNiBhdCAxMjoyOCBBTSwg
T2xpdmllciBCb25hdmVudHVyZSA8b2xpdmllci5ib25hdmVudHVyZUB0ZXNzYXJlcy5uZXQ8bWFp
bHRvOm9saXZpZXIuYm9uYXZlbnR1cmVAdGVzc2FyZXMubmV0Pj4gd3JvdGU6DQpNYXJrLA0KU2hv
b3RpbmcgZm9yIHBlcmZlY3QgcHJpdmFjeSBpcyBhbHdheXMgZ29pbmcgdG8gZmFpbC4NCg0KSSB0
b3RhbGx5IGFncmVlDQpXaGF0IHdlIHNob3VsZCBiZSBhaW1pbmcgZm9yIGlzIG5vIHdvcnNlIHRo
YW4gVENQIC0tIGhhdmluZyBzdGFibGUsIHdlbGwtdW5kZXJzdG9vZCBiZWhhdmlvdXIgaXMgdGhl
IGltcG9ydGFudCB0aGluZyBoZXJlLiBUaGUgSW50ZXJuZXQgKGFuZCB0aGUgV2ViKSBpcyBhIHBs
YXRmb3JtIHRoYXQgcGVvcGxlIGJvdGggZGVzaWduIGZvciBhbmQgdXNlIHdpdGggY2VydGFpbiBh
c3N1bXB0aW9ucyBpbiBtaW5kOyB3ZSBzaG91bGRuJ3QgdmlvbGF0ZSB0aGVtIHdpdGhvdXQgdmVy
eSBjYXJlZnVsbHkgd2VpZ2hpbmcgdGhlIGltcGFjdC4NCg0KTWFraW5nIGl0IGJldHRlciB0aGFu
IFRDUCB3b3VsZCBiZSBhIGdvb2Qgb3V0Y29tZSB0b28sIG9mIGNvdXJzZS4NCg0KSXQgd291bGQg
YmUgbmljZSB0byBoYXZlIHNvbWV0aGluZyBpbiB0aGUgY2hhcnRlciBzdGF0aW5nICJubyB3b3Jz
ZSB0aGFuIFRDUCIgZm9yIHByaXZhY3kgYW5kIHBvc3NpYmx5IG90aGVyIHByb3BlcnRpZXMgYXMg
d2VsbC4NCg0KVGhpcyBpcyBleGFjdGx5IHRoZSB0eXBlIG9mIHdvcmRpbmcgdGhhdCB3ZSBzaG91
bGQgaGF2ZSBpbiB0aGUgY2hhcnRlciBmb3IgdmFyaW91cyBtZWNoYW5pc21zIHRoYXQgYWxyZWFk
eSBleGlzdCBhbmQgYXJlL3dpbGwgYmUgaW5jbHVkZWQgaW4gUVVJQy4NCg0KRm9yIGNvbmdlc3Rp
b24gY29udHJvbCwgUVVJQyBzaG91bGQgcmV1c2UgdGhlIGV4aXN0aW5nIChzaW5nbGUtcGF0aCBh
bmQgbXVsdGlwYXRoKSBUQ1AgY29uZ2VzdGlvbiBjb250cm9sIHNjaGVtZXMuDQoNCkZvciBwcml2
YWN5LCBRVUlDIHNob3VsZCBub3QgYmUgd29yc2UgdGhhbiBleGlzdGluZyB0cmFuc3BvcnQgcHJv
dG9jb2xzIChUQ1AsIE11bHRpcGF0aCBUQ1AsIFNDVFApLiBGb3IgTXVsdGlwYXRoIFRDUCwgd2Ug
dG9vayB0aGlzIGFwcHJvYWNoIGZvciBzZWN1cml0eSBhbmQgaXQgdHVybmVkIG91dCB0byBiZSBn
b29kLg0KDQpTYW1lIGFwcGxpZXMgcHJvYmFibHkgZm9yIHRoZSBzZWN1cml0eSBmZWF0dXJlcyBp
biByZWxhdGlvbiB3aXRoIFRMUyAxLjMgYW5kIHBlcmhhcHMgSFRUUC8yIGZvciB0aGUgQVBJIGRp
c2N1c3Npb24uDQoNCk9saXZpZXINCg0KLS0NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQpESVNDTEFJTUVSLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdp
dGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m
IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYg
eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBz
eXN0ZW0gbWFuYWdlci4gVGhpcyBtZXNzYWdlIGNvbnRhaW5zIGNvbmZpZGVudGlhbCBpbmZvcm1h
dGlvbiBhbmQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIGluZGl2aWR1YWwgbmFtZWQuIElmIHlv
dSBhcmUgbm90IHRoZSBuYW1lZCBhZGRyZXNzZWUgeW91IHNob3VsZCBub3QgZGlzc2VtaW5hdGUs
IGRpc3RyaWJ1dGUgb3IgY29weSB0aGlzIGUtbWFpbC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy
IGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBpZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBi
eSBtaXN0YWtlIGFuZCBkZWxldGUgdGhpcyBlLW1haWwgZnJvbSB5b3VyIHN5c3RlbS4gSWYgeW91
IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgZGlz
Y2xvc2luZywgY29weWluZywgZGlzdHJpYnV0aW5nIG9yIHRha2luZyBhbnkgYWN0aW9uIGluIHJl
bGlhbmNlIG9uIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHN0cmljdGx5IHBy
b2hpYml0ZWQuDQoNCg==

--_000_655C07320163294895BBADA28372AF5D48863C89FR712WXCHMBA15z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u
aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxh
Z2UxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk
U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IGlzIGFjY2VwdGFibGUgdG8gbWUg
aXMg4oCebm90IHdvcnNlIHRoYW4gVENQIGFuZCBUTFMgMS4zIGJ5IGRlZmF1bHTigJ0uIEkgZmFp
bCB0byB1bmRlcnN0YW5kIHdoeSB0aGUgSUVURiBzaG91bGQgbG93ZXIgdGhlIHN0YW5kYXJkcyBm
b3Igc2VjdXJpdHkNCiBhbmQgcHJpdmFjeSBrbm93biBmcm9tIFRDUCBmb3IgYW55IGRhdGEgdHJh
bnNwb3J0IGluIHRoZSBmaXhlZCBJbnRlcm5ldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SXQgbWF5IG1ha2Ugc2Vuc2UgaWYgdXNlcnMgY2FuIG9wdCBpbiBmb3IgYWRkaXRp
b25hbCBwcm90b2NvbCAmbmJzcDtmZWF0dXJlcywgZS5nLiwgc2ltaWxhciB0byBNUFRDUCBhbmQg
U0NUUCwgZS5nLiBvbiBtb2JpbGUgZGV2aWNlcy4gSW4gdGhhdCBjYXNlLA0KIOKAnGFmdGVyIGV4
cGxpY2l0IG9wdC1pbiBub3Qgd29yc2UgdGhhbiBUTFMxLjMgb3ZlciBvbmUgb2Yge1RDUCwgTVBU
Q1AsIFNDVFB94oCdIHNlZW1zIHJlYXNvbmFibGUsIHByb3ZpZGVkIGl0IGlzIG9wdC1pbi4NCjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NaWNoYWVsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow
Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEphbmEgSXllbmdhciBbbWFpbHRv
OmpyaUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDIzLCAyMDE2
IDg6MzcgUE08YnI+DQo8Yj5Ubzo8L2I+IE9saXZpZXIgQm9uYXZlbnR1cmU8YnI+DQo8Yj5DYzo8
L2I+IE1hcmsgTm90dGluZ2hhbTsgS3lsZSBSb3NlOyBSeWFuIEhhbWlsdG9uOyBCcmlhbiBUcmFt
bWVsbDsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTsgcXVpY0BpZXRmLm9yZzxicj4NCjxi
PlN1YmplY3Q6PC9iPiBSZTogW1FVSUNdIFFVSUMgcHJpdmFjeSBpbXBhY3Q8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIHRo
ZSBzcGlyaXQgb2YgTWFyaydzIGFuZCBPbGl2aWVyJ3MgYXNzZXNzbWVudHMuIEknbSBoYXBweSB0
byBhZGQgd29yZGluZyB0byB0aGUgY2hhcnRlciBidXQgd2UnZCBoYXZlIHRvIGJlIGNhcmVmdWwu
IFFVSUMncyBjb21wYXJpc29ucyBhcmUgbm90IHRvIFRDUCwgTVBUQ1AsIFNDVFAsIG9yIFRMUzEu
MyBpbmRpdmlkdWFsbHksIHNpbmNlIHRoZXkgYWxsIGltcGxlbWVudCBkaWZmZXJlbnQNCiBmdW5j
dGlvbnMgdGhhdCBhcmUgYWxsIGNvbWJpbmVkIGluIFFVSUMuIEknbSBoYXBweSB0byBzdGF0ZSBz
b21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mIFFVSUMgdXNpbmcgVExTMS4zIHNob3VsZCBoYXZl
IHByaXZhY3kgYW5kIHNlY3VyaXR5IHByb3BlcnRpZXMgdGhhdCBhcmUgbm8gd29yc2UgdGhhbiBh
IHN0YWNrIGNvbXByaXNlZCBvZiBUTFMxLjMgb3ZlciBvbmUgb2YmbmJzcDt7VENQLCBNUFRDUCwg
b3IgU0NUUH0uJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5Eb2VzIHRoYXQgc291bmQgcmVhc29uYWJsZT88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdsbCBwb2ludCBvdXQgdGhhdCB0
aGVyZSdzIG5vdGhpbmcgaW4gdGhlIGN1cnJlbnQgZGVzaWduIG9mIFFVSUMgdGhhdCBydW5zIGFm
b3VsIG9mIHRoaXMgc3RhdGVtZW50IChpbmNsdWRpbmcgdXNlIG9mIHRoZSBzYW1lIGNvbm5lY3Rp
b24gSUQgZm9yIG11bHRpcGF0aCkuIE9mIGNvdXJzZSwgd2UgY2FuIG1ha2UgaXQgYmV0dGVyLCBz
byBsZXQncyBoYXZlIHRoYXQgY29udmVyc2F0aW9uIHdoZW4gc3BlY2lmaWMNCiBkZXNpZ24gcXVl
c3Rpb25zIGFyZSBiZWluZyBjb25zaWRlcmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIGphbmE8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
TW9uLCBNYXkgMjMsIDIwMTYgYXQgMTI6MjggQU0sIE9saXZpZXIgQm9uYXZlbnR1cmUgJmx0Ozxh
IGhyZWY9Im1haWx0bzpvbGl2aWVyLmJvbmF2ZW50dXJlQHRlc3NhcmVzLm5ldCIgdGFyZ2V0PSJf
YmxhbmsiPm9saXZpZXIuYm9uYXZlbnR1cmVAdGVzc2FyZXMubmV0PC9hPiZndDsgd3JvdGU6PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox
Mi4wcHQiPk1hcmssPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG9vdGlu
ZyBmb3IgcGVyZmVjdCBwcml2YWN5IGlzIGFsd2F5cyBnb2luZyB0byBmYWlsLjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48
YnI+DQpJIHRvdGFsbHkgYWdyZWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PldoYXQgd2Ugc2hvdWxkIGJlIGFpbWluZyBmb3IgaXMgbm8gd29yc2UgdGhhbiBUQ1AgLS0gaGF2
aW5nIHN0YWJsZSwgd2VsbC11bmRlcnN0b29kIGJlaGF2aW91ciBpcyB0aGUgaW1wb3J0YW50IHRo
aW5nIGhlcmUuIFRoZSBJbnRlcm5ldCAoYW5kIHRoZSBXZWIpIGlzIGEgcGxhdGZvcm0gdGhhdCBw
ZW9wbGUgYm90aCBkZXNpZ24gZm9yIGFuZCB1c2Ugd2l0aCBjZXJ0YWluIGFzc3VtcHRpb25zIGlu
IG1pbmQ7IHdlDQogc2hvdWxkbid0IHZpb2xhdGUgdGhlbSB3aXRob3V0IHZlcnkgY2FyZWZ1bGx5
IHdlaWdoaW5nIHRoZSBpbXBhY3QuPGJyPg0KPGJyPg0KTWFraW5nIGl0IGJldHRlciB0aGFuIFRD
UCB3b3VsZCBiZSBhIGdvb2Qgb3V0Y29tZSB0b28sIG9mIGNvdXJzZS48YnI+DQo8YnI+DQpJdCB3
b3VsZCBiZSBuaWNlIHRvIGhhdmUgc29tZXRoaW5nIGluIHRoZSBjaGFydGVyIHN0YXRpbmcgJnF1
b3Q7bm8gd29yc2UgdGhhbiBUQ1AmcXVvdDsgZm9yIHByaXZhY3kgYW5kIHBvc3NpYmx5IG90aGVy
IHByb3BlcnRpZXMgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pjxicj4NClRoaXMgaXMgZXhhY3RseSB0aGUgdHlwZSBvZiB3b3JkaW5nIHRoYXQgd2Ugc2hvdWxk
IGhhdmUgaW4gdGhlIGNoYXJ0ZXIgZm9yIHZhcmlvdXMgbWVjaGFuaXNtcyB0aGF0IGFscmVhZHkg
ZXhpc3QgYW5kIGFyZS93aWxsIGJlIGluY2x1ZGVkIGluIFFVSUMuPGJyPg0KPGJyPg0KRm9yIGNv
bmdlc3Rpb24gY29udHJvbCwgUVVJQyBzaG91bGQgcmV1c2UgdGhlIGV4aXN0aW5nIChzaW5nbGUt
cGF0aCBhbmQgbXVsdGlwYXRoKSBUQ1AgY29uZ2VzdGlvbiBjb250cm9sIHNjaGVtZXMuPGJyPg0K
PGJyPg0KRm9yIHByaXZhY3ksIFFVSUMgc2hvdWxkIG5vdCBiZSB3b3JzZSB0aGFuIGV4aXN0aW5n
IHRyYW5zcG9ydCBwcm90b2NvbHMgKFRDUCwgTXVsdGlwYXRoIFRDUCwgU0NUUCkuIEZvciBNdWx0
aXBhdGggVENQLCB3ZSB0b29rIHRoaXMgYXBwcm9hY2ggZm9yIHNlY3VyaXR5IGFuZCBpdCB0dXJu
ZWQgb3V0IHRvIGJlIGdvb2QuPGJyPg0KPGJyPg0KU2FtZSBhcHBsaWVzIHByb2JhYmx5IGZvciB0
aGUgc2VjdXJpdHkgZmVhdHVyZXMgaW4gcmVsYXRpb24gd2l0aCBUTFMgMS4zIGFuZCBwZXJoYXBz
IEhUVFAvMiBmb3IgdGhlIEFQSSBkaXNjdXNzaW9uLjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4
Ij48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5PbGl2aWVyPC9zcGFuPjxicj4NCjxi
cj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi0tIDwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBjbGFz
cz0iaG9lbnpiIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJyPg0KPHNw
YW4gY2xhc3M9ImhvZW56YiI+RElTQ0xBSU1FUi48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Imhv
ZW56YiI+VGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNv
bmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk
dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVj
ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBzeXN0ZW0gbWFuYWdl
ci4gVGhpcyBtZXNzYWdlDQogY29udGFpbnMgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBp
cyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgaW5kaXZpZHVhbCBuYW1lZC4gSWYgeW91IGFyZSBub3Qg
dGhlIG5hbWVkIGFkZHJlc3NlZSB5b3Ugc2hvdWxkIG5vdCBkaXNzZW1pbmF0ZSwgZGlzdHJpYnV0
ZSBvciBjb3B5IHRoaXMgZS1tYWlsLiBQbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl
bHkgYnkgZS1tYWlsIGlmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZS1tYWlsDQogYnkgbWlzdGFr
ZSBhbmQgZGVsZXRlIHRoaXMgZS1tYWlsIGZyb20geW91ciBzeXN0ZW0uIElmIHlvdSBhcmUgbm90
IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgeW91IGFyZSBub3RpZmllZCB0aGF0IGRpc2Nsb3Npbmcs
IGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvciB0YWtpbmcgYW55IGFjdGlvbiBpbiByZWxpYW5jZSBv
biB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVk
Ljwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_655C07320163294895BBADA28372AF5D48863C89FR712WXCHMBA15z_--


From nobody Mon May 23 12:55:54 2016
Return-Path: 
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 A54CA12D1B6 for ; Mon, 23 May 2016 12:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 leIzKce4FPIx for ; Mon, 23 May 2016 12:55:51 -0700 (PDT)
Received: from uk-www1.yaanatech.uk (uk-www1.yaanatech.uk [46.20.116.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30A712D526 for ; Mon, 23 May 2016 12:55:50 -0700 (PDT)
Received: from [192.168.1.51] (pool-173-67-205-17.clppva.fios.verizon.net [173.67.205.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by uk-www1.yaanatech.uk (Postfix) with ESMTPSA id 15C8F5400F2; Mon, 23 May 2016 20:55:47 +0100 (BST)
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D48863C11@FR712WXCHMBA15.zeu.alcatel-lucent.com>
To: "Scharf, Michael (Nokia - DE)" , Jana Iyengar 
From: Tony Rutkowski 
Organization: Yaana Ltd
Message-ID: 
Date: Mon, 23 May 2016 15:55:47 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <655C07320163294895BBADA28372AF5D48863C11@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="------------CF1A70ADB6CAFD5F2EBC4C8D"
Archived-At: 
Cc: "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: tony@yaanatech.co.uk
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 19:55:53 -0000

This is a multi-part message in MIME format.
--------------CF1A70ADB6CAFD5F2EBC4C8D
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Michael,

So like...could the identifier be used by a provider
to lessen culpability their culpability in implementing
the Digital Millennium Copyright Act?  The recent
$25 million fine against one provider provides a
major motivation toward mitigating unlawful used
of encrypted streams of their customers.

--tony

On 2016-05-23 3:16 PM, Scharf, Michael (Nokia - DE) wrote:
>
> I am certainly not concerned about stupid implementations. I am 
> concerned about implementations that understand how to intelligently 
> leverage this identifier and this is the type of analysis I expect in 
> a comprehensive security consideration section. Some of the malicious 
> use if this ID may perhaps be classified by as an active attack on 
> user privacy but still the attack vector seems to me quite different 
> to what an attacker can do with similar means with TCP.
>


--------------CF1A70ADB6CAFD5F2EBC4C8D
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Michael,

    

    So like...could the identifier be used by a provider

    to lessen culpability their culpability in implementing

    the Digital Millennium Copyright Act? The recent

    $25 million fine against one provider provides a

    major motivation toward mitigating unlawful used

    of encrypted streams of their customers.

    

    --tony

    

    
On 2016-05-23 3:16 PM, Scharf, Michael
      (Nokia - DE) wrote:

    

    

      
I am certainly not concerned about stupid
          implementations. I am concerned about implementations that
          understand how to intelligently leverage this identifier and
          this is the type of analysis I expect in a comprehensive
          security consideration section. Some of the malicious use if
          this ID may perhaps be classified by as an active attack on
          user privacy but still the attack vector seems to me quite
          different to what an attacker can do with similar means with
          TCP. 

      

    

    

  


--------------CF1A70ADB6CAFD5F2EBC4C8D--


From nobody Mon May 23 13:03:27 2016
Return-Path: 
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 DDF4D12DB27 for ; Mon, 23 May 2016 13:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 vTP8O6_1doAY for ; Mon, 23 May 2016 13:03:23 -0700 (PDT)
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 D453512DAEC for ; Mon, 23 May 2016 13:03:21 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id h19so28726612ywc.0 for ; Mon, 23 May 2016 13:03:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hPxBLSYU6LY+zL97Jg3jmJr+wIda3v7eC25tWAES16I=; b=fNh9nNHFhh1D5C1kK39tP73Bmkik12hNL02NhFX2sLUUp8KA9ewvKXxqPpUKD+Zv2G R96Yb+J054KdEYSxRqX38F7AQwRxetj6fTQqamA27f/wU8ZnrD7XG0YD/TvbMR/ACKt2 tjC7kOE8JhgLIDAyXtbquLa4VfoxAU/Q1HArO2bxErSMdPo+DorA8octGffU3DkO20Nn KXfuNeJYqrAqxFZHmDljsOe1oRVdoao50QtPbxrHMKvV3awLN23aLNqug7iMgCRIxyE7 fNrmdKIzNoNq7xHUyRvsB2QYzO5740MwtZtAWAdL7hO07VG/BEZ9dqxu82g+jll80J+L IqWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hPxBLSYU6LY+zL97Jg3jmJr+wIda3v7eC25tWAES16I=; b=Yd46mRaiXWg7g40lKr6PyBK6rTJXnsGouRoljqmZ7jJAW+HzeXs2NA1kmYW8aGN8XU 7lUcHpGhNebZ/PrEDXLKQ1SUxMcyfnqhpuXTjjOi3xg4o4dDo/qIldKjxa59TK1YT3/W F1iF4ttKg9OVKVUDEhDwSToQhs6qsjcdSw3AaB/RKYicdmw7Y/+xum5EuNUKUmaWsjkD eGeTM785/jgFq0d2SasIT5laVyx1q2KYY6vezr7Hxd6OLkqbI3HGyz0TJ9SjHT29K9F+ mze0P74VEO5/OxtsktWC4eZ3dn22p7naOT4uTVh/tGwpmFk6pFkW92tNlfWIsO67d/0k qqqQ==
X-Gm-Message-State: ALyK8tI9MMHNmxDxOonw8c8FtPiTbgDyqj88+uqxNCx9oO7Ta6DuIGQ8BX/PXUIdJlVg7cIyCeWjVFXl27bY3z10
X-Received: by 10.37.49.193 with SMTP id x184mr383148ybx.57.1464033800882; Mon, 23 May 2016 13:03:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 13:03:20 -0700 (PDT)
In-Reply-To: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>      
From: Jana Iyengar 
Date: Mon, 23 May 2016 13:03:20 -0700
Message-ID: 
To: Ian Swett 
Content-Type: multipart/alternative; boundary=001a1148af18a498c7053387eeec
Archived-At: 
Cc: Ted Hardie , Julian Reschke , Cory Benfield , Mark Nottingham , Christian Huitema , quic@ietf.org, Martin Thomson 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 20:03:25 -0000

--001a1148af18a498c7053387eeec
Content-Type: text/plain; charset=UTF-8

The intent was definitely to use alt-svc with "h2q", and not define a new
HTTP/3.

In general as a transport, lack of HoL blocking in QUIC (or equivalently,
the availability of HoL blocking in TCP) is a key difference when
considering HTTP/2 mechanisms or extensions. Having QUIC as an alternative
transport for HTTP/2 makes it important that any new HTTP/2 extension
explicitly consider and state its HoL blocking assumptions.

HTTP/2 was clearly defined to run on top of TLS or TCP... RFC 7540
 clearly states: "An HTTP/2
connection is an application-layer protocol running on top of a TCP
connection". This is exactly why "h2q" needs a mapping document, which maps
the semantics of HTTP/2 on top of a different wire-format. By extension,
HTTP/2 extensions will by default extend h2 and not h2q, and may rely on
TCP underneath. As a rule, I think we have to assume that they'll need to
explicitly map to QUIC.

We've done something similar in the past in TSVAREA that may be helpful --
when a modification to a congestion control or a loss recovery mechanism is
made, it can be made for both TCP and SCTP in the same doc (see RFC 5827
, for instance.) To be clear, this is
not required for draft authors at the moment, and it is a model to consider
for future HTTP/2 extensions -- an extension could have a "TCP" and a
"QUIC" section.


On Mon, May 23, 2016 at 10:32 AM, Ian Swett  wrote:

> Agreed, the ability of QUIC to fix head of line blocking creates a variety
> of challenges for specifications which relied on head of line
> blocking(including, but not limited to headers).
>
> The simple fix is to put all H2 frames requiring HoL blocking onto the
> headers stream.  I 'think' that's sufficient as a viable approach, and in
> some cases we may be able to do better.
>
> On Mon, May 23, 2016 at 1:28 PM, Martin Thomson 
> wrote:
>
>> On 23 May 2016 at 13:22, Ian Swett  wrote:
>> > Can you describe the particular QUIC specific challenge with the
>> http2-certs
>> > draft?  I'm familiar with the draft, and no issues come to mind.
>>
>> The draft requires exchanges on the affected stream and stream 0.  I'm
>> concerned that the change to move header fields to stream 3 will
>> negatively affect the sequencing of things.  I haven't thought it
>> through completely, maybe it's even an improvement.
>>
>> Even if this is OK, I'm concerned that changes like the placement of
>> header blocks will have an impact on h2 extensions generally.
>>
>
>

--001a1148af18a498c7053387eeec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The intent was definitely to use alt-svc with "h2q&qu=
ot;, and not define a new HTTP/3.

In general as a transp=
ort, lack of HoL blocking in QUIC (or equivalently, the availability of HoL=
 blocking in TCP) is a key difference when considering HTTP/2 mechanisms or=
 extensions. Having QUIC as an alternative transport for HTTP/2 makes it im=
portant that any new HTTP/2 extension explicitly consider and state its HoL=
 blocking assumptions.=C2=A0

HTTP/2 was clearly de=
fined to run on top of TLS or TCP...=C2=A0RFC 7540=C2=A0clearly states: "An HTTP/2 connectio=
n is an application-layer protocol running on top of a TCP connection"=
. This=C2=A0is exactly why "h2q" needs a mapping document, which =
maps the semantics of HTTP/2 on top of a different wire-format. By extensio=
n, HTTP/2 extensions will by default extend h2 and not h2q, and may rely on=
 TCP underneath. As a rule, I think we have to assume that they'll need=
 to explicitly map to QUIC.

We've done somethi=
ng similar in the past in TSVAREA that may be helpful -- when a modificatio=
n to a congestion control or a loss recovery mechanism is made, it can be m=
ade for both TCP and SCTP in the same doc (see RFC 5827, for instance.) To be clear, this is not r=
equired for draft authors at the moment, and it is a model to consider for =
future HTTP/2 extensions -- an extension could have a "TCP" and a=
 "QUIC" section.


On Mon, May 23, 2016 at 10:32 AM, Ian S=
wett <ianswett@google.com> wrote:
Agreed, the ability of QUIC to fix head of line =
blocking creates a variety of challenges for specifications which relied on=
 head of line blocking(including, but not limited to headers).

The simple fix is to put all H2 frames requiring HoL blocking onto t=
he headers stream.=C2=A0 I 'think' that's sufficient as a viabl=
e approach, and in some cases we may be able to do better.

On Mon, May 23, 2016 at 1:28 PM, Martin Thomson <=
martin.thomson@gmail.com> wrote:
On 23 May 2016 at 13:22, Ian Swett <ianswett@google.com> wrote:

> Can you describe the particular QUIC specific challenge with the http2=
-certs

> draft?=C2=A0 I'm familiar with the draft, and no issues come to mi=
nd.



The draft requires exchanges on the affected stream and stream 0.=C2=
=A0 I'm

concerned that the change to move header fields to stream 3 will

negatively affect the sequencing of things.=C2=A0 I haven't thought it<=
br>
through completely, maybe it's even an improvement.



Even if this is OK, I'm concerned that changes like the placement of
header blocks will have an impact on h2 extensions generally.








--001a1148af18a498c7053387eeec--


From nobody Mon May 23 13:04:24 2016
Return-Path: 
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 4F69D12DB2D for ; Mon, 23 May 2016 13:04:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 Wrb6vLs6AkcU for ; Mon, 23 May 2016 13:04:18 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A89512DB27 for ; Mon, 23 May 2016 13:04:18 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id F04F05FE2CA58; Mon, 23 May 2016 20:04:12 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NK4Gvd024873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 20:04:16 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NK2wbS024788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 22:04:15 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 23 May 2016 22:03:58 +0200
From: "Scharf, Michael (Nokia - DE)" 
To: "tony@yaanatech.co.uk" , Jana Iyengar 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynFCnTysxHU/0GFj3E4WoIavJ/DSSMAgAAj/ACAALzBAIABBqOQgAGB/gCAACh9YP//91mAgAAiAIA=
Date: Mon, 23 May 2016 20:03:57 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48863D26@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D48863C11@FR712WXCHMBA15.zeu.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48863D26FR712WXCHMBA15z_"
MIME-Version: 1.0
Archived-At: 
Cc: "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 20:04:22 -0000

--_000_655C07320163294895BBADA28372AF5D48863D26FR712WXCHMBA15z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am not neither a QUIC nor a security expert. I just deal with the entirel=
y ossified Internet running over legacy TCP ;-)

But, to me, this sort of question is valid and has to be answered in a secu=
rity considerations section.

Michael


From: Tony Rutkowski [mailto:tony@yaanatech.co.uk]
Sent: Monday, May 23, 2016 9:56 PM
To: Scharf, Michael (Nokia - DE); Jana Iyengar
Cc: quic@ietf.org; Ryan Hamilton
Subject: Re: [QUIC] QUIC privacy impact

Hi Michael,

So like...could the identifier be used by a provider
to lessen culpability their culpability in implementing
the Digital Millennium Copyright Act?  The recent
$25 million fine against one provider provides a
major motivation toward mitigating unlawful used
of encrypted streams of their customers.

--tony
On 2016-05-23 3:16 PM, Scharf, Michael (Nokia - DE) wrote:
I am certainly not concerned about "stupid" implementations. I am concerned=
 about implementations that understand how to "intelligently" leverage this=
 identifier and this is the type of analysis I expect in a comprehensive se=
curity consideration section. Some of the malicious use if this ID may perh=
aps be classified by as an active attack on user privacy but still the atta=
ck vector seems to me quite different to what an attacker can do with simil=
ar means with TCP.


--_000_655C07320163294895BBADA28372AF5D48863D26FR712WXCHMBA15z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I am not n=
either a QUIC nor a security expert. I just deal with the entirely ossified=
 Internet running over legacy TCP ;-)


 =
;


But, to me=
, this sort of question is valid and has to be answered in a security consi=
derations section.


 =
;


Michael


 =
;


 =
;








From: Tony Rutkowski [mailto:tony@yaanatech.co.uk]


Sent: Monday, May 23, 2016 9:56 PM

To: Scharf, Michael (Nokia - DE); Jana Iyengar

Cc: quic@ietf.org; Ryan Hamilton

Subject: Re: [QUIC] QUIC privacy impact






 


Hi Michael,



So like...could the identifier be used by a provider

to lessen culpability their culpability in implementing

the Digital Millennium Copyright Act?  The recent

$25 million fine against one provider provides a

major motivation toward mitigating unlawful used

of encrypted streams of their customers.



--tony




On 2016-05-23 3:16 PM, Scharf, Michael (Nokia - DE) =
wrote:






I am certainly not conce=
rned about “stupid” implementations. I am concerned about imple=
mentations
 that understand how to “intelligently” leverage this identifie=
r and this is the type of analysis I expect in a comprehensive security con=
sideration section. Some of the malicious use if this ID may perhaps be cla=
ssified by as an active attack on user privacy
 but still the attack vector seems to me quite different to what an attacke=
r can do with similar means with TCP.





 








--_000_655C07320163294895BBADA28372AF5D48863D26FR712WXCHMBA15z_--


From nobody Mon May 23 13:27:39 2016
Return-Path: 
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 936EE12DB8C for ; Mon, 23 May 2016 13:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 g-x4GfdgU3RQ for ; Mon, 23 May 2016 13:27:36 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 37BC812DB70 for ; Mon, 23 May 2016 13:27:36 -0700 (PDT)
Received: by mail-ig0-x236.google.com with SMTP id fh2so29309945igd.1 for ; Mon, 23 May 2016 13:27:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=cJjqepnxMDm3RHiFK9WqDrpholamxkWi6nq3Dt0NX68=; b=rwHenYmVSF1xYs2CFTSzOHtdr3TYQUxKYoMTm0oZhLpA6g9/zxCUP2YrLUlpQ8ooGi Gyw6jZ86plwUJvPbgsHrdp8U9FYmYXF9mbHbRqu2CKyvP3qqW0WF+nme/faBMN7lHN3k ucl9GbE3DcXvu93T3IHNPUgpWy8IQ1LeFOySwjUxL/qU2CvVVuZN5o8vf7hSXPzcBFY8 AaX4JlBbuVzrV0xdowGejQeDYYCcT+JcK0ew9oqC+V5zjYdGWDjd1dZZ0Fr+92p0PeVO 5fzzJcPKcAJgbJFFAKs1Jz4qNfr3wEw8v9mLlVjLbFBVGgaX4RkZ8hYngsrPwpae8nP+ VvoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=cJjqepnxMDm3RHiFK9WqDrpholamxkWi6nq3Dt0NX68=; b=QamvSxdscS3xTGjXGwcX5XjppU63gp0d1/0WMfKNgPkrnmLy8ZL85Ted19ov6MspvL S1EmG4ZR43WvqD2G9zQi3paKqLQzDknZVWvofgJ2aCOEEWInoszHYpVyqAnpZErvof26 UssaFkeyEadQYIIL/J8+YOKb/w7Dl+hFF6cZrB9G8P6Wm7+S5AnIiqO/B0KOcOH7hEYX Q5vhrw9QOS3SUBP8FWmddjwqGNnF6XpmBXaqHx/n6jE3nXQcV0n/sZGD+LX52yw38pOC Ds1ng8SLQ1pAcwpv3pW5z1DzdFKjTDae0UlypKMwxIq2cVHDKOXnIDqUN5ErX0m6ebfQ hRww==
X-Gm-Message-State: AOPr4FVNhW5U5wRiNvJ7qj/RLY4ZMSSKMT1yLX2n7qb7dxKFsWgLVyGOnEtFH5T9XsDAoyjDc6H9fbRnJKfovg==
MIME-Version: 1.0
X-Received: by 10.50.58.71 with SMTP id o7mr15170563igq.77.1464035255608; Mon, 23 May 2016 13:27:35 -0700 (PDT)
Received: by 10.36.43.23 with HTTP; Mon, 23 May 2016 13:27:35 -0700 (PDT)
In-Reply-To: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>       
Date: Mon, 23 May 2016 16:27:35 -0400
Message-ID: 
From: Martin Thomson 
To: Jana Iyengar 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Ted Hardie , Julian Reschke , Ian Swett , Cory Benfield , Mark Nottingham , Christian Huitema , quic@ietf.org
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 20:27:37 -0000

On 23 May 2016 at 16:03, Jana Iyengar  wrote:
> By extension, HTTP/2 extensions will by default extend h2 and not h2q, and
> may rely on TCP underneath. As a rule, I think we have to assume that
> they'll need to explicitly map to QUIC.

I think that this is the safest assumption.  Extensions for "h2" don't
immediately port to "h2q".

That said, we do have in order guarantees on both stream 3 and stream
N, so maybe, just maybe, there is a simple set of guidelines we can
produce that will be generally applicable to most, if not all,
extensions.


From nobody Mon May 23 13:36:11 2016
Return-Path: 
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 CA71712D572 for ; Mon, 23 May 2016 13:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 GEj8rLl5nVFA for ; Mon, 23 May 2016 13:36:07 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 D913012D55D for ; Mon, 23 May 2016 13:36:03 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id c127so65628275ywb.1 for ; Mon, 23 May 2016 13:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VWSgd/HkKatcr5QAXnfNH/PkEyRCR1OvGnNvEuxNKXE=; b=WdYUMbpbisakWjWB97NqUf9RFIAvKdBHP1qi+X8Oit+xHQtc9Litntb9X32AjMUDqS 2S32J6717WH6SaICKsT+q6/U0WHWb2/BWGjtOGCNBjQT0o8UiUT9uj/RYBHzsrf0o9cp WPVtimtLb+3+qpJr0G34vTDFGZjPWsipiUI/q3btrceQOGqAgBGgaaJMW3XWzkgXC/cj Z8ByHUHmPI5jcMIudmE2MzwGGgpT4RhPWIMzmUACvCKsvm3hh+3UcYjQyjbpSFkYk6gN sQ7R3xEMi9mddj+veMvzY82mQZXrrtYTveAbX15UNjvBVSHBU61JeXFycyxW88Qh/qEc M8PQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VWSgd/HkKatcr5QAXnfNH/PkEyRCR1OvGnNvEuxNKXE=; b=i3OPceXobz/d7HVlMy3I+WlCXK4Jb7wDaiy6R0VHon4A4jkaEgu2M/MNb5UbUquqs4 1GrTwA8Cv5DjQd+X4ZNUl069sJAMIJnfSLrPUtLbnQpFKd/ZCVr0nf3fAmScWySqRhia dv+5Z9B8p3fXHCm5rGciJ241RySzAUSOkUBrdzL84tMEeYGekncY0jYhTvsyB5hkhoxm E6gYQ21j4YT/00Gn/W2gvrHLzcqvzCOdLebXJNZ3PIwwaPyF2YTVh/h7mF7bLgkrYw6P QhbniPzDSvnaT3BYxJy9n4OvYWXqMP+ODNnHZRHBJewekcvxroBvVvD25dyp1P2qWHDf I8Yg==
X-Gm-Message-State: ALyK8tLRmHS0Qw0SuCf9Zn/s2c/6ehFZNH4BGbRrG9POACitUTyRKLFhBusU7HxxpKvFKHH0F7n3ItbOayvKzq0f
X-Received: by 10.13.237.1 with SMTP id w1mr474642ywe.62.1464035762873; Mon, 23 May 2016 13:36:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 13:36:01 -0700 (PDT)
In-Reply-To: <655C07320163294895BBADA28372AF5D48863C11@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D48863C11@FR712WXCHMBA15.zeu.alcatel-lucent.com>
From: Jana Iyengar 
Date: Mon, 23 May 2016 13:36:01 -0700
Message-ID: 
To: "Scharf, Michael (Nokia - DE)" 
Content-Type: multipart/alternative; boundary=94eb2c0864a8966d1d053388636d
Archived-At: 
Cc: "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 20:36:11 -0000

--94eb2c0864a8966d1d053388636d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If your point is that there should be a Security Considerations section in
the QUIC protocol draft, point taken, and I agree that there should be one
that discusses privacy considerations as well. I think my only argument for
now is that this discussion can wait until after the wg is formed.

A bit more inline:

On Mon, May 23, 2016 at 12:16 PM, Scharf, Michael (Nokia - DE) <
michael.scharf@nokia.com> wrote:

> I am certainly not concerned about =E2=80=9Cstupid=E2=80=9D implementatio=
ns. I am
> concerned about implementations that understand how to =E2=80=9Cintellige=
ntly=E2=80=9D
> leverage this identifier and this is the type of analysis I expect in a
> comprehensive security consideration section. Some of the malicious use i=
f
> this ID may perhaps be classified by as an active attack on user privacy
> but still the attack vector seems to me quite different to what an attack=
er
> can do with similar means with TCP.
>
>
>
> At first sight I see quite a number of additional problems compared to th=
e
> TCP ISN:
>
>
>
> =C2=B7         As TCP stacks do not offer an API for setting the ISN,
> modification of the TCP ISN would require a kernel patch, administrator
> rights, etc. The barrier for that is high. The deployment model of a user
> space UDP protocol stack seems different to that.
>
To be clear, we don't rely on TCP for privacy and security properties, we
rely on TLS for these things. Most TLS implementations live in userspace,
often inside applications. I think you'd agree that it's tenuous at best to
argue that a userspace transport is any more vulnerable than TLS.

> =C2=B7         The TCP ISN will not be conveyed over TCP/HTTP proxies and
> there are firewalls that randomize the ISN. So, using the TCP ISN as a
> covert channel or =E2=80=9Cclear text super cookie=E2=80=9D would not wor=
k in many
> environments
>
=C2=B7         The ISN only applies to the SYN and not to every packet, so =
at
> least monitoring of the ISN by a passive attack seems more difficult
>
> =C2=B7         There are only 32 bits (possibly some more when using othe=
r
> header fields)
>
> =C2=B7         I fail to understand how a passive attacker can use the IS=
N
> passively for user location tracking etc.
>
I was trying to point out that there are cleartext fields in TCP, and are
visible to a passive attacker, just as the connection ID is in QUIC. I
don't want to argue these specific points since I don't want us to go
astray from the core point below:

Anyway, I believe that the QUIC connection ID has to be carefully reviewed
> by better security experts than me, so I am certainly willing to learn if=
 I
> miss something.
>

Absolutely, I agree. I expect that it will be reviewed by security experts
in the wg.

- jana


>
> Michael
>
>
>
>
>
> *From:* Jana Iyengar [mailto:jri@google.com]
> *Sent:* Monday, May 23, 2016 8:02 PM
> *To:* Scharf, Michael (Nokia - DE)
> *Cc:* Ryan Hamilton; quic@ietf.org
>
> *Subject:* Re: [QUIC] QUIC privacy impact
>
>
>
> On Sun, May 22, 2016 at 10:32 AM, Scharf, Michael (Nokia - DE) <
> michael.scharf@nokia.com> wrote:
>
> draft-tsvwg-quic-protocol-02 says:
>
>
>
>   QUIC connections are identified by a 64-bit Connection ID, randomly
>
>    generated by the client.  QUIC can survive IP address changes and NAT
>
>    re-bindings since the Connection ID remains the same across these
>
>    migrations.
>
>
>
> So, can we agree that this statement is very, very vague?
>
>
>
> For instance, could I write a QUIC implementation compliant to
> draft-tsvwg-quic-protocol-02 that e.g. uses a static and a random part of
> the connection ID, and e.g. stores the static part permanently on the
> user=E2=80=99s computer? Or, could I pick as a static part the MAC addres=
s? The
> total ID would still be random. I have difficulties to understand how thi=
s
> sort of ID generation would be different from a =E2=80=9Cclear text super=
 cookie=E2=80=9D
> and what is defined in the reference you provide.
>
>
>
> I am sure that this is not what the current QUIC implementation does. But
> since we are in IETF context, talking about a potential standard, I am
> concerned what other implementers of a new protocol could do, and what us=
e
> cases they could find for this ID.
>
>
>
> And if there was some interesting use of having an entirely user-defined
> clear text value at some constant offset in the packet, for a widely used
> Internet transport protocol, I am pretty sure some implementers would not
> care about some MUSTs in an RFC saying =E2=80=9Cplease, please, please se=
lect every
> bit in the ID randomly=E2=80=9D.
>
>
>
> Or do I miss something obvious?
>
>
>
> Yes. The fact that you can't keep stupid implementations from hurting use=
r
> privacy. The TCP ISN is unspecified, and it can always be used for packin=
g
> whatever user-privacy-revealing information you want. That would be very
> very dumb, but it's not out of spec for TCP.
>
>
>
> I'll agree that we can and should have text in the spec that says
> implementations SHOULD not do stupid things.
>
>
>
> - jana
>
>
>
>
>
> Michael
>
>
>
>
>
>
>
>
>
> *From:* Jana Iyengar [mailto:jri@google.com]
> *Sent:* Sunday, May 22, 2016 5:20 AM
> *To:* Ryan Hamilton
> *Cc:* quic@ietf.org; Scharf, Michael (Nokia - DE)
> *Subject:* Re: [QUIC] QUIC privacy impact
>
>
>
> Michael,
>
>
>
> Just caught up on the SPUD thread, and I'd like to correct something you
> said there that I'll quote here for context:
>
> *"if there is now a new clear text identifier that just happens to be
> unique per subscriber. What a great improvement for privacy in the
> Internet! And even better that it seems compatible with QUIC..."*
>
>
>
> QUIC's connection ID is NOT unique per subscriber. It's per connection. A=
s
> I said on the other thread, in the single-path case, it reveals no more
> informtion than TCP. In the multipath case, it effectively reveals no mor=
e
> than MPTCP, since the ID is used to tie the multiple, using MPTCP
> parlance, "sub-flows", together. It is possible to consider a different
> design that uses multiple connection IDs for the multiple sub-flows, but =
to
> be clear, that makes this new multipath strictly better than MPTCP at
> privacy-preservation.
>
>
>
> At any rate, I wanted to make sure that we're talking about the same
> issue. I'll also note that it's plain wrong to use the term "clear text
> super cookie" in relation to the QUIC connection ID (see
> https://www.techopedia.com/definition/27310/super-cookie for what I think
> a supercookie is.)
>
>
>
> - jana
>
>
>
> On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar  wrote:
>
> That's a design element that should and will definitely be discussed in
> the WG.
>
> Specifically this applies to use of connection IDs during multipath, and =
I
> expect that conversation to happen when we discuss multipath.
>
> On May 21, 2016 6:56 AM, "Ryan Hamilton"  wrote:
>
> Definitely.
>
>
>
> On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) <
> michael.scharf@nokia.com> wrote:
>
> Is it planned to discuss potential privacy implications of the =E2=80=9EQ=
UIC
> connection identifier=E2=80=9C (also named =E2=80=9Cclear text super cook=
ie=E2=80=9D on the SPUD
> list)?
>
>
>
> Thanks
>
>
>
> Michael
>
>
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *EXT Ted Hardie
> *Sent:* Saturday, May 14, 2016 1:27 AM
> *To:* quic@ietf.org; Jana Iyengar; Christian Huitema
> *Subject:* [QUIC] Draft charter
>
>
>
> Howdy,
>
> As part of the BoF preparation, we put together a stab at a draft
> charter.  It's available as html and markdown on github at:
>
> https://github.com/IETF-QUIC/Charter
>
> I've attached the HTML version as well.
>
> It would be great to have some of the discussion on the list before the
> BoF.  Comments to the list or issues/pull requests at the github repo are
> welcome.  We will periodically reflect any issues or suggestion from the
> Repo back to the list, but this will be manual, so expect some lag.
>
>
>
> regards,
>
> Ted
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>
>
>
>

--94eb2c0864a8966d1d053388636d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


If your point is that there should be a Security Cons=
iderations section in the QUIC protocol draft, point taken, and I agree tha=
t there should be one that discusses privacy considerations as well. I thin=
k my only argument for now is that this discussion can wait until after the=
 wg is formed.

A bit more inline:

On Mon, May 23, 201=
6 at 12:16 PM, Scharf, Michael (Nokia - DE) <michael.scharf@nokia=
.com> wrote:











I am certa=
inly not concerned about =E2=80=9Cstupid=E2=80=9D implementations. I am con=
cerned about implementations that understand how to =E2=80=9Cintelligently=
=E2=80=9D leverage
 this identifier and this is the type of analysis I expect in a comprehensi=
ve security consideration section. Some of the malicious use if this ID may=
 perhaps be classified by as an active attack on user privacy but still the=
 attack vector seems to me quite
 different to what an attacker can do with similar means with TCP. <=
u>


=C2=
=A0


At first s=
ight I see quite a number of additional problems compared to the TCP ISN:


=C2=
=A0


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
As TC=
P stacks do not offer an API for setting the ISN, modification of the TCP I=
SN would require a kernel patch, administrator rights,
 etc. The barrier for that is high. The deployment model of a user space UD=
P protocol stack seems different to that.
To be clear, we don't rely on TCP for privacy and security prope=
rties, we rely on TLS for these things. Most TLS implementations live in us=
erspace, often inside applications. I think you'd agree that it's t=
enuous at best to argue that a userspace transport is any more vulnerable t=
han TLS.
=



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
The T=
CP ISN will not be conveyed over TCP/HTTP proxies and there are firewalls t=
hat randomize the ISN. So, using the TCP ISN as a covert
 channel or =E2=80=9Cclear text super cookie=E2=80=9D would not work in man=
y environments
=
=C2=B7=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
The I=
SN only applies to the SYN and not to every packet, so at least monitoring =
of the ISN by a passive attack seems more difficult

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
There=
 are only 32 bits (possibly some more when using other header fields)


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
I fai=
l to understand how a passive attacker can use the ISN passively for user l=
ocation tracking etc.
I was trying =
to point out that there are cleartext fields in TCP, and are visible to a p=
assive attacker, just as the connection ID is in QUIC. I don't want to =
argue these specific points since I don't want us to go astray from the=
 core point below:



Anyway, I =
believe that the QUIC connection ID has to be carefully reviewed by better =
security experts than me, so I am certainly willing to learn
 if I miss something.

Absolutely, I agree. I expect that it will be reviewed by security expert=
s in the wg.

- jana

<=
p class=3D"MsoNormal">=C2=A0


Michael=



=C2=
=A0


=C2=
=A0








From: Jana Iye=
ngar [mailto:jri@google=
.com]


Sent: Monday, May 23, 2016 8:02 PM

To: Scharf, Michael (Nokia - DE)

Cc: Ryan Hamilton; quic@ietf.org


Subject: Re: [QUIC] QUIC privacy impact
=







=C2=A0








On Sun, May 22, 2016 at 10:32 AM, Scharf, Michael (N=
okia - DE) <michael.scharf@nokia.com> wrote:






draft-tsvw=
g-quic-protocol-02 says:



=C2=A0


=C2=A0=C2=A0QUIC connections are identified=
 by a 64-bit Connection ID, randomly


=C2=A0=C2=A0 generated by the client.=C2=A0=
 QUIC can survive IP address changes and NAT


=C2=A0=C2=A0 re-bindings since the Connecti=
on ID remains the same across these


=C2=A0=C2=A0
migrations. 



=C2=A0


So, can we=
 agree that this statement is very, very vague?


=C2=A0


For instan=
ce, could I write a QUIC implementation compliant to draft-tsvwg-quic-proto=
col-02
 that e.g. uses a static and a random part of the connection ID, and e.g. s=
tores the static part permanently on the user=E2=80=99s computer? Or, could=
 I pick as a static part the MAC address? The total ID would still be rando=
m. I have difficulties to understand how
 this sort of ID generation would be different from a =E2=80=9Cclear text s=
uper cookie=E2=80=9D and what is defined in the reference you provide.


=C2=A0


I am sure =
that this is not what the current QUIC implementation does. But since we ar=
e
 in IETF context, talking about a potential standard, I am concerned what o=
ther implementers of a new protocol could do, and what use cases they could=
 find for this ID.


=C2=A0


And if the=
re was some interesting use of having an entirely user-defined clear text
 value at some constant offset in the packet, for a widely used Internet tr=
ansport protocol, I am pretty sure some implementers would not care about s=
ome MUSTs in an RFC saying =E2=80=9Cplease, please, please select every bit=
 in the ID randomly=E2=80=9D.



=C2=A0


Or do I mi=
ss something obvious?








=C2=A0






Yes. The fact that you can't keep stupid impleme=
ntations from hurting user privacy. The TCP ISN is unspecified, and it can =
always be used for packing whatever user-privacy-revealing information you =
want. That would be very very dumb, but
 it's not out of spec for TCP.






=C2=A0






I'll agree that we can and should have text in t=
he spec that says implementations SHOULD not do stupid things.






=C2=A0






- jana






=C2=A0










=C2=A0


Michael


=C2=A0


=C2=A0


=C2=A0


=C2=A0








From: Jana Iye=
ngar [mailto:jri@google=
.com]


Sent: Sunday, May 22, 2016 5:20 AM

To: Ryan Hamilton

Cc: quic@ietf.org=
; Scharf, Michael (Nokia - DE)

Subject: Re: [QUIC] QUIC privacy impact






=C2=A0






Michael,=











=C2=A0




Just caught up on the SPUD thread, and I'd like =
to correct something you said there that I'll quote here for context:=
=C2=A0




"if there is now a new clear text identifier=
 that just happens to be unique per subscriber. What a great improvement fo=
r privacy in the Internet! And even better that it seems
 compatible with QUIC..."






=C2=A0






QUIC's connection ID is NOT unique per subscribe=
r. It's per connection. As I said on the other thread, in the single-pa=
th case, it reveals no more informtion than TCP. In the multipath
 case, it effectively reveals no more than MPTCP, since the ID is used to t=
ie the multiple, using MPTCP parlance,=C2=A0"sub-flows", together=
. It is possible to consider a different design that uses multiple connecti=
on IDs for the multiple sub-flows, but to be clear,
 that makes this new multipath strictly better than MPTCP=C2=A0at privacy-p=
reservation.






=C2=A0






At any rate, I wanted to make sure that we're ta=
lking about the same issue. I'll also note that it's plain wrong to=
 use the term "clear text super cookie" in relation to the QUIC
 connection ID (see=C2=A0https://www.techopedia.com/definition/=
27310/super-cookie=C2=A0for what I think a supercookie is.)






=C2=A0






- jana
















=C2=A0




On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar <jri@google.com> wr=
ote:


That's a design element that should and will definitely be discussed=
 in the WG.


Specifically this applies to use of connection IDs during multipath, and=
 I expect that conversation to happen when we discuss multipath.<=
/u>








On May 21, 2016 6:56 AM, "Ryan Hamilton" &=
lt;rch@google.com&g=
t; wrote:






Definitely.








=C2=A0




On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (N=
okia - DE) <michael.scharf@nokia.com> wrote:






Is it plan=
ned to discuss potential privacy implications of the =E2=80=9EQUIC connecti=
on identifier=E2=80=9C
 (also named =E2=80=9Cclear text super cookie=E2=80=9D on the SPUD list)?


=C2=A0


Thanks


=C2=A0


Michael


=C2=A0


=C2=A0








From: QUIC [ma=
ilto:quic-bounce=
s@ietf.org]
On Behalf Of EXT Ted Hardie

Sent: Saturday, May 14, 2016 1:27 AM

To: quic@ietf.org=
; Jana Iyengar; Christian Huitema

Subject: [QUIC] Draft charter






=C2=A0












Howdy,<=
/p>



As part of the BoF pr=
eparation, we put together a stab at a draft charter.=C2=A0 It's availa=
ble as html and markdown on github at:



https://=
github.com/IETF-QUIC/Charter




I've attached the=
 HTML version as well.=C2=A0







It would be great to have some of the discussion on =
the list before the BoF.=C2=A0 Comments to the list or issues/pull requests=
 at the github repo are welcome.=C2=A0 We will periodically
 reflect any issues or suggestion from the Repo back to the list, but this =
will be manual, so expect some lag.






=C2=A0




regards,




Ted












_______________________________________________

QUIC mailing list

QUIC@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/quic




=C2=A0






_______________________________________________

QUIC mailing list

QUIC@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/quic










=C2=A0


















=C2=A0
















--94eb2c0864a8966d1d053388636d--


From nobody Mon May 23 13:51:43 2016
Return-Path: 
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 C92D212D55D for ; Mon, 23 May 2016 13:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 QfG7pGaBd3tm for ; Mon, 23 May 2016 13:51:39 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 14E2B12D1AA for ; Mon, 23 May 2016 13:51:39 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id h19so29971199ywc.0 for ; Mon, 23 May 2016 13:51:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dLKKbPeE/yaOwugXOhYn17/i/UVRjS2xaHx9VDPb+yo=; b=B3cAY6n3CaH5HheK1UwgZ5eavzlb73wYT+8sqmSo9/NL+bNnVteS9hyovT/2VLxyP9 NYmSTLyBOIpORFcsO6l47u0/ysdgIJOCud2+3vI8bXDsCyD7eWO10Fj7yJX/0uD9lVDp bM7uZFQW7Q5g0VQPkIxno4atx/eoBYpS/TX1GNBvxDncnfhbfAaDzEPMZaf90FpLa2Nw 8IBoaD567Mfl1W8QpGpht3DJAwqzGOGDFHtBpekZYmIz4l9ZVG3DnNruHVv1Hck8XsK3 FffqZ2xdO2xOiFjKxFP0r/AqOL/bQQQwCHqgZ2p8M3XUy6JpeTyhG14pLLA/PcTtrXcT nUQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dLKKbPeE/yaOwugXOhYn17/i/UVRjS2xaHx9VDPb+yo=; b=cDm1gwfQFIiC3rHsxqI5kCJoIUxU0wOEp7T399xf09wYT1AvYaf/LzUcxkhP2IjkWV t8qfCz5Nnj/eow1gbJ2RNx/r+79Nh9qu0or+L0anAkbI855XukAMvNtk4r0JnCiRkE32 442IZVhhuUREL5GueCUHh3QJuhn8Tliap3d1w/uGvlBYkHjEBvKvTNOsk+zd3XYxjVig dmfF40UTVjl7syXXP2mZXrdwJ6Dretsa+GMj1HAd6UEIv0EVXxzp80vXxgrMgV2YMF93 6ZE8Jy2Ogu8Nn0H4Cp/KuXYZFauadyoHIdaQhVvN87pPi+4bi8yVnmopNcGQFW0aCbTM MXgQ==
X-Gm-Message-State: ALyK8tKqkZ2NwwSs7oAAdpdaeF2WT0umTZ++gOOIamXIkt1n9vR1bRtyQONlLnTw8zM+dKyKvwo0bwrt7LEkOx9j
X-Received: by 10.13.198.197 with SMTP id i188mr467993ywd.207.1464036698150; Mon, 23 May 2016 13:51:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 13:51:37 -0700 (PDT)
In-Reply-To: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>        
From: Jana Iyengar 
Date: Mon, 23 May 2016 13:51:37 -0700
Message-ID: 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=001a114d6f745560da0533889b6b
Archived-At: 
Cc: Ted Hardie , Julian Reschke , Ian Swett , Cory Benfield , Mark Nottingham , Christian Huitema , quic@ietf.org
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 20:51:41 -0000

--001a114d6f745560da0533889b6b
Content-Type: text/plain; charset=UTF-8

On Mon, May 23, 2016 at 1:27 PM, Martin Thomson 
wrote:

> On 23 May 2016 at 16:03, Jana Iyengar  wrote:
> > By extension, HTTP/2 extensions will by default extend h2 and not h2q,
> and
> > may rely on TCP underneath. As a rule, I think we have to assume that
> > they'll need to explicitly map to QUIC.
>
> I think that this is the safest assumption.  Extensions for "h2" don't
> immediately port to "h2q".
>

Agreed.


> That said, we do have in order guarantees on both stream 3 and stream
> N, so maybe, just maybe, there is a simple set of guidelines we can
> produce that will be generally applicable to most, if not all,
> extensions.
>

Agreed.

--001a114d6f745560da0533889b6b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Mon, May 23, 2016 at 1:27 PM, Martin Thomson <martin.thomson@gma=
il.com> wrote:
On 23 May 2016 at 16:03, Jana Iyengar <jri@google.com> wrote:

> By extension, HTTP/2 extensions will by default extend h2 and not h2q,=
 and

> may rely on TCP underneath. As a rule, I think we have to assume that<=
br>
> they'll need to explicitly map to QUIC.



I think that this is the safest assumption.=C2=A0 Extensions for &qu=
ot;h2" don't

immediately port to "h2q".

Ag=
reed.
=C2=A0

That said, we do have in order guarantees on both stream 3 and stream

N, so maybe, just maybe, there is a simple set of guidelines we can

produce that will be generally applicable to most, if not all,

extensions.



Agreed.


--001a114d6f745560da0533889b6b--


From nobody Mon May 23 14:14:54 2016
Return-Path: 
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 C353012DBD2 for ; Mon, 23 May 2016 14:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 KhMdMt93fTlb for ; Mon, 23 May 2016 14:14:49 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0AB12DBAC for ; Mon, 23 May 2016 14:14:49 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 004A9262022A8; Mon, 23 May 2016 21:14:42 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NLEk2l019586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 21:14:47 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NLEjGr012033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 23:14:45 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 23 May 2016 23:14:45 +0200
From: "Scharf, Michael (Nokia - DE)" 
To: Jana Iyengar 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynFCnTysxHU/0GFj3E4WoIavJ/DSSMAgAAj/ACAALzBAIABBqOQgAGB/gCAACh9YIAAApeAgAAk0AA=
Date: Mon, 23 May 2016 21:14:44 +0000
Message-ID: <655C07320163294895BBADA28372AF5D4886662C@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D48863C11@FR712WXCHMBA15.zeu.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D4886662CFR712WXCHMBA15z_"
MIME-Version: 1.0
Archived-At: 
Cc: "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 21:14:53 -0000

--_000_655C07320163294895BBADA28372AF5D4886662CFR712WXCHMBA15z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

LTEgb24gdGhhdCB1c2VyIHByaXZhY3kgY2FuIHNpbXBseSB3YWl0IHVudGlsIHRoZSBXRyBpcyBm
b3JtZWQNCg0KTWljaGFlbA0KDQoNCkZyb206IEphbmEgSXllbmdhciBbbWFpbHRvOmpyaUBnb29n
bGUuY29tXQ0KU2VudDogTW9uZGF5LCBNYXkgMjMsIDIwMTYgMTA6MzYgUE0NClRvOiBTY2hhcmYs
IE1pY2hhZWwgKE5va2lhIC0gREUpDQpDYzogUnlhbiBIYW1pbHRvbjsgcXVpY0BpZXRmLm9yZw0K
U3ViamVjdDogUmU6IFtRVUlDXSBRVUlDIHByaXZhY3kgaW1wYWN0DQoNCklmIHlvdXIgcG9pbnQg
aXMgdGhhdCB0aGVyZSBzaG91bGQgYmUgYSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u
IGluIHRoZSBRVUlDIHByb3RvY29sIGRyYWZ0LCBwb2ludCB0YWtlbiwgYW5kIEkgYWdyZWUgdGhh
dCB0aGVyZSBzaG91bGQgYmUgb25lIHRoYXQgZGlzY3Vzc2VzIHByaXZhY3kgY29uc2lkZXJhdGlv
bnMgYXMgd2VsbC4gSSB0aGluayBteSBvbmx5IGFyZ3VtZW50IGZvciBub3cgaXMgdGhhdCB0aGlz
IGRpc2N1c3Npb24gY2FuIHdhaXQgdW50aWwgYWZ0ZXIgdGhlIHdnIGlzIGZvcm1lZC4NCg0KQSBi
aXQgbW9yZSBpbmxpbmU6DQoNCk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDEyOjE2IFBNLCBTY2hh
cmYsIE1pY2hhZWwgKE5va2lhIC0gREUpIDxtaWNoYWVsLnNjaGFyZkBub2tpYS5jb208bWFpbHRv
Om1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbT4+IHdyb3RlOg0KSSBhbSBjZXJ0YWlubHkgbm90IGNv
bmNlcm5lZCBhYm91dCDigJxzdHVwaWTigJ0gaW1wbGVtZW50YXRpb25zLiBJIGFtIGNvbmNlcm5l
ZCBhYm91dCBpbXBsZW1lbnRhdGlvbnMgdGhhdCB1bmRlcnN0YW5kIGhvdyB0byDigJxpbnRlbGxp
Z2VudGx54oCdIGxldmVyYWdlIHRoaXMgaWRlbnRpZmllciBhbmQgdGhpcyBpcyB0aGUgdHlwZSBv
ZiBhbmFseXNpcyBJIGV4cGVjdCBpbiBhIGNvbXByZWhlbnNpdmUgc2VjdXJpdHkgY29uc2lkZXJh
dGlvbiBzZWN0aW9uLiBTb21lIG9mIHRoZSBtYWxpY2lvdXMgdXNlIGlmIHRoaXMgSUQgbWF5IHBl
cmhhcHMgYmUgY2xhc3NpZmllZCBieSBhcyBhbiBhY3RpdmUgYXR0YWNrIG9uIHVzZXIgcHJpdmFj
eSBidXQgc3RpbGwgdGhlIGF0dGFjayB2ZWN0b3Igc2VlbXMgdG8gbWUgcXVpdGUgZGlmZmVyZW50
IHRvIHdoYXQgYW4gYXR0YWNrZXIgY2FuIGRvIHdpdGggc2ltaWxhciBtZWFucyB3aXRoIFRDUC4N
Cg0KQXQgZmlyc3Qgc2lnaHQgSSBzZWUgcXVpdGUgYSBudW1iZXIgb2YgYWRkaXRpb25hbCBwcm9i
bGVtcyBjb21wYXJlZCB0byB0aGUgVENQIElTTjoNCg0KDQrigKIgICAgICAgICBBcyBUQ1Agc3Rh
Y2tzIGRvIG5vdCBvZmZlciBhbiBBUEkgZm9yIHNldHRpbmcgdGhlIElTTiwgbW9kaWZpY2F0aW9u
IG9mIHRoZSBUQ1AgSVNOIHdvdWxkIHJlcXVpcmUgYSBrZXJuZWwgcGF0Y2gsIGFkbWluaXN0cmF0
b3IgcmlnaHRzLCBldGMuIFRoZSBiYXJyaWVyIGZvciB0aGF0IGlzIGhpZ2guIFRoZSBkZXBsb3lt
ZW50IG1vZGVsIG9mIGEgdXNlciBzcGFjZSBVRFAgcHJvdG9jb2wgc3RhY2sgc2VlbXMgZGlmZmVy
ZW50IHRvIHRoYXQuDQpUbyBiZSBjbGVhciwgd2UgZG9uJ3QgcmVseSBvbiBUQ1AgZm9yIHByaXZh
Y3kgYW5kIHNlY3VyaXR5IHByb3BlcnRpZXMsIHdlIHJlbHkgb24gVExTIGZvciB0aGVzZSB0aGlu
Z3MuIE1vc3QgVExTIGltcGxlbWVudGF0aW9ucyBsaXZlIGluIHVzZXJzcGFjZSwgb2Z0ZW4gaW5z
aWRlIGFwcGxpY2F0aW9ucy4gSSB0aGluayB5b3UnZCBhZ3JlZSB0aGF0IGl0J3MgdGVudW91cyBh
dCBiZXN0IHRvIGFyZ3VlIHRoYXQgYSB1c2Vyc3BhY2UgdHJhbnNwb3J0IGlzIGFueSBtb3JlIHZ1
bG5lcmFibGUgdGhhbiBUTFMuDQoNCuKAoiAgICAgICAgIFRoZSBUQ1AgSVNOIHdpbGwgbm90IGJl
IGNvbnZleWVkIG92ZXIgVENQL0hUVFAgcHJveGllcyBhbmQgdGhlcmUgYXJlIGZpcmV3YWxscyB0
aGF0IHJhbmRvbWl6ZSB0aGUgSVNOLiBTbywgdXNpbmcgdGhlIFRDUCBJU04gYXMgYSBjb3ZlcnQg
Y2hhbm5lbCBvciDigJxjbGVhciB0ZXh0IHN1cGVyIGNvb2tpZeKAnSB3b3VsZCBub3Qgd29yayBp
biBtYW55IGVudmlyb25tZW50cw0KDQrigKIgICAgICAgICBUaGUgSVNOIG9ubHkgYXBwbGllcyB0
byB0aGUgU1lOIGFuZCBub3QgdG8gZXZlcnkgcGFja2V0LCBzbyBhdCBsZWFzdCBtb25pdG9yaW5n
IG9mIHRoZSBJU04gYnkgYSBwYXNzaXZlIGF0dGFjayBzZWVtcyBtb3JlIGRpZmZpY3VsdA0KDQri
gKIgICAgICAgICBUaGVyZSBhcmUgb25seSAzMiBiaXRzIChwb3NzaWJseSBzb21lIG1vcmUgd2hl
biB1c2luZyBvdGhlciBoZWFkZXIgZmllbGRzKQ0KDQrigKIgICAgICAgICBJIGZhaWwgdG8gdW5k
ZXJzdGFuZCBob3cgYSBwYXNzaXZlIGF0dGFja2VyIGNhbiB1c2UgdGhlIElTTiBwYXNzaXZlbHkg
Zm9yIHVzZXIgbG9jYXRpb24gdHJhY2tpbmcgZXRjLg0KSSB3YXMgdHJ5aW5nIHRvIHBvaW50IG91
dCB0aGF0IHRoZXJlIGFyZSBjbGVhcnRleHQgZmllbGRzIGluIFRDUCwgYW5kIGFyZSB2aXNpYmxl
IHRvIGEgcGFzc2l2ZSBhdHRhY2tlciwganVzdCBhcyB0aGUgY29ubmVjdGlvbiBJRCBpcyBpbiBR
VUlDLiBJIGRvbid0IHdhbnQgdG8gYXJndWUgdGhlc2Ugc3BlY2lmaWMgcG9pbnRzIHNpbmNlIEkg
ZG9uJ3Qgd2FudCB1cyB0byBnbyBhc3RyYXkgZnJvbSB0aGUgY29yZSBwb2ludCBiZWxvdzoNCg0K
QW55d2F5LCBJIGJlbGlldmUgdGhhdCB0aGUgUVVJQyBjb25uZWN0aW9uIElEIGhhcyB0byBiZSBj
YXJlZnVsbHkgcmV2aWV3ZWQgYnkgYmV0dGVyIHNlY3VyaXR5IGV4cGVydHMgdGhhbiBtZSwgc28g
SSBhbSBjZXJ0YWlubHkgd2lsbGluZyB0byBsZWFybiBpZiBJIG1pc3Mgc29tZXRoaW5nLg0KDQpB
YnNvbHV0ZWx5LCBJIGFncmVlLiBJIGV4cGVjdCB0aGF0IGl0IHdpbGwgYmUgcmV2aWV3ZWQgYnkg
c2VjdXJpdHkgZXhwZXJ0cyBpbiB0aGUgd2cuDQoNCi0gamFuYQ0KDQoNCk1pY2hhZWwNCg0KDQpG
cm9tOiBKYW5hIEl5ZW5nYXIgW21haWx0bzpqcmlAZ29vZ2xlLmNvbTxtYWlsdG86anJpQGdvb2ds
ZS5jb20+XQ0KU2VudDogTW9uZGF5LCBNYXkgMjMsIDIwMTYgODowMiBQTQ0KVG86IFNjaGFyZiwg
TWljaGFlbCAoTm9raWEgLSBERSkNCkNjOiBSeWFuIEhhbWlsdG9uOyBxdWljQGlldGYub3JnPG1h
aWx0bzpxdWljQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW1FVSUNdIFFVSUMgcHJpdmFjeSBp
bXBhY3QNCg0KT24gU3VuLCBNYXkgMjIsIDIwMTYgYXQgMTA6MzIgQU0sIFNjaGFyZiwgTWljaGFl
bCAoTm9raWEgLSBERSkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbTxtYWlsdG86bWljaGFlbC5z
Y2hhcmZAbm9raWEuY29tPj4gd3JvdGU6DQpkcmFmdC10c3Z3Zy1xdWljLXByb3RvY29sLTAyIHNh
eXM6DQoNCiAgUVVJQyBjb25uZWN0aW9ucyBhcmUgaWRlbnRpZmllZCBieSBhIDY0LWJpdCBDb25u
ZWN0aW9uIElELCByYW5kb21seQ0KICAgZ2VuZXJhdGVkIGJ5IHRoZSBjbGllbnQuICBRVUlDIGNh
biBzdXJ2aXZlIElQIGFkZHJlc3MgY2hhbmdlcyBhbmQgTkFUDQogICByZS1iaW5kaW5ncyBzaW5j
ZSB0aGUgQ29ubmVjdGlvbiBJRCByZW1haW5zIHRoZSBzYW1lIGFjcm9zcyB0aGVzZQ0KICAgbWln
cmF0aW9ucy4NCg0KU28sIGNhbiB3ZSBhZ3JlZSB0aGF0IHRoaXMgc3RhdGVtZW50IGlzIHZlcnks
IHZlcnkgdmFndWU/DQoNCkZvciBpbnN0YW5jZSwgY291bGQgSSB3cml0ZSBhIFFVSUMgaW1wbGVt
ZW50YXRpb24gY29tcGxpYW50IHRvIGRyYWZ0LXRzdndnLXF1aWMtcHJvdG9jb2wtMDIgdGhhdCBl
LmcuIHVzZXMgYSBzdGF0aWMgYW5kIGEgcmFuZG9tIHBhcnQgb2YgdGhlIGNvbm5lY3Rpb24gSUQs
IGFuZCBlLmcuIHN0b3JlcyB0aGUgc3RhdGljIHBhcnQgcGVybWFuZW50bHkgb24gdGhlIHVzZXLi
gJlzIGNvbXB1dGVyPyBPciwgY291bGQgSSBwaWNrIGFzIGEgc3RhdGljIHBhcnQgdGhlIE1BQyBh
ZGRyZXNzPyBUaGUgdG90YWwgSUQgd291bGQgc3RpbGwgYmUgcmFuZG9tLiBJIGhhdmUgZGlmZmlj
dWx0aWVzIHRvIHVuZGVyc3RhbmQgaG93IHRoaXMgc29ydCBvZiBJRCBnZW5lcmF0aW9uIHdvdWxk
IGJlIGRpZmZlcmVudCBmcm9tIGEg4oCcY2xlYXIgdGV4dCBzdXBlciBjb29raWXigJ0gYW5kIHdo
YXQgaXMgZGVmaW5lZCBpbiB0aGUgcmVmZXJlbmNlIHlvdSBwcm92aWRlLg0KDQpJIGFtIHN1cmUg
dGhhdCB0aGlzIGlzIG5vdCB3aGF0IHRoZSBjdXJyZW50IFFVSUMgaW1wbGVtZW50YXRpb24gZG9l
cy4gQnV0IHNpbmNlIHdlIGFyZSBpbiBJRVRGIGNvbnRleHQsIHRhbGtpbmcgYWJvdXQgYSBwb3Rl
bnRpYWwgc3RhbmRhcmQsIEkgYW0gY29uY2VybmVkIHdoYXQgb3RoZXIgaW1wbGVtZW50ZXJzIG9m
IGEgbmV3IHByb3RvY29sIGNvdWxkIGRvLCBhbmQgd2hhdCB1c2UgY2FzZXMgdGhleSBjb3VsZCBm
aW5kIGZvciB0aGlzIElELg0KDQpBbmQgaWYgdGhlcmUgd2FzIHNvbWUgaW50ZXJlc3RpbmcgdXNl
IG9mIGhhdmluZyBhbiBlbnRpcmVseSB1c2VyLWRlZmluZWQgY2xlYXIgdGV4dCB2YWx1ZSBhdCBz
b21lIGNvbnN0YW50IG9mZnNldCBpbiB0aGUgcGFja2V0LCBmb3IgYSB3aWRlbHkgdXNlZCBJbnRl
cm5ldCB0cmFuc3BvcnQgcHJvdG9jb2wsIEkgYW0gcHJldHR5IHN1cmUgc29tZSBpbXBsZW1lbnRl
cnMgd291bGQgbm90IGNhcmUgYWJvdXQgc29tZSBNVVNUcyBpbiBhbiBSRkMgc2F5aW5nIOKAnHBs
ZWFzZSwgcGxlYXNlLCBwbGVhc2Ugc2VsZWN0IGV2ZXJ5IGJpdCBpbiB0aGUgSUQgcmFuZG9tbHni
gJ0uDQoNCk9yIGRvIEkgbWlzcyBzb21ldGhpbmcgb2J2aW91cz8NCg0KWWVzLiBUaGUgZmFjdCB0
aGF0IHlvdSBjYW4ndCBrZWVwIHN0dXBpZCBpbXBsZW1lbnRhdGlvbnMgZnJvbSBodXJ0aW5nIHVz
ZXIgcHJpdmFjeS4gVGhlIFRDUCBJU04gaXMgdW5zcGVjaWZpZWQsIGFuZCBpdCBjYW4gYWx3YXlz
IGJlIHVzZWQgZm9yIHBhY2tpbmcgd2hhdGV2ZXIgdXNlci1wcml2YWN5LXJldmVhbGluZyBpbmZv
cm1hdGlvbiB5b3Ugd2FudC4gVGhhdCB3b3VsZCBiZSB2ZXJ5IHZlcnkgZHVtYiwgYnV0IGl0J3Mg
bm90IG91dCBvZiBzcGVjIGZvciBUQ1AuDQoNCkknbGwgYWdyZWUgdGhhdCB3ZSBjYW4gYW5kIHNo
b3VsZCBoYXZlIHRleHQgaW4gdGhlIHNwZWMgdGhhdCBzYXlzIGltcGxlbWVudGF0aW9ucyBTSE9V
TEQgbm90IGRvIHN0dXBpZCB0aGluZ3MuDQoNCi0gamFuYQ0KDQoNCk1pY2hhZWwNCg0KDQoNCg0K
RnJvbTogSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29n
bGUuY29tPl0NClNlbnQ6IFN1bmRheSwgTWF5IDIyLCAyMDE2IDU6MjAgQU0NClRvOiBSeWFuIEhh
bWlsdG9uDQpDYzogcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz47IFNjaGFyZiwg
TWljaGFlbCAoTm9raWEgLSBERSkNClN1YmplY3Q6IFJlOiBbUVVJQ10gUVVJQyBwcml2YWN5IGlt
cGFjdA0KDQpNaWNoYWVsLA0KDQpKdXN0IGNhdWdodCB1cCBvbiB0aGUgU1BVRCB0aHJlYWQsIGFu
ZCBJJ2QgbGlrZSB0byBjb3JyZWN0IHNvbWV0aGluZyB5b3Ugc2FpZCB0aGVyZSB0aGF0IEknbGwg
cXVvdGUgaGVyZSBmb3IgY29udGV4dDoNCiJpZiB0aGVyZSBpcyBub3cgYSBuZXcgY2xlYXIgdGV4
dCBpZGVudGlmaWVyIHRoYXQganVzdCBoYXBwZW5zIHRvIGJlIHVuaXF1ZSBwZXIgc3Vic2NyaWJl
ci4gV2hhdCBhIGdyZWF0IGltcHJvdmVtZW50IGZvciBwcml2YWN5IGluIHRoZSBJbnRlcm5ldCEg
QW5kIGV2ZW4gYmV0dGVyIHRoYXQgaXQgc2VlbXMgY29tcGF0aWJsZSB3aXRoIFFVSUMuLi4iDQoN
ClFVSUMncyBjb25uZWN0aW9uIElEIGlzIE5PVCB1bmlxdWUgcGVyIHN1YnNjcmliZXIuIEl0J3Mg
cGVyIGNvbm5lY3Rpb24uIEFzIEkgc2FpZCBvbiB0aGUgb3RoZXIgdGhyZWFkLCBpbiB0aGUgc2lu
Z2xlLXBhdGggY2FzZSwgaXQgcmV2ZWFscyBubyBtb3JlIGluZm9ybXRpb24gdGhhbiBUQ1AuIElu
IHRoZSBtdWx0aXBhdGggY2FzZSwgaXQgZWZmZWN0aXZlbHkgcmV2ZWFscyBubyBtb3JlIHRoYW4g
TVBUQ1AsIHNpbmNlIHRoZSBJRCBpcyB1c2VkIHRvIHRpZSB0aGUgbXVsdGlwbGUsIHVzaW5nIE1Q
VENQIHBhcmxhbmNlLCAic3ViLWZsb3dzIiwgdG9nZXRoZXIuIEl0IGlzIHBvc3NpYmxlIHRvIGNv
bnNpZGVyIGEgZGlmZmVyZW50IGRlc2lnbiB0aGF0IHVzZXMgbXVsdGlwbGUgY29ubmVjdGlvbiBJ
RHMgZm9yIHRoZSBtdWx0aXBsZSBzdWItZmxvd3MsIGJ1dCB0byBiZSBjbGVhciwgdGhhdCBtYWtl
cyB0aGlzIG5ldyBtdWx0aXBhdGggc3RyaWN0bHkgYmV0dGVyIHRoYW4gTVBUQ1AgYXQgcHJpdmFj
eS1wcmVzZXJ2YXRpb24uDQoNCkF0IGFueSByYXRlLCBJIHdhbnRlZCB0byBtYWtlIHN1cmUgdGhh
dCB3ZSdyZSB0YWxraW5nIGFib3V0IHRoZSBzYW1lIGlzc3VlLiBJJ2xsIGFsc28gbm90ZSB0aGF0
IGl0J3MgcGxhaW4gd3JvbmcgdG8gdXNlIHRoZSB0ZXJtICJjbGVhciB0ZXh0IHN1cGVyIGNvb2tp
ZSIgaW4gcmVsYXRpb24gdG8gdGhlIFFVSUMgY29ubmVjdGlvbiBJRCAoc2VlIGh0dHBzOi8vd3d3
LnRlY2hvcGVkaWEuY29tL2RlZmluaXRpb24vMjczMTAvc3VwZXItY29va2llIGZvciB3aGF0IEkg
dGhpbmsgYSBzdXBlcmNvb2tpZSBpcy4pDQoNCi0gamFuYQ0KDQpPbiBTYXQsIE1heSAyMSwgMjAx
NiBhdCA5OjA0IEFNLCBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPG1haWx0bzpqcmlAZ29v
Z2xlLmNvbT4+IHdyb3RlOg0KDQpUaGF0J3MgYSBkZXNpZ24gZWxlbWVudCB0aGF0IHNob3VsZCBh
bmQgd2lsbCBkZWZpbml0ZWx5IGJlIGRpc2N1c3NlZCBpbiB0aGUgV0cuDQoNClNwZWNpZmljYWxs
eSB0aGlzIGFwcGxpZXMgdG8gdXNlIG9mIGNvbm5lY3Rpb24gSURzIGR1cmluZyBtdWx0aXBhdGgs
IGFuZCBJIGV4cGVjdCB0aGF0IGNvbnZlcnNhdGlvbiB0byBoYXBwZW4gd2hlbiB3ZSBkaXNjdXNz
IG11bHRpcGF0aC4NCk9uIE1heSAyMSwgMjAxNiA2OjU2IEFNLCAiUnlhbiBIYW1pbHRvbiIgPHJj
aEBnb29nbGUuY29tPG1haWx0bzpyY2hAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KRGVmaW5pdGVseS4N
Cg0KT24gRnJpLCBNYXkgMjAsIDIwMTYgYXQgMTE6MjYgUE0sIFNjaGFyZiwgTWljaGFlbCAoTm9r
aWEgLSBERSkgPG1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbTxtYWlsdG86bWljaGFlbC5zY2hhcmZA
bm9raWEuY29tPj4gd3JvdGU6DQpJcyBpdCBwbGFubmVkIHRvIGRpc2N1c3MgcG90ZW50aWFsIHBy
aXZhY3kgaW1wbGljYXRpb25zIG9mIHRoZSDigJ5RVUlDIGNvbm5lY3Rpb24gaWRlbnRpZmllcuKA
nCAoYWxzbyBuYW1lZCDigJxjbGVhciB0ZXh0IHN1cGVyIGNvb2tpZeKAnSBvbiB0aGUgU1BVRCBs
aXN0KT8NCg0KVGhhbmtzDQoNCk1pY2hhZWwNCg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1i
b3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYg
T2YgRVhUIFRlZCBIYXJkaWUNClNlbnQ6IFNhdHVyZGF5LCBNYXkgMTQsIDIwMTYgMToyNyBBTQ0K
VG86IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+OyBKYW5hIEl5ZW5nYXI7IENo
cmlzdGlhbiBIdWl0ZW1hDQpTdWJqZWN0OiBbUVVJQ10gRHJhZnQgY2hhcnRlcg0KDQpIb3dkeSwN
CkFzIHBhcnQgb2YgdGhlIEJvRiBwcmVwYXJhdGlvbiwgd2UgcHV0IHRvZ2V0aGVyIGEgc3RhYiBh
dCBhIGRyYWZ0IGNoYXJ0ZXIuICBJdCdzIGF2YWlsYWJsZSBhcyBodG1sIGFuZCBtYXJrZG93biBv
biBnaXRodWIgYXQ6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9JRVRGLVFVSUMvQ2hhcnRlcg0KSSd2
ZSBhdHRhY2hlZCB0aGUgSFRNTCB2ZXJzaW9uIGFzIHdlbGwuDQpJdCB3b3VsZCBiZSBncmVhdCB0
byBoYXZlIHNvbWUgb2YgdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgYmVmb3JlIHRoZSBCb0Yu
ICBDb21tZW50cyB0byB0aGUgbGlzdCBvciBpc3N1ZXMvcHVsbCByZXF1ZXN0cyBhdCB0aGUgZ2l0
aHViIHJlcG8gYXJlIHdlbGNvbWUuICBXZSB3aWxsIHBlcmlvZGljYWxseSByZWZsZWN0IGFueSBp
c3N1ZXMgb3Igc3VnZ2VzdGlvbiBmcm9tIHRoZSBSZXBvIGJhY2sgdG8gdGhlIGxpc3QsIGJ1dCB0
aGlzIHdpbGwgYmUgbWFudWFsLCBzbyBleHBlY3Qgc29tZSBsYWcuDQoNCnJlZ2FyZHMsDQpUZWQN
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClFVSUMg
bWFpbGluZyBsaXN0DQpRVUlDQGlldGYub3JnPG1haWx0bzpRVUlDQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9xdWljDQoNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClFVSUMgbWFpbGluZyBsaXN0DQpRVUlD
QGlldGYub3JnPG1haWx0bzpRVUlDQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9xdWljDQoNCg0KDQo=

--_000_655C07320163294895BBADA28372AF5D4886662CFR712WXCHMBA15z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1T
IjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u
cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46
MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy
bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0
ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJTcHJlY2hibGFzZW50ZXh0IFpjaG4iOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu
cy1zZXJpZiI7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMTgNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj
b2xvcjojMUY0OTdEO30NCnNwYW4uU3ByZWNoYmxhc2VudGV4dFpjaG4NCgl7bXNvLXN0eWxlLW5h
bWU6IlNwcmVjaGJsYXNlbnRleHQgWmNobiI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOlNwcmVjaGJsYXNlbnRleHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh
bnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5
O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46
NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX
b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp
Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0
Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv
eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxpbms9ImJsdWUiIHZs
aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+LTEgb24gdGhhdCB1c2VyIHByaXZhY3kgY2FuIHNpbXBseSB3YWl0IHVudGlsIHRoZSBX
RyBpcyBmb3JtZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu
NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw
Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKYW5hIEl5
ZW5nYXIgW21haWx0bzpqcmlAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXks
IE1heSAyMywgMjAxNiAxMDozNiBQTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsIChO
b2tpYSAtIERFKTxicj4NCjxiPkNjOjwvYj4gUnlhbiBIYW1pbHRvbjsgcXVpY0BpZXRmLm9yZzxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1FVSUNdIFFVSUMgcHJpdmFjeSBpbXBhY3Q8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklm
IHlvdXIgcG9pbnQgaXMgdGhhdCB0aGVyZSBzaG91bGQgYmUgYSBTZWN1cml0eSBDb25zaWRlcmF0
aW9ucyBzZWN0aW9uIGluIHRoZSBRVUlDIHByb3RvY29sIGRyYWZ0LCBwb2ludCB0YWtlbiwgYW5k
IEkgYWdyZWUgdGhhdCB0aGVyZSBzaG91bGQgYmUgb25lIHRoYXQgZGlzY3Vzc2VzIHByaXZhY3kg
Y29uc2lkZXJhdGlvbnMgYXMgd2VsbC4gSSB0aGluayBteSBvbmx5IGFyZ3VtZW50IGZvciBub3cg
aXMgdGhhdA0KIHRoaXMgZGlzY3Vzc2lvbiBjYW4gd2FpdCB1bnRpbCBhZnRlciB0aGUgd2cgaXMg
Zm9ybWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5BIGJpdCBtb3JlIGlubGluZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1heSAyMywgMjAxNiBhdCAxMjoxNiBQTSwgU2No
YXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pY2hhZWwuc2No
YXJmQG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pY2hhZWwuc2NoYXJmQG5va2lhLmNvbTwv
YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SSBhbSBjZXJ0YWlubHkgbm90IGNvbmNlcm5lZCBhYm91dCDigJxzdHVwaWTigJ0g
aW1wbGVtZW50YXRpb25zLiBJIGFtIGNvbmNlcm5lZCBhYm91dCBpbXBsZW1lbnRhdGlvbnMNCiB0
aGF0IHVuZGVyc3RhbmQgaG93IHRvIOKAnGludGVsbGlnZW50bHnigJ0gbGV2ZXJhZ2UgdGhpcyBp
ZGVudGlmaWVyIGFuZCB0aGlzIGlzIHRoZSB0eXBlIG9mIGFuYWx5c2lzIEkgZXhwZWN0IGluIGEg
Y29tcHJlaGVuc2l2ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24uIFNvbWUgb2YgdGhl
IG1hbGljaW91cyB1c2UgaWYgdGhpcyBJRCBtYXkgcGVyaGFwcyBiZSBjbGFzc2lmaWVkIGJ5IGFz
IGFuIGFjdGl2ZSBhdHRhY2sgb24gdXNlciBwcml2YWN5DQogYnV0IHN0aWxsIHRoZSBhdHRhY2sg
dmVjdG9yIHNlZW1zIHRvIG1lIHF1aXRlIGRpZmZlcmVudCB0byB3aGF0IGFuIGF0dGFja2VyIGNh
biBkbyB3aXRoIHNpbWlsYXIgbWVhbnMgd2l0aCBUQ1AuDQo8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkF0IGZpcnN0IHNpZ2h0IEkgc2VlIHF1aXRlIGEgbnVtYmVyIG9m
IGFkZGl0aW9uYWwgcHJvYmxlbXMgY29tcGFyZWQgdG8gdGhlIFRDUCBJU046PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBUQ1Agc3RhY2tzIGRvIG5v
dCBvZmZlciBhbiBBUEkgZm9yIHNldHRpbmcgdGhlIElTTiwgbW9kaWZpY2F0aW9uIG9mIHRoZSBU
Q1AgSVNOIHdvdWxkIHJlcXVpcmUgYSBrZXJuZWwgcGF0Y2gsIGFkbWluaXN0cmF0b3IgcmlnaHRz
LCBldGMuIFRoZSBiYXJyaWVyIGZvciB0aGF0DQogaXMgaGlnaC4gVGhlIGRlcGxveW1lbnQgbW9k
ZWwgb2YgYSB1c2VyIHNwYWNlIFVEUCBwcm90b2NvbCBzdGFjayBzZWVtcyBkaWZmZXJlbnQgdG8g
dGhhdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRvIGJlIGNsZWFyLCB3ZSBkb24ndCByZWx5IG9uIFRDUCBmb3IgcHJp
dmFjeSBhbmQgc2VjdXJpdHkgcHJvcGVydGllcywgd2UgcmVseSBvbiBUTFMgZm9yIHRoZXNlIHRo
aW5ncy4gTW9zdCBUTFMgaW1wbGVtZW50YXRpb25zIGxpdmUgaW4gdXNlcnNwYWNlLCBvZnRlbiBp
bnNpZGUgYXBwbGljYXRpb25zLiBJIHRoaW5rIHlvdSdkIGFncmVlIHRoYXQgaXQncyB0ZW51b3Vz
IGF0IGJlc3QgdG8gYXJndWUgdGhhdCBhDQogdXNlcnNwYWNlIHRyYW5zcG9ydCBpcyBhbnkgbW9y
ZSB2dWxuZXJhYmxlIHRoYW4gVExTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk
aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i
Pg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPsK3PC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIFRDUCBJ
U04gd2lsbCBub3QgYmUgY29udmV5ZWQgb3ZlciBUQ1AvSFRUUCBwcm94aWVzIGFuZCB0aGVyZSBh
cmUgZmlyZXdhbGxzIHRoYXQgcmFuZG9taXplIHRoZSBJU04uIFNvLCB1c2luZyB0aGUgVENQIElT
TiBhcyBhIGNvdmVydCBjaGFubmVsIG9yIOKAnGNsZWFyIHRleHQNCiBzdXBlciBjb29raWXigJ0g
d291bGQgbm90IHdvcmsgaW4gbWFueSBlbnZpcm9ubWVudHM8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj
bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2
Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj7Ctzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBJU04gb25seSBhcHBsaWVzIHRv
IHRoZSBTWU4gYW5kIG5vdCB0byBldmVyeSBwYWNrZXQsIHNvIGF0IGxlYXN0IG1vbml0b3Jpbmcg
b2YgdGhlIElTTiBieSBhIHBhc3NpdmUgYXR0YWNrIHNlZW1zIG1vcmUgZGlmZmljdWx0PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj7Ctzwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGFy
ZSBvbmx5IDMyIGJpdHMgKHBvc3NpYmx5IHNvbWUgbW9yZSB3aGVuIHVzaW5nIG90aGVyIGhlYWRl
ciBmaWVsZHMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj7C
tzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjoj
MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN
Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkkgZmFpbCB0byB1bmRlcnN0YW5kIGhvdyBhIHBhc3NpdmUgYXR0YWNrZXIgY2FuIHVz
ZSB0aGUgSVNOIHBhc3NpdmVseSBmb3IgdXNlciBsb2NhdGlvbiB0cmFja2luZyBldGMuPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyB0cnlpbmcgdG8gcG9pbnQgb3V0IHRoYXQgdGhlcmUg
YXJlIGNsZWFydGV4dCBmaWVsZHMgaW4gVENQLCBhbmQgYXJlIHZpc2libGUgdG8gYSBwYXNzaXZl
IGF0dGFja2VyLCBqdXN0IGFzIHRoZSBjb25uZWN0aW9uIElEIGlzIGluIFFVSUMuIEkgZG9uJ3Qg
d2FudCB0byBhcmd1ZSB0aGVzZSBzcGVjaWZpYyBwb2ludHMgc2luY2UgSSBkb24ndCB3YW50IHVz
IHRvIGdvIGFzdHJheSBmcm9tIHRoZSBjb3JlDQogcG9pbnQgYmVsb3c6PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkFueXdheSwgSSBiZWxpZXZlIHRoYXQgdGhlIFFVSUMgY29ubmVjdGlvbiBJRCBoYXMgdG8g
YmUgY2FyZWZ1bGx5IHJldmlld2VkIGJ5IGJldHRlcg0KIHNlY3VyaXR5IGV4cGVydHMgdGhhbiBt
ZSwgc28gSSBhbSBjZXJ0YWlubHkgd2lsbGluZyB0byBsZWFybiBpZiBJIG1pc3Mgc29tZXRoaW5n
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BYnNvbHV0ZWx5LCBJIGFncmVlLiBJIGV4cGVj
dCB0aGF0IGl0IHdpbGwgYmUgcmV2aWV3ZWQgYnkgc2VjdXJpdHkgZXhwZXJ0cyBpbiB0aGUgd2cu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g
amFuYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g
Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5NaWNoYWVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+IEphbmEgSXllbmdhciBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqcmlAZ29v
Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpyaUBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNl
bnQ6PC9iPiBNb25kYXksIE1heSAyMywgMjAxNiA4OjAyIFBNPGJyPg0KPGI+VG86PC9iPiBTY2hh
cmYsIE1pY2hhZWwgKE5va2lhIC0gREUpPGJyPg0KPGI+Q2M6PC9iPiBSeWFuIEhhbWlsdG9uOyA8
YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5v
cmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtRVUlDXSBRVUlDIHByaXZhY3kgaW1w
YWN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU3VuLCBNYXkgMjIs
IDIwMTYgYXQgMTA6MzIgQU0sIFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgJmx0OzxhIGhy
ZWY9Im1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj5taWNo
YWVsLnNjaGFyZkBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmRyYWZ0LXRzdndnLXF1aWMtcHJvdG9jb2wt
MDIgc2F5czoNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7UVVJQyBjb25uZWN0aW9ucyBhcmUgaWRlbnRp
ZmllZCBieSBhIDY0LWJpdCBDb25uZWN0aW9uIElELCByYW5kb21seTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDsmbmJzcDsgZ2VuZXJhdGVkIGJ5IHRoZSBjbGllbnQuJm5ic3A7IFFVSUMgY2FuIHN1cnZpdmUg
SVAgYWRkcmVzcyBjaGFuZ2VzIGFuZCBOQVQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHJlLWJp
bmRpbmdzIHNpbmNlIHRoZSBDb25uZWN0aW9uIElEIHJlbWFpbnMgdGhlIHNhbWUgYWNyb3NzIHRo
ZXNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5taWdyYXRpb25z
LiA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5T
bywgY2FuIHdlIGFncmVlIHRoYXQgdGhpcyBzdGF0ZW1lbnQgaXMgdmVyeSwgdmVyeSB2YWd1ZT88
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBpbnN0YW5jZSwgY291
bGQgSSB3cml0ZSBhIFFVSUMgaW1wbGVtZW50YXRpb24gY29tcGxpYW50IHRvIGRyYWZ0LXRzdndn
LXF1aWMtcHJvdG9jb2wtMDINCiB0aGF0IGUuZy4gdXNlcyBhIHN0YXRpYyBhbmQgYSByYW5kb20g
cGFydCBvZiB0aGUgY29ubmVjdGlvbiBJRCwgYW5kIGUuZy4gc3RvcmVzIHRoZSBzdGF0aWMgcGFy
dCBwZXJtYW5lbnRseSBvbiB0aGUgdXNlcuKAmXMgY29tcHV0ZXI/IE9yLCBjb3VsZCBJIHBpY2sg
YXMgYSBzdGF0aWMgcGFydCB0aGUgTUFDIGFkZHJlc3M/IFRoZSB0b3RhbCBJRCB3b3VsZCBzdGls
bCBiZSByYW5kb20uIEkgaGF2ZSBkaWZmaWN1bHRpZXMgdG8gdW5kZXJzdGFuZCBob3cNCiB0aGlz
IHNvcnQgb2YgSUQgZ2VuZXJhdGlvbiB3b3VsZCBiZSBkaWZmZXJlbnQgZnJvbSBhIOKAnGNsZWFy
IHRleHQgc3VwZXIgY29va2ll4oCdIGFuZCB3aGF0IGlzIGRlZmluZWQgaW4gdGhlIHJlZmVyZW5j
ZSB5b3UgcHJvdmlkZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg
YW0gc3VyZSB0aGF0IHRoaXMgaXMgbm90IHdoYXQgdGhlIGN1cnJlbnQgUVVJQyBpbXBsZW1lbnRh
dGlvbiBkb2VzLiBCdXQgc2luY2Ugd2UgYXJlDQogaW4gSUVURiBjb250ZXh0LCB0YWxraW5nIGFi
b3V0IGEgcG90ZW50aWFsIHN0YW5kYXJkLCBJIGFtIGNvbmNlcm5lZCB3aGF0IG90aGVyIGltcGxl
bWVudGVycyBvZiBhIG5ldyBwcm90b2NvbCBjb3VsZCBkbywgYW5kIHdoYXQgdXNlIGNhc2VzIHRo
ZXkgY291bGQgZmluZCBmb3IgdGhpcyBJRC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPkFuZCBpZiB0aGVyZSB3YXMgc29tZSBpbnRlcmVzdGluZyB1c2Ugb2YgaGF2aW5n
IGFuIGVudGlyZWx5IHVzZXItZGVmaW5lZCBjbGVhciB0ZXh0DQogdmFsdWUgYXQgc29tZSBjb25z
dGFudCBvZmZzZXQgaW4gdGhlIHBhY2tldCwgZm9yIGEgd2lkZWx5IHVzZWQgSW50ZXJuZXQgdHJh
bnNwb3J0IHByb3RvY29sLCBJIGFtIHByZXR0eSBzdXJlIHNvbWUgaW1wbGVtZW50ZXJzIHdvdWxk
IG5vdCBjYXJlIGFib3V0IHNvbWUgTVVTVHMgaW4gYW4gUkZDIHNheWluZyDigJxwbGVhc2UsIHBs
ZWFzZSwgcGxlYXNlIHNlbGVjdCBldmVyeSBiaXQgaW4gdGhlIElEIHJhbmRvbWx54oCdLg0KPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PciBkbyBJIG1pc3Mgc29tZXRo
aW5nIG9idmlvdXM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMuIFRoZSBmYWN0IHRoYXQgeW91IGNhbid0
IGtlZXAgc3R1cGlkIGltcGxlbWVudGF0aW9ucyBmcm9tIGh1cnRpbmcgdXNlciBwcml2YWN5LiBU
aGUgVENQIElTTiBpcyB1bnNwZWNpZmllZCwgYW5kIGl0IGNhbiBhbHdheXMgYmUgdXNlZCBmb3Ig
cGFja2luZyB3aGF0ZXZlciB1c2VyLXByaXZhY3ktcmV2ZWFsaW5nDQogaW5mb3JtYXRpb24geW91
IHdhbnQuIFRoYXQgd291bGQgYmUgdmVyeSB2ZXJ5IGR1bWIsIGJ1dCBpdCdzIG5vdCBvdXQgb2Yg
c3BlYyBmb3IgVENQLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+SSdsbCBhZ3JlZSB0aGF0IHdlIGNhbiBhbmQgc2hvdWxkIGhhdmUgdGV4
dCBpbiB0aGUgc3BlYyB0aGF0IHNheXMgaW1wbGVtZW50YXRpb25zIFNIT1VMRCBub3QgZG8gc3R1
cGlkIHRoaW5ncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPi0gamFuYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk
ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5NaWNoYWVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7
cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw
Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmFuYSBJeWVu
Z2FyIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmpyaUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu
ayI+anJpQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWF5IDIy
LCAyMDE2IDU6MjAgQU08YnI+DQo8Yj5Ubzo8L2I+IFJ5YW4gSGFtaWx0b248YnI+DQo8Yj5DYzo8
L2I+IDxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0Bp
ZXRmLm9yZzwvYT47IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IFtRVUlDXSBRVUlDIHByaXZhY3kgaW1wYWN0PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv
bG9yOiM4ODg4ODgiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+TWljaGFl
bCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+SnVzdCBjYXVnaHQgdXAgb24gdGhlIFNQVUQgdGhyZWFkLCBhbmQg
SSdkIGxpa2UgdG8gY29ycmVjdCBzb21ldGhpbmcgeW91IHNhaWQgdGhlcmUgdGhhdCBJJ2xsIHF1
b3RlIGhlcmUgZm9yIGNvbnRleHQ6Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48aT4mcXVvdDtpZiB0aGVyZSBpcyBub3cgYSBuZXcgY2xlYXIgdGV4
dCBpZGVudGlmaWVyIHRoYXQganVzdCBoYXBwZW5zIHRvIGJlIHVuaXF1ZSBwZXIgc3Vic2NyaWJl
ci4gV2hhdCBhIGdyZWF0IGltcHJvdmVtZW50IGZvciBwcml2YWN5IGluIHRoZSBJbnRlcm5ldCEg
QW5kIGV2ZW4gYmV0dGVyIHRoYXQgaXQgc2VlbXMNCiBjb21wYXRpYmxlIHdpdGggUVVJQy4uLiZx
dW90OzwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPlFVSUMncyBjb25uZWN0aW9uIElEIGlzIE5PVCB1bmlxdWUgcGVyIHN1YnNjcmli
ZXIuIEl0J3MgcGVyIGNvbm5lY3Rpb24uIEFzIEkgc2FpZCBvbiB0aGUgb3RoZXIgdGhyZWFkLCBp
biB0aGUgc2luZ2xlLXBhdGggY2FzZSwgaXQgcmV2ZWFscyBubyBtb3JlIGluZm9ybXRpb24gdGhh
biBUQ1AuIEluIHRoZSBtdWx0aXBhdGgNCiBjYXNlLCBpdCBlZmZlY3RpdmVseSByZXZlYWxzIG5v
IG1vcmUgdGhhbiBNUFRDUCwgc2luY2UgdGhlIElEIGlzIHVzZWQgdG8gdGllIHRoZSBtdWx0aXBs
ZSwgdXNpbmcgTVBUQ1AgcGFybGFuY2UsJm5ic3A7JnF1b3Q7c3ViLWZsb3dzJnF1b3Q7LCB0b2dl
dGhlci4gSXQgaXMgcG9zc2libGUgdG8gY29uc2lkZXIgYSBkaWZmZXJlbnQgZGVzaWduIHRoYXQg
dXNlcyBtdWx0aXBsZSBjb25uZWN0aW9uIElEcyBmb3IgdGhlIG11bHRpcGxlIHN1Yi1mbG93cywg
YnV0IHRvIGJlIGNsZWFyLA0KIHRoYXQgbWFrZXMgdGhpcyBuZXcgbXVsdGlwYXRoIHN0cmljdGx5
IGJldHRlciB0aGFuIE1QVENQJm5ic3A7YXQgcHJpdmFjeS1wcmVzZXJ2YXRpb24uPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BdCBhbnkg
cmF0ZSwgSSB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoYXQgd2UncmUgdGFsa2luZyBhYm91dCB0aGUg
c2FtZSBpc3N1ZS4gSSdsbCBhbHNvIG5vdGUgdGhhdCBpdCdzIHBsYWluIHdyb25nIHRvIHVzZSB0
aGUgdGVybSAmcXVvdDtjbGVhciB0ZXh0IHN1cGVyIGNvb2tpZSZxdW90OyBpbiByZWxhdGlvbiB0
byB0aGUgUVVJQw0KIGNvbm5lY3Rpb24gSUQgKHNlZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3
LnRlY2hvcGVkaWEuY29tL2RlZmluaXRpb24vMjczMTAvc3VwZXItY29va2llIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly93d3cudGVjaG9wZWRpYS5jb20vZGVmaW5pdGlvbi8yNzMxMC9zdXBlci1j
b29raWU8L2E+Jm5ic3A7Zm9yIHdoYXQgSSB0aGluayBhIHN1cGVyY29va2llIGlzLik8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gamFu
YTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU2F0LCBNYXkgMjEsIDIwMTYgYXQg
OTowNCBBTSwgSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20i
IHRhcmdldD0iX2JsYW5rIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPHA+VGhhdCdzIGEgZGVzaWduIGVsZW1lbnQgdGhhdCBzaG91bGQgYW5kIHdpbGwgZGVm
aW5pdGVseSBiZSBkaXNjdXNzZWQgaW4gdGhlIFdHLjxvOnA+PC9vOnA+PC9wPg0KPHA+U3BlY2lm
aWNhbGx5IHRoaXMgYXBwbGllcyB0byB1c2Ugb2YgY29ubmVjdGlvbiBJRHMgZHVyaW5nIG11bHRp
cGF0aCwgYW5kIEkgZXhwZWN0IHRoYXQgY29udmVyc2F0aW9uIHRvIGhhcHBlbiB3aGVuIHdlIGRp
c2N1c3MgbXVsdGlwYXRoLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5PbiBNYXkgMjEsIDIwMTYgNjo1NiBBTSwgJnF1b3Q7UnlhbiBI
YW1pbHRvbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJjaEBnb29nbGUuY29tIiB0YXJnZXQ9
Il9ibGFuayI+cmNoQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlZmlu
aXRlbHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+T24gRnJpLCBNYXkgMjAsIDIwMTYgYXQgMTE6MjYgUE0sIFNjaGFyZiwg
TWljaGFlbCAoTm9raWEgLSBERSkgJmx0OzxhIGhyZWY9Im1haWx0bzptaWNoYWVsLnNjaGFyZkBu
b2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj5taWNoYWVsLnNjaGFyZkBub2tpYS5jb208L2E+Jmd0
OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPklzIGl0IHBsYW5uZWQgdG8gZGlzY3VzcyBwb3RlbnRpYWwgcHJpdmFjeSBpbXBsaWNhdGlv
bnMgb2YgdGhlIOKAnlFVSUMgY29ubmVjdGlvbiBpZGVudGlmaWVy4oCcDQogKGFsc28gbmFtZWQg
4oCcY2xlYXIgdGV4dCBzdXBlciBjb29raWXigJ0gb24gdGhlIFNQVUQgbGlzdCk/PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj
bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0
bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0
Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FWFQgVGVkIEhhcmRpZTxicj4NCjxiPlNl
bnQ6PC9iPiBTYXR1cmRheSwgTWF5IDE0LCAyMDE2IDE6MjcgQU08YnI+DQo8Yj5Ubzo8L2I+IDxh
IGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9y
ZzwvYT47IEphbmEgSXllbmdhcjsgQ2hyaXN0aWFuIEh1aXRlbWE8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gW1FVSUNdIERyYWZ0IGNoYXJ0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5Ib3dkeSw8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5BcyBwYXJ0IG9mIHRoZSBCb0Yg
cHJlcGFyYXRpb24sIHdlIHB1dCB0b2dldGhlciBhIHN0YWIgYXQgYSBkcmFmdCBjaGFydGVyLiZu
YnNwOyBJdCdzIGF2YWlsYWJsZSBhcyBodG1sIGFuZCBtYXJrZG93biBvbiBnaXRodWIgYXQ6PGJy
Pg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL0lFVEYtUVVJQy9DaGFydGVyIiB0
YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL0lFVEYtUVVJQy9DaGFydGVyPC9hPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkkndmUgYXR0YWNoZWQgdGhl
IEhUTUwgdmVyc2lvbiBhcyB3ZWxsLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IHdvdWxkIGJlIGdyZWF0IHRvIGhhdmUgc29t
ZSBvZiB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBiZWZvcmUgdGhlIEJvRi4mbmJzcDsgQ29t
bWVudHMgdG8gdGhlIGxpc3Qgb3IgaXNzdWVzL3B1bGwgcmVxdWVzdHMgYXQgdGhlIGdpdGh1YiBy
ZXBvIGFyZSB3ZWxjb21lLiZuYnNwOyBXZSB3aWxsIHBlcmlvZGljYWxseQ0KIHJlZmxlY3QgYW55
IGlzc3VlcyBvciBzdWdnZXN0aW9uIGZyb20gdGhlIFJlcG8gYmFjayB0byB0aGUgbGlzdCwgYnV0
IHRoaXMgd2lsbCBiZSBtYW51YWwsIHNvIGV4cGVjdCBzb21lIGxhZy48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClFVSUMgbWFpbGluZyBs
aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlFVSUNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5R
VUlDQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vcXVpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vcXVpYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu
MHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NClFVSUMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlFVSUNAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5RVUlDQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcXVpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcXVpYzwvYT48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_655C07320163294895BBADA28372AF5D4886662CFR712WXCHMBA15z_--


From nobody Mon May 23 14:32:06 2016
Return-Path: 
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 7F71912DBF2 for ; Mon, 23 May 2016 14:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ABWn5ZeRjEdn for ; Mon, 23 May 2016 14:32:02 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 D190F12D52A for ; Mon, 23 May 2016 14:31:58 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id o16so66240851ywd.2 for ; Mon, 23 May 2016 14:31:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o88uX1eeYyDk+ZzP1PqfAS1iwTfybF//sAQUWiEzILI=; b=NTLFgxX+1/T1CA/+fLpXdyECTxtHvZWX1FAe2lhBJ1H+nK7HNWi6uNDzBPusDfFtuM nL4sueRu+Nrn/g0k79FdPpmEGrw8TIDw1HkAt6e2wdUMyoWY/xYrGhm1ScRwhVvwdBuw /Vysz2bfwrNbDxSrwlr2/qLtNEonQ6+dTcrZatyY6QjkmKmGn111shtBe1cbwOmzS/pc F7Yw+XL6Nd1KQTW7GWbFWgIKz5iwaa90qosqIMh9kBF4jLSfAcEGctrobL+lKx2REmAv t7WxvbHjU781U7UxTIJVm3+1pBqTJ6v69kFDu9Qdnnre0hDmVIqKuk4l7UB2EJz1hDLs LPSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o88uX1eeYyDk+ZzP1PqfAS1iwTfybF//sAQUWiEzILI=; b=LQB5wJB/J/N6oJVO/5A1cV1T1UeBXazDEA6ZaPtB89BFp6GdtFkdExgwPfxTJ9YSLB bEXbiMQJX25n6PtyIjZl8qnezPXxOk/68tmw4iwHZumUBxs3Mv2cal3I/NHm2sj0QJLO bIx4FrhRygKf3j333S3NRyjbZM4k0l1sXN1DERVEdUfhU9hKlzUmgTaY7cN+rHayDMxv lExj/2PyJUSgr9MXOWkEYE1l0R1SYS2PXPRnmiNT667zn9LUKkqXNrQO3DTv9LWkkwlc ZjJ4Dst05VjFdh2v9QJ98VJRCI05MnxmNjwSy86ANjr1NcH7E5SlVfQDg74HDx2CAbAw efdw==
X-Gm-Message-State: ALyK8tJlJGUt8jFPbircu5j5onAByArVnG71b1LMABOIIp+NRx7pUSaSKlFRP4Vwlky9HX0OcLSaJJgSqZI6eAZC
X-Received: by 10.13.237.1 with SMTP id w1mr603751ywe.62.1464039117872; Mon, 23 May 2016 14:31:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 14:31:56 -0700 (PDT)
In-Reply-To: <655C07320163294895BBADA28372AF5D4886662C@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D48863C11@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D4886662C@FR712WXCHMBA15.zeu.alcatel-lucent.com>
From: Jana Iyengar 
Date: Mon, 23 May 2016 14:31:56 -0700
Message-ID: 
To: "Scharf, Michael (Nokia - DE)" 
Content-Type: multipart/alternative; boundary=94eb2c0864a88f91f80533892bcb
Archived-At: 
Cc: "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 21:32:04 -0000

--94eb2c0864a88f91f80533892bcb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, May 23, 2016 at 2:14 PM, Scharf, Michael (Nokia - DE) <
michael.scharf@nokia.com> wrote:

> -1 on that user privacy can simply wait until the WG is formed
>

I may have missed it -- can you state the privacy concern precisely? I'm
happy to discuss a specific concern that you think needs to be addressed
before the BoF.

- jana

Michael
>
>
>
>
>
> *From:* Jana Iyengar [mailto:jri@google.com]
> *Sent:* Monday, May 23, 2016 10:36 PM
>
> *To:* Scharf, Michael (Nokia - DE)
> *Cc:* Ryan Hamilton; quic@ietf.org
> *Subject:* Re: [QUIC] QUIC privacy impact
>
>
>
> If your point is that there should be a Security Considerations section i=
n
> the QUIC protocol draft, point taken, and I agree that there should be on=
e
> that discusses privacy considerations as well. I think my only argument f=
or
> now is that this discussion can wait until after the wg is formed.
>
>
>
> A bit more inline:
>
>
>
> On Mon, May 23, 2016 at 12:16 PM, Scharf, Michael (Nokia - DE) <
> michael.scharf@nokia.com> wrote:
>
> I am certainly not concerned about =E2=80=9Cstupid=E2=80=9D implementatio=
ns. I am
> concerned about implementations that understand how to =E2=80=9Cintellige=
ntly=E2=80=9D
> leverage this identifier and this is the type of analysis I expect in a
> comprehensive security consideration section. Some of the malicious use i=
f
> this ID may perhaps be classified by as an active attack on user privacy
> but still the attack vector seems to me quite different to what an attack=
er
> can do with similar means with TCP.
>
>
>
> At first sight I see quite a number of additional problems compared to th=
e
> TCP ISN:
>
>
>
> =C2=B7         As TCP stacks do not offer an API for setting the ISN,
> modification of the TCP ISN would require a kernel patch, administrator
> rights, etc. The barrier for that is high. The deployment model of a user
> space UDP protocol stack seems different to that.
>
> To be clear, we don't rely on TCP for privacy and security properties, we
> rely on TLS for these things. Most TLS implementations live in userspace,
> often inside applications. I think you'd agree that it's tenuous at best =
to
> argue that a userspace transport is any more vulnerable than TLS.
>
> =C2=B7         The TCP ISN will not be conveyed over TCP/HTTP proxies and
> there are firewalls that randomize the ISN. So, using the TCP ISN as a
> covert channel or =E2=80=9Cclear text super cookie=E2=80=9D would not wor=
k in many
> environments
>
> =C2=B7         The ISN only applies to the SYN and not to every packet, s=
o at
> least monitoring of the ISN by a passive attack seems more difficult
>
> =C2=B7         There are only 32 bits (possibly some more when using othe=
r
> header fields)
>
> =C2=B7         I fail to understand how a passive attacker can use the IS=
N
> passively for user location tracking etc.
>
> I was trying to point out that there are cleartext fields in TCP, and are
> visible to a passive attacker, just as the connection ID is in QUIC. I
> don't want to argue these specific points since I don't want us to go
> astray from the core point below:
>
>
>
> Anyway, I believe that the QUIC connection ID has to be carefully reviewe=
d
> by better security experts than me, so I am certainly willing to learn if=
 I
> miss something.
>
>
>
> Absolutely, I agree. I expect that it will be reviewed by security expert=
s
> in the wg.
>
>
>
> - jana
>
>
>
>
>
> Michael
>
>
>
>
>
> *From:* Jana Iyengar [mailto:jri@google.com]
> *Sent:* Monday, May 23, 2016 8:02 PM
> *To:* Scharf, Michael (Nokia - DE)
> *Cc:* Ryan Hamilton; quic@ietf.org
>
>
> *Subject:* Re: [QUIC] QUIC privacy impact
>
>
>
> On Sun, May 22, 2016 at 10:32 AM, Scharf, Michael (Nokia - DE) <
> michael.scharf@nokia.com> wrote:
>
> draft-tsvwg-quic-protocol-02 says:
>
>
>
>   QUIC connections are identified by a 64-bit Connection ID, randomly
>
>    generated by the client.  QUIC can survive IP address changes and NAT
>
>    re-bindings since the Connection ID remains the same across these
>
>    migrations.
>
>
>
> So, can we agree that this statement is very, very vague?
>
>
>
> For instance, could I write a QUIC implementation compliant to
> draft-tsvwg-quic-protocol-02 that e.g. uses a static and a random part of
> the connection ID, and e.g. stores the static part permanently on the
> user=E2=80=99s computer? Or, could I pick as a static part the MAC addres=
s? The
> total ID would still be random. I have difficulties to understand how thi=
s
> sort of ID generation would be different from a =E2=80=9Cclear text super=
 cookie=E2=80=9D
> and what is defined in the reference you provide.
>
>
>
> I am sure that this is not what the current QUIC implementation does. But
> since we are in IETF context, talking about a potential standard, I am
> concerned what other implementers of a new protocol could do, and what us=
e
> cases they could find for this ID.
>
>
>
> And if there was some interesting use of having an entirely user-defined
> clear text value at some constant offset in the packet, for a widely used
> Internet transport protocol, I am pretty sure some implementers would not
> care about some MUSTs in an RFC saying =E2=80=9Cplease, please, please se=
lect every
> bit in the ID randomly=E2=80=9D.
>
>
>
> Or do I miss something obvious?
>
>
>
> Yes. The fact that you can't keep stupid implementations from hurting use=
r
> privacy. The TCP ISN is unspecified, and it can always be used for packin=
g
> whatever user-privacy-revealing information you want. That would be very
> very dumb, but it's not out of spec for TCP.
>
>
>
> I'll agree that we can and should have text in the spec that says
> implementations SHOULD not do stupid things.
>
>
>
> - jana
>
>
>
>
>
> Michael
>
>
>
>
>
>
>
>
>
> *From:* Jana Iyengar [mailto:jri@google.com]
> *Sent:* Sunday, May 22, 2016 5:20 AM
> *To:* Ryan Hamilton
> *Cc:* quic@ietf.org; Scharf, Michael (Nokia - DE)
> *Subject:* Re: [QUIC] QUIC privacy impact
>
>
>
> Michael,
>
>
>
> Just caught up on the SPUD thread, and I'd like to correct something you
> said there that I'll quote here for context:
>
> *"if there is now a new clear text identifier that just happens to be
> unique per subscriber. What a great improvement for privacy in the
> Internet! And even better that it seems compatible with QUIC..."*
>
>
>
> QUIC's connection ID is NOT unique per subscriber. It's per connection. A=
s
> I said on the other thread, in the single-path case, it reveals no more
> informtion than TCP. In the multipath case, it effectively reveals no mor=
e
> than MPTCP, since the ID is used to tie the multiple, using MPTCP
> parlance, "sub-flows", together. It is possible to consider a different
> design that uses multiple connection IDs for the multiple sub-flows, but =
to
> be clear, that makes this new multipath strictly better than MPTCP at
> privacy-preservation.
>
>
>
> At any rate, I wanted to make sure that we're talking about the same
> issue. I'll also note that it's plain wrong to use the term "clear text
> super cookie" in relation to the QUIC connection ID (see
> https://www.techopedia.com/definition/27310/super-cookie for what I think
> a supercookie is.)
>
>
>
> - jana
>
>
>
> On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar  wrote:
>
> That's a design element that should and will definitely be discussed in
> the WG.
>
> Specifically this applies to use of connection IDs during multipath, and =
I
> expect that conversation to happen when we discuss multipath.
>
> On May 21, 2016 6:56 AM, "Ryan Hamilton"  wrote:
>
> Definitely.
>
>
>
> On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) <
> michael.scharf@nokia.com> wrote:
>
> Is it planned to discuss potential privacy implications of the =E2=80=9EQ=
UIC
> connection identifier=E2=80=9C (also named =E2=80=9Cclear text super cook=
ie=E2=80=9D on the SPUD
> list)?
>
>
>
> Thanks
>
>
>
> Michael
>
>
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *EXT Ted Hardie
> *Sent:* Saturday, May 14, 2016 1:27 AM
> *To:* quic@ietf.org; Jana Iyengar; Christian Huitema
> *Subject:* [QUIC] Draft charter
>
>
>
> Howdy,
>
> As part of the BoF preparation, we put together a stab at a draft
> charter.  It's available as html and markdown on github at:
>
> https://github.com/IETF-QUIC/Charter
>
> I've attached the HTML version as well.
>
> It would be great to have some of the discussion on the list before the
> BoF.  Comments to the list or issues/pull requests at the github repo are
> welcome.  We will periodically reflect any issues or suggestion from the
> Repo back to the list, but this will be manual, so expect some lag.
>
>
>
> regards,
>
> Ted
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>
>
>
>
>
>

--94eb2c0864a88f91f80533892bcb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 23, 2016 at 2:14 PM, Scharf, Michael (Nokia - DE) <michael.=
scharf@nokia.com> wrote:











-1 on that=
 user privacy can simply wait until the WG is formed
=

=C2=A0
I may have missed it -- can you state th=
e privacy concern precisely? I'm happy to discuss a specific concern th=
at you think needs to be addressed before the BoF.

- jana



Michael=



=C2=
=A0


=C2=
=A0








From: Jana Iye=
ngar [mailto:jri@google=
.com]


Sent: Monday, May 23, 2016 10:36 PM


To: Scharf, Michael (Nokia - DE)

Cc: Ryan Hamilton; quic@ietf.org

Subject: Re: [QUIC] QUIC privacy impact
=







=C2=A0






If your point is that there should be a Security Con=
siderations section in the QUIC protocol draft, point taken, and I agree th=
at there should be one that discusses privacy considerations as well. I thi=
nk my only argument for now is that
 this discussion can wait until after the wg is formed.






=C2=A0






A bit more inline:








=C2=A0




On Mon, May 23, 2016 at 12:16 PM, Scharf, Michael (N=
okia - DE) <michael.scharf@nokia.com> wrote:






I am certa=
inly not concerned about =E2=80=9Cstupid=E2=80=9D implementations. I am con=
cerned about implementations
 that understand how to =E2=80=9Cintelligently=E2=80=9D leverage this ident=
ifier and this is the type of analysis I expect in a comprehensive security=
 consideration section. Some of the malicious use if this ID may perhaps be=
 classified by as an active attack on user privacy
 but still the attack vector seems to me quite different to what an attacke=
r can do with similar means with TCP.



=C2=A0


At first s=
ight I see quite a number of additional problems compared to the TCP ISN:


=C2=A0


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
As TCP stacks do not offer=
 an API for setting the ISN, modification of the TCP ISN would require a ke=
rnel patch, administrator rights, etc. The barrier for that
 is high. The deployment model of a user space UDP protocol stack seems dif=
ferent to that.








To be clear, we don't rely on TCP for privacy an=
d security properties, we rely on TLS for these things. Most TLS implementa=
tions live in userspace, often inside applications. I think you'd agree=
 that it's tenuous at best to argue that a
 userspace transport is any more vulnerable than TLS.










=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
The TCP ISN will not be co=
nveyed over TCP/HTTP proxies and there are firewalls that randomize the ISN=
. So, using the TCP ISN as a covert channel or =E2=80=9Cclear text
 super cookie=E2=80=9D would not work in many environments=















=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
The ISN only applies to th=
e SYN and not to every packet, so at least monitoring of the ISN by a passi=
ve attack seems more difficult


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
There are only 32 bits (po=
ssibly some more when using other header fields)


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
I fail to understand how a=
 passive attacker can use the ISN passively for user location tracking etc.=











I was trying to point out that there are cleartext f=
ields in TCP, and are visible to a passive attacker, just as the connection=
 ID is in QUIC. I don't want to argue these specific points since I don=
't want us to go astray from the core
 point below:






=C2=A0










Anyway, I =
believe that the QUIC connection ID has to be carefully reviewed by better
 security experts than me, so I am certainly willing to learn if I miss som=
ething.










=C2=A0






Absolutely, I agree. I expect that it will be review=
ed by security experts in the wg.






=C2=A0






- jana






=C2=A0










=C2=A0


Michael


=C2=A0


=C2=A0








From: Jana Iye=
ngar [mailto:jri@google=
.com]


Sent: Monday, May 23, 2016 8:02 PM

To: Scharf, Michael (Nokia - DE)

Cc: Ryan Hamilton; quic@ietf.org








Subject: Re: [QUIC] QUIC privacy impact














=C2=A0








On Sun, May 22, 2016 at 10:32 AM, Scharf, Michael (N=
okia - DE) <michael.scharf@nokia.com> wrote:






draft-tsvw=
g-quic-protocol-02 says:



=C2=A0


=C2=A0=C2=A0QUIC connections are identified=
 by a 64-bit Connection ID, randomly


=C2=A0=C2=A0 generated by the client.=C2=A0=
 QUIC can survive IP address changes and NAT


=C2=A0=C2=A0 re-bindings since the Connecti=
on ID remains the same across these


=C2=A0=C2=A0
migrations. 



=C2=A0


So, can we=
 agree that this statement is very, very vague?


=C2=A0


For instan=
ce, could I write a QUIC implementation compliant to draft-tsvwg-quic-proto=
col-02
 that e.g. uses a static and a random part of the connection ID, and e.g. s=
tores the static part permanently on the user=E2=80=99s computer? Or, could=
 I pick as a static part the MAC address? The total ID would still be rando=
m. I have difficulties to understand how
 this sort of ID generation would be different from a =E2=80=9Cclear text s=
uper cookie=E2=80=9D and what is defined in the reference you provide.


=C2=A0


I am sure =
that this is not what the current QUIC implementation does. But since we ar=
e
 in IETF context, talking about a potential standard, I am concerned what o=
ther implementers of a new protocol could do, and what use cases they could=
 find for this ID.


=C2=A0


And if the=
re was some interesting use of having an entirely user-defined clear text
 value at some constant offset in the packet, for a widely used Internet tr=
ansport protocol, I am pretty sure some implementers would not care about s=
ome MUSTs in an RFC saying =E2=80=9Cplease, please, please select every bit=
 in the ID randomly=E2=80=9D.



=C2=A0


Or do I mi=
ss something obvious?








=C2=A0






Yes. The fact that you can't keep stupid impleme=
ntations from hurting user privacy. The TCP ISN is unspecified, and it can =
always be used for packing whatever user-privacy-revealing
 information you want. That would be very very dumb, but it's not out o=
f spec for TCP.






=C2=A0






I'll agree that we can and should have text in t=
he spec that says implementations SHOULD not do stupid things.






=C2=A0






- jana






=C2=A0










=C2=A0


Michael


=C2=A0


=C2=A0


=C2=A0


=C2=A0








From: Jana Iye=
ngar [mailto:jri@google=
.com]


Sent: Sunday, May 22, 2016 5:20 AM

To: Ryan Hamilton

Cc: quic@ietf.org=
; Scharf, Michael (Nokia - DE)

Subject: Re: [QUIC] QUIC privacy impact






=C2=A0






Michael,=











=C2=A0




Just caught up on the SPUD thread, and I'd like =
to correct something you said there that I'll quote here for context:=
=C2=A0




"if there is now a new clear text identifier=
 that just happens to be unique per subscriber. What a great improvement fo=
r privacy in the Internet! And even better that it seems
 compatible with QUIC..."






=C2=A0






QUIC's connection ID is NOT unique per subscribe=
r. It's per connection. As I said on the other thread, in the single-pa=
th case, it reveals no more informtion than TCP. In the multipath
 case, it effectively reveals no more than MPTCP, since the ID is used to t=
ie the multiple, using MPTCP parlance,=C2=A0"sub-flows", together=
. It is possible to consider a different design that uses multiple connecti=
on IDs for the multiple sub-flows, but to be clear,
 that makes this new multipath strictly better than MPTCP=C2=A0at privacy-p=
reservation.






=C2=A0






At any rate, I wanted to make sure that we're ta=
lking about the same issue. I'll also note that it's plain wrong to=
 use the term "clear text super cookie" in relation to the QUIC
 connection ID (see=C2=A0https://www.techopedia.com/definition/=
27310/super-cookie=C2=A0for what I think a supercookie is.)






=C2=A0






- jana
















=C2=A0




On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar <jri@google.com> wr=
ote:


That's a design element that should and will definitely be discussed=
 in the WG.


Specifically this applies to use of connection IDs during multipath, and=
 I expect that conversation to happen when we discuss multipath.<=
/u>








On May 21, 2016 6:56 AM, "Ryan Hamilton" &=
lt;rch@google.com&g=
t; wrote:






Definitely.








=C2=A0




On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (N=
okia - DE) <michael.scharf@nokia.com> wrote:






Is it plan=
ned to discuss potential privacy implications of the =E2=80=9EQUIC connecti=
on identifier=E2=80=9C
 (also named =E2=80=9Cclear text super cookie=E2=80=9D on the SPUD list)?


=C2=A0


Thanks


=C2=A0


Michael


=C2=A0


=C2=A0








From: QUIC [ma=
ilto:quic-bounce=
s@ietf.org]
On Behalf Of EXT Ted Hardie

Sent: Saturday, May 14, 2016 1:27 AM

To: quic@ietf.org=
; Jana Iyengar; Christian Huitema

Subject: [QUIC] Draft charter






=C2=A0












Howdy,<=
/p>



As part of the BoF pr=
eparation, we put together a stab at a draft charter.=C2=A0 It's availa=
ble as html and markdown on github at:



https://=
github.com/IETF-QUIC/Charter




I've attached the=
 HTML version as well.=C2=A0







It would be great to have some of the discussion on =
the list before the BoF.=C2=A0 Comments to the list or issues/pull requests=
 at the github repo are welcome.=C2=A0 We will periodically
 reflect any issues or suggestion from the Repo back to the list, but this =
will be manual, so expect some lag.






=C2=A0




regards,




Ted












_______________________________________________

QUIC mailing list

QUIC@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/quic




=C2=A0






_______________________________________________

QUIC mailing list

QUIC@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/quic










=C2=A0


















=C2=A0




















=C2=A0


















--94eb2c0864a88f91f80533892bcb--


From nobody Mon May 23 14:34:53 2016
Return-Path: 
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 B13C712DBE6 for ; Mon, 23 May 2016 14:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.127
X-Spam-Level: 
X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 8TAwVZrxvVrg for ; Mon, 23 May 2016 14:34:51 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7752312D52A for ; Mon, 23 May 2016 14:34:51 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A0CF8423701; Mon, 23 May 2016 21:34:50 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 8515042373A; Mon, 23 May 2016 21:34:50 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1464039290; bh=h9M85U0o9FUdOclbD1uYyRu6LPdQLg/Hc/7w2htqNCY=; l=272; h=From:To:CC:Date:References:In-Reply-To:From; b=Ghr9PRj7Tz5tWgR4+F2nMqFx9V199oYi5gNCbwkkigO4v7dwithPYfF+U/gYBy8lG I9PuMORZ4/wUkPSVK4di6XXa1R1xyQosenH43Vh4JlduRoIJPvcuGeiMCcV8scjm/+ JIun7nfhjBd9R40j3cNbWaXKUoSImNoojTHvAmp0=
Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 816881FC94; Mon, 23 May 2016 21:34:50 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 23 May 2016 17:34:50 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Mon, 23 May 2016 17:34:50 -0400
From: "Salz, Rich" 
To: Jana Iyengar , "Scharf, Michael (Nokia - DE)" 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynMO1nsPb4wB0KSfckXTbaP25/DrbgAgAAj/QCAALzAAIAA7hoAgAGahwCAABTaAIAAFjqAgAAK0QCAAATOAP//vYAA
Date: Mon, 23 May 2016 21:34:49 +0000
Message-ID: <47cd7d685cf54acda0f867e9a9032a90@usma1ex-dag1mb1.msg.corp.akamai.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D48863C11@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D4886662C@FR712WXCHMBA15.zeu.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.45.190]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 21:34:53 -0000

Pi0xIG9uIHRoYXQgdXNlciBwcml2YWN5IGNhbiBzaW1wbHkgd2FpdCB1bnRpbCB0aGUgV0cgaXMg
Zm9ybWVkDQrCoA0KSSBhbSBjb25mdXNlZCBieSB0aGlzLiAgQSBXRyBnZXRzIGZvcm1lZCB0byBk
byB0aGluZ3MuICBTbyBwdXR0aW5nIHByaXZhY3kgaW4gdGhlIGNoYXJ0ZXIgc2hvdWxkIGJlIGFs
bCB0aGF0J3MgbmVlZGVkLCByaWdodD8NCg==


From nobody Mon May 23 15:08:17 2016
Return-Path: 
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 0505612D5D6 for ; Mon, 23 May 2016 15:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 wHdod35Rqrfz for ; Mon, 23 May 2016 15:08:15 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 88C7C12D5B6 for ; Mon, 23 May 2016 15:08:15 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id c127so67764982ywb.1 for ; Mon, 23 May 2016 15:08:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ljpUXPBd8FANbnV7etdZZcsEBBn4hUr8dMoPpn0Jk/8=; b=kYdrsgHR10aiiECFl45IXTS/Ht+BWBlqAeVd+ie96R5MyWR7nbY1zxBPISCmpbu6yf rFgAcWmiiOhMLSIAVfFyLh1L7VfxdG2AhyF1fxFCh08nQoFimPS3LEOQLUjrylrugCXr Fci8apui2PccjH0nBCqMTcFsHYeooalBLQyt/ZPswqi5lh0/CNpJWsYd7CDqaLSQz2AT TAh4Z2vqjcU1C39UY9C6WMDZ5BS+LAPbftazV21A4CcOjpAClRSY2mvfdTcWbBuhvKL0 /PNGAhKzRlHWxG0lb5XBEXuQp2JM+2K7EEJ+WLR86JVZL6WTTdbFRiVsh0JLMegrjwn8 b6Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ljpUXPBd8FANbnV7etdZZcsEBBn4hUr8dMoPpn0Jk/8=; b=XpSb/UTZpArjQJj/oTH4y4/h5YuNMrZJ8r9Uj5sBdkXZBVH/AjM6/eEXRH+UWa5Ysn u8FYModMaWGRw7kvzq1EfD/SW3RvXX7R3BcZTa7xipgq7vkllri4QGZJLHxBYWh9WQfC 9E1Ckoct+3ssF/3FLc71mFOdQQbAKc2nmLaH9QJihuVlhJwts98rIIhvyQYL5w/EAzPD KhWWxsdlPb0uDqjr4lFOe4XhgWz8IXjprGYlvXpckGNO879P54SrcibWMSKPOK1Ic6IR NiXlRt546wziRbZ6zg4LBHkegsco1lvWRgyt2DEuGBUTInBIUZSRCoVX3bddcK6wnux1 +DrQ==
X-Gm-Message-State: ALyK8tJrX+nkQsvIY5QcX1z9mK3HdBYa6tRdfohTB1uSG3S6lYfG+yaxH3TwfPQzuGCR27UU9q0qo0X78iNYbKph
X-Received: by 10.13.251.4 with SMTP id l4mr694518ywf.265.1464041294728; Mon, 23 May 2016 15:08:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 15:08:14 -0700 (PDT)
In-Reply-To: 
References:    <59f8ddb3-8cd3-6cbe-19c1-07c88264a8c8@tessares.net>  
From: Jana Iyengar 
Date: Mon, 23 May 2016 15:08:14 -0700
Message-ID: 
To: =?UTF-8?Q?G=C3=B6ran_Eriksson_AP?= 
Content-Type: multipart/alternative; boundary=94eb2c07e55c4f6f0f053389ad4f
Archived-At: 
Cc: Christian Huitema , Olivier Bonaventure , "quic@ietf.org" , Ted Hardie 
Subject: Re: [QUIC] Scope of multi-path WAS: Re: Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 May 2016 22:08:17 -0000

--94eb2c07e55c4f6f0f053389ad4f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

G=C3=B6ran,

I am adding text to the charter to say that both reliability (mobility) and
load sharing will be in scope for multipath. Path selection will probably
be left to implementations, just as it is in SCTP and MPTCP.

- jana

On Fri, May 20, 2016 at 4:34 PM, G=C3=B6ran Eriksson AP <
goran.ap.eriksson@ericsson.com> wrote:

>
>
> >I agree. At this point, it's not clear to me how useful a QUIC API doc
> >will be. We can certainly consider it later as more implementations
> >emerge.
>
> +1
>
> But perhaps you could elaborate a bit on the use of MPQUIC case/usages yo=
u
> are considering?
>
> Mobility? And if you foresee any case where the path selection will be
> done based on http layer input?
>
> Regards
> G=C3=B6ran
>
>

--94eb2c07e55c4f6f0f053389ad4f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


G=C3=B6ran,

I am adding text to the cha=
rter to say that both reliability (mobility) and load sharing will be in sc=
ope for multipath. Path selection will probably be left to implementations,=
 just as it is in SCTP and MPTCP.

- jana

On Fri, May 20,=
 2016 at 4:34 PM, G=C3=B6ran Eriksson AP <goran.ap.eriksson@e=
ricsson.com> wrote:




>I agree. At this point, it's not clear to me how useful a QUIC API =
doc

>will be. We can certainly consider it later as more implementations

>emerge.



+1



But perhaps you could elaborate a bit on the use of MPQUIC case/usages you<=
br>
are considering?



Mobility? And if you foresee any case where the path selection will be

done based on http layer input?



Regards

G=C3=B6ran







--94eb2c07e55c4f6f0f053389ad4f--


From nobody Mon May 23 18:26:53 2016
Return-Path: 
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 29BD712D53B for ; Mon, 23 May 2016 18:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 FLt8niDNaTBb for ; Mon, 23 May 2016 18:26:50 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D6312B03D for ; Mon, 23 May 2016 18:26:50 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D25CD22E1FA; Mon, 23 May 2016 21:26:47 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Tue, 24 May 2016 11:26:44 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>  
To: Ian Swett 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Ted Hardie , "Julian F. Reschke" , Cory Benfield , Jana Iyengar , Christian Huitema , quic@ietf.org
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 01:26:52 -0000

Hi Ian,

> On 24 May 2016, at 1:48 AM, Ian Swett  wrote:
>=20
> A very interesting question Mark.  A few thoughts.
>=20
> In regards to alt-svc, my thinking is that this would be h2-udp or =
something similar.  That assumes QUIC has no semantic changes to H2.
>=20
> If QUIC enables semantic changes to h2 that are valuable and are =
difficult or impossible with TCP, then this becomes a very challenging =
question indeed.  So far, the largest divergence we've considered from =
h2 in QUIC's mapping is the best way to map headers and still minimize =
HoL blocking.  But that doesn't change semantics.  Developers build =
applications with the tools presented to them, so lack of use is no =
indication that there aren't semantic changes of interest, but I'm not =
aware of any QUIC specific ones at the moment.
>=20
> If the concern is that there's interest in an h3, but little appetite =
to deploy h3 over TCP and h2-QUIC and h3-QUIC all in close time =
proximity, that's a fair concern.

That's a part of it, but mainly my concern is mostly that the decision =
is happening as a side effect of the start of QUIC work, rather than =
something explicitly made. I think it's easy enough to fix.

Cheers,


--
Mark Nottingham   https://www.mnot.net/


From nobody Mon May 23 18:28:02 2016
Return-Path: 
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 5188E12D53B for ; Mon, 23 May 2016 18:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 oHbLfabbH5lq for ; Mon, 23 May 2016 18:27:59 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB9512B03D for ; Mon, 23 May 2016 18:27:58 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C64BE22E255; Mon, 23 May 2016 21:27:55 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Tue, 24 May 2016 11:27:53 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <0AE43B24-8B4A-4F9C-AF93-F4222268E072@mnot.net>
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>        
To: Martin Thomson 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Ted Hardie , "Julian F. Reschke" , Ian Swett , Cory Benfield , Christian Huitema , Jana Iyengar , quic@ietf.org
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 01:28:00 -0000

> On 24 May 2016, at 6:27 AM, Martin Thomson  =
wrote:
>=20
> On 23 May 2016 at 16:03, Jana Iyengar  wrote:
>> By extension, HTTP/2 extensions will by default extend h2 and not =
h2q, and
>> may rely on TCP underneath. As a rule, I think we have to assume that
>> they'll need to explicitly map to QUIC.
>=20
> I think that this is the safest assumption.  Extensions for "h2" don't
> immediately port to "h2q".
>=20
> That said, we do have in order guarantees on both stream 3 and stream
> N, so maybe, just maybe, there is a simple set of guidelines we can
> produce that will be generally applicable to most, if not all,
> extensions.

+1. We should be looking at how we can minimise the differences wherever =
possible.

--
Mark Nottingham   https://www.mnot.net/


From nobody Mon May 23 18:31:05 2016
Return-Path: 
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 202EB12DBB4 for ; Mon, 23 May 2016 18:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 vK94u3JIM23p for ; Mon, 23 May 2016 18:31:02 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EB112D500 for ; Mon, 23 May 2016 18:31:02 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4C18422E253; Mon, 23 May 2016 21:30:53 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Tue, 24 May 2016 11:30:50 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>  
To: Jana Iyengar 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Olivier Bonaventure , "Scharf, Michael \(Nokia - DE\)" , Kyle Rose , Ryan Hamilton , Brian Trammell , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 01:31:04 -0000

> On 24 May 2016, at 4:36 AM, Jana Iyengar  wrote:
>=20
> I agree with the spirit of Mark's and Olivier's assessments. I'm happy =
to add wording to the charter but we'd have to be careful. QUIC's =
comparisons are not to TCP, MPTCP, SCTP, or TLS1.3 individually, since =
they all implement different functions that are all combined in QUIC. =
I'm happy to state something along the lines of QUIC using TLS1.3 should =
have privacy and security properties that are no worse than a stack =
comprised of TLS1.3 over one of {TCP, MPTCP, or SCTP}.=20
>=20
> Does that sound reasonable?

SGTM, although some tweaking along the lines Michael suggests might help =
(it shouldn't be the case that we can e.g., treat MPTCP as a floor for =
privacy when multipath isn't in use).

Cheers,


>=20
> I'll point out that there's nothing in the current design of QUIC that =
runs afoul of this statement (including use of the same connection ID =
for multipath). Of course, we can make it better, so let's have that =
conversation when specific design questions are being considered.
>=20
> - jana
>=20
> On Mon, May 23, 2016 at 12:28 AM, Olivier Bonaventure =
 wrote:
> Mark,
>=20
> Shooting for perfect privacy is always going to fail.
>=20
> I totally agree
>=20
> What we should be aiming for is no worse than TCP -- having stable, =
well-understood behaviour is the important thing here. The Internet (and =
the Web) is a platform that people both design for and use with certain =
assumptions in mind; we shouldn't violate them without very carefully =
weighing the impact.
>=20
> Making it better than TCP would be a good outcome too, of course.
>=20
> It would be nice to have something in the charter stating "no worse =
than TCP" for privacy and possibly other properties as well.
>=20
> This is exactly the type of wording that we should have in the charter =
for various mechanisms that already exist and are/will be included in =
QUIC.
>=20
> For congestion control, QUIC should reuse the existing (single-path =
and multipath) TCP congestion control schemes.
>=20
> For privacy, QUIC should not be worse than existing transport =
protocols (TCP, Multipath TCP, SCTP). For Multipath TCP, we took this =
approach for security and it turned out to be good.
>=20
> Same applies probably for the security features in relation with TLS =
1.3 and perhaps HTTP/2 for the API discussion.
>=20
> Olivier
>=20
> --=20
>=20
> ------------------------------
> DISCLAIMER.
> This email and any files transmitted with it are confidential and =
intended solely for the use of the individual or entity to whom they are =
addressed. If you have received this email in error please notify the =
system manager. This message contains confidential information and is =
intended only for the individual named. If you are not the named =
addressee you should not disseminate, distribute or copy this e-mail. =
Please notify the sender immediately by e-mail if you have received this =
e-mail by mistake and delete this e-mail from your system. If you are =
not the intended recipient you are notified that disclosing, copying, =
distributing or taking any action in reliance on the contents of this =
information is strictly prohibited.
>=20

--
Mark Nottingham   https://www.mnot.net/


From nobody Mon May 23 19:07:50 2016
Return-Path: 
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 2C7EB12DC30 for ; Mon, 23 May 2016 19:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 jMa_bMfjss3s for ; Mon, 23 May 2016 19:07:47 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 D23A912DC2F for ; Mon, 23 May 2016 19:07:46 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id x189so3022739ywe.3 for ; Mon, 23 May 2016 19:07:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kh8GVq06VqaqThJKq/v0i8L24fxLWxC9za/iOwauuu0=; b=ksaJNH4XaxzX8gqNWLhUIhsCxYdkyAVeWLzvJV0Ay097wP4atxAwJ51rDzkzRTE6r3 5FmOFgE/wwF/DYkbTp5t0BMZE/BM1o2pBl+KyA8cxXE6RNnqbd9YSji7zIcgUiRhI7Nf PwQ/6b1Kyp/jyTTYA27iqVPPKzNCeVS8dNq66qPtqYeH032ZDdxCiJF7CBmK6dJbSwF5 pPtiPPdHhpyrV64glXaDYijvHkryZUA9AANF575kUh8Fv/cWyQ5Uj/OpWSZJc0ZLYiz1 TkrmEqZS5Vo/X10CQzIS2VYYl1eXeUzr++YLUEqSq1PvNyK9YnZScfKIy4VaY6w9hV+v uYnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kh8GVq06VqaqThJKq/v0i8L24fxLWxC9za/iOwauuu0=; b=Eb5qqt8PBow2/oPZhODxnyF4aFZ/zny0ZvChwXaJekWeF9mOXvjzJqvB5MSM3MrUNB MXn3sdFzon7+7ztb9sv7PaYVpc/J4M3BngKYxcG6wYawNyjCm8wjHGDQp6hbERPbpLzV qsb98x6RSsTQcea4QpS91SrKz4HtUQVQUFoox++6d9tHk/IEoamLF7utgDGgLGSTj4OB s3xGzxpe3mP0qPMKrSXacRzFSXbF+7OR2G/0zJdbVJpVZZvDmZ5vGTPhYy3rSyNfhMho NpIT5vphivUunWVCpAMakDAuq7upwR9Y2OladntSg9zo9NHtVJkscMqQENS9CYsxBeeq nVGQ==
X-Gm-Message-State: ALyK8tL2lWYeRbFoBfwQkxPOftJY9ix+XB/nX9TJHr6D4WHeXzN7VilO8bnzkGgcGve94+//jeOTHb6Ccf448OOL
X-Received: by 10.13.198.197 with SMTP id i188mr1055286ywd.207.1464055665869;  Mon, 23 May 2016 19:07:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 19:07:44 -0700 (PDT)
In-Reply-To: <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>
From: Jana Iyengar 
Date: Mon, 23 May 2016 19:07:44 -0700
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=001a114d6f74e5c87a05338d05ff
Archived-At: 
Cc: Olivier Bonaventure , "Scharf, Michael \(Nokia - DE\)" , Kyle Rose , Ryan Hamilton , Brian Trammell , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 02:07:49 -0000

--001a114d6f74e5c87a05338d05ff
Content-Type: text/plain; charset=UTF-8

On Mon, May 23, 2016 at 6:30 PM, Mark Nottingham  wrote:

>
> > On 24 May 2016, at 4:36 AM, Jana Iyengar  wrote:
> >
> > I agree with the spirit of Mark's and Olivier's assessments. I'm happy
> to add wording to the charter but we'd have to be careful. QUIC's
> comparisons are not to TCP, MPTCP, SCTP, or TLS1.3 individually, since they
> all implement different functions that are all combined in QUIC. I'm happy
> to state something along the lines of QUIC using TLS1.3 should have privacy
> and security properties that are no worse than a stack comprised of TLS1.3
> over one of {TCP, MPTCP, or SCTP}.
> >
> > Does that sound reasonable?
>
> SGTM, although some tweaking along the lines Michael suggests might help
> (it shouldn't be the case that we can e.g., treat MPTCP as a floor for
> privacy when multipath isn't in use).
>

I don't follow this line of thinking. MPTCP was explicitly designed with
the goal of being a drop-in replacement for TCP -- see the relevant section
in RFC 6182 . As a
co-author of that RFC, I know for fact that backward-compatibility with
applications was considered an important goal for MPTCP. Is the suggestion
here that MPTCP brings up privacy issues that make it not a drop-in
replacement for TCP? I would argue that the privacy properties of MPTCP are
a reasonable floor for QUIC. That is the current state of the art when it
comes to TCP with multipath operations.

To keep it simple, my suggestion for the wording is "This work will ensure
that QUIC using TLS1.3 has security and privacy properties that are at
least as good as a stack composed of TLS1.3 using MPTCP."

- jana



> Cheers,
>
>
> >
> > I'll point out that there's nothing in the current design of QUIC that
> runs afoul of this statement (including use of the same connection ID for
> multipath). Of course, we can make it better, so let's have that
> conversation when specific design questions are being considered.
> >
> > - jana
> >
> > On Mon, May 23, 2016 at 12:28 AM, Olivier Bonaventure <
> olivier.bonaventure@tessares.net> wrote:
> > Mark,
> >
> > Shooting for perfect privacy is always going to fail.
> >
> > I totally agree
> >
> > What we should be aiming for is no worse than TCP -- having stable,
> well-understood behaviour is the important thing here. The Internet (and
> the Web) is a platform that people both design for and use with certain
> assumptions in mind; we shouldn't violate them without very carefully
> weighing the impact.
> >
> > Making it better than TCP would be a good outcome too, of course.
> >
> > It would be nice to have something in the charter stating "no worse than
> TCP" for privacy and possibly other properties as well.
> >
> > This is exactly the type of wording that we should have in the charter
> for various mechanisms that already exist and are/will be included in QUIC.
> >
> > For congestion control, QUIC should reuse the existing (single-path and
> multipath) TCP congestion control schemes.
> >
> > For privacy, QUIC should not be worse than existing transport protocols
> (TCP, Multipath TCP, SCTP). For Multipath TCP, we took this approach for
> security and it turned out to be good.
> >
> > Same applies probably for the security features in relation with TLS 1.3
> and perhaps HTTP/2 for the API discussion.
> >
> > Olivier
> >
> > --
> >
> > ------------------------------
> > DISCLAIMER.
> > This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this email in error please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail. Please notify
> the sender immediately by e-mail if you have received this e-mail by
> mistake and delete this e-mail from your system. If you are not the
> intended recipient you are notified that disclosing, copying, distributing
> or taking any action in reliance on the contents of this information is
> strictly prohibited.
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>

--001a114d6f74e5c87a05338d05ff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 23, 2016 at 6:30 PM, Mark Nottingham <mnot@mnot.net> wrote:


> On 24 May 2016, at 4:36 AM, Jana Iyengar <jri@google.com> wrote:

>

> I agree with the spirit of Mark's and Olivier's assessments. I=
'm happy to add wording to the charter but we'd have to be careful.=
 QUIC's comparisons are not to TCP, MPTCP, SCTP, or TLS1.3 individually=
, since they all implement different functions that are all combined in QUI=
C. I'm happy to state something along the lines of QUIC using TLS1.3 sh=
ould have privacy and security properties that are no worse than a stack co=
mprised of TLS1.3 over one of {TCP, MPTCP, or SCTP}.

>

> Does that sound reasonable?



SGTM, although some tweaking along the lines Michael suggests might =
help (it shouldn't be the case that we can e.g., treat MPTCP as a floor=
 for privacy when multipath isn't in use).

I don't follow this line of thinking. MPTCP was explicitly desi=
gned with the goal of being a drop-in replacement for TCP -- see the relevant section in=
 RFC 6182. As a co-author of that RFC, I know for fact that backward-co=
mpatibility with applications was considered an important goal for MPTCP. I=
s the suggestion here that MPTCP brings up privacy issues that make it not =
a drop-in replacement for TCP? I would argue that the privacy properties of=
 MPTCP are a reasonable floor for QUIC. That is the current state of the ar=
t when it comes to TCP with multipath operations.

=
To keep it simple, my suggestion for the wording is "This work will en=
sure that QUIC using TLS1.3 has security and privacy properties that are at=
 least as good as a stack composed of TLS1.3 using MPTCP."

- jana

=C2=A0

Cheers,





>

> I'll point out that there's nothing in the current design of Q=
UIC that runs afoul of this statement (including use of the same connection=
 ID for multipath). Of course, we can make it better, so let's have tha=
t conversation when specific design questions are being considered.

>

> - jana

>

> On Mon, May 23, 2016 at 12:28 AM, Olivier Bonaventure <olivier.bonaventure@tessares.net> wrote:

> Mark,

>

> Shooting for perfect privacy is always going to fail.

>

> I totally agree

>

> What we should be aiming for is no worse than TCP -- having stable, we=
ll-understood behaviour is the important thing here. The Internet (and the =
Web) is a platform that people both design for and use with certain assumpt=
ions in mind; we shouldn't violate them without very carefully weighing=
 the impact.

>

> Making it better than TCP would be a good outcome too, of course.

>

> It would be nice to have something in the charter stating "no wor=
se than TCP" for privacy and possibly other properties as well.

>

> This is exactly the type of wording that we should have in the charter=
 for various mechanisms that already exist and are/will be included in QUIC=
.

>

> For congestion control, QUIC should reuse the existing (single-path an=
d multipath) TCP congestion control schemes.

>

> For privacy, QUIC should not be worse than existing transport protocol=
s (TCP, Multipath TCP, SCTP). For Multipath TCP, we took this approach for =
security and it turned out to be good.

>

> Same applies probably for the security features in relation with TLS 1=
.3 and perhaps HTTP/2 for the API discussion.

>

> Olivier

>

> --

>

> ------------------------------

> DISCLAIMER.

> This email and any files transmitted with it are confidential and inte=
nded solely for the use of the individual or entity to whom they are addres=
sed. If you have received this email in error please notify the system mana=
ger. This message contains confidential information and is intended only fo=
r the individual named. If you are not the named addressee you should not d=
isseminate, distribute or copy this e-mail. Please notify the sender immedi=
ately by e-mail if you have received this e-mail by mistake and delete this=
 e-mail from your system. If you are not the intended recipient you are not=
ified that disclosing, copying, distributing or taking any action in relian=
ce on the contents of this information is strictly prohibited.

>




--

Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/







--001a114d6f74e5c87a05338d05ff--


From nobody Mon May 23 19:10:37 2016
Return-Path: 
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 E166212DC3C for ; Mon, 23 May 2016 19:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ercfu9U9WHAl for ; Mon, 23 May 2016 19:10:24 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 52D6012DC2B for ; Mon, 23 May 2016 19:10:23 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id h19so3164141ywc.0 for ; Mon, 23 May 2016 19:10:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NPY/nWfZon66pc43cT3FsNzfwkYc7i6vaabi9LHTTb0=; b=JRFIswuaKMc5gucfTxG46zPO6lldEX3TASkKC+lgh4ub0ElFK+SJrRzCrb7fTEkB1X VODdRkJIfQMw4Ryj0dXrSLvM8lheU8q0b1HHNRdI8bWjA/7gX686JwPbZI0h5LhNbR9D 9+j+DeWLIaoRfYwPlGaumgpB/LsxLFWtENCZs5U0RHXzLqfw646A+KfbavDUg8VX2lvB zIUdiZx3KUT510BDaj6gARJIoKCB9UOP0btk46zyWUZlAMY9P7Gew6LYEOKsHsCW0RD8 M9MfFFm5t771PnG8y5duLZdo9HOjgqoIM+8uxLgOft72KwzJfpiDamxwB4VoJW8wMePQ 0tVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NPY/nWfZon66pc43cT3FsNzfwkYc7i6vaabi9LHTTb0=; b=cZZjXCKxigv+1HlH5V+gnNR9nHsQYQEtTFa7NLZomk6J3h7301/Q6RW+4cIkmPD3/I glXMpd6F09DHfPKmwFwbIjL70C0soVGXGns+Y1iTAyIob6Cid7Ab0yYE74kw2saHuLbD mQmAlEwD93PPHQt1xqsqKNl1Li6pFsX/pJf+zzNbCowAalHV4hJIgrdWWNq7kHENdlUk u+M1FQWSNrEVFYn9uC+8M7YnSxCfzCeV4xMfUewhCdw/AsvJfWcCTX2PPxUqQIbC7/ir jjKRHpGtawaS9v79rVJxm8wEQZUhM6/C8+jANnPqsuh/N46BDjnww+RWSb97zHaoyq1s SBzQ==
X-Gm-Message-State: ALyK8tLs4fXOVBrs+zgQzcs7kJIWlLTUgXD4tgI99ayTk2KT/dMJZIvcHL9Y/BdA2h/5UEqKXXyqgp/jTw/vbXM/
X-Received: by 10.13.237.1 with SMTP id w1mr1102253ywe.62.1464055822536; Mon, 23 May 2016 19:10:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 19:10:21 -0700 (PDT)
In-Reply-To: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net> 
From: Jana Iyengar 
Date: Mon, 23 May 2016 19:10:21 -0700
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=94eb2c0864a83c37c505338d0f37
Archived-At: 
Cc: Olivier Bonaventure , "Scharf, Michael \(Nokia - DE\)" , Kyle Rose , Ryan Hamilton , Brian Trammell , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 02:10:36 -0000

--94eb2c0864a83c37c505338d0f37
Content-Type: text/plain; charset=UTF-8

On Mon, May 23, 2016 at 7:07 PM, Jana Iyengar  wrote:

> On Mon, May 23, 2016 at 6:30 PM, Mark Nottingham  wrote:
>
>>
>> > On 24 May 2016, at 4:36 AM, Jana Iyengar  wrote:
>> >
>> > I agree with the spirit of Mark's and Olivier's assessments. I'm happy
>> to add wording to the charter but we'd have to be careful. QUIC's
>> comparisons are not to TCP, MPTCP, SCTP, or TLS1.3 individually, since they
>> all implement different functions that are all combined in QUIC. I'm happy
>> to state something along the lines of QUIC using TLS1.3 should have privacy
>> and security properties that are no worse than a stack comprised of TLS1.3
>> over one of {TCP, MPTCP, or SCTP}.
>> >
>> > Does that sound reasonable?
>>
>> SGTM, although some tweaking along the lines Michael suggests might help
>> (it shouldn't be the case that we can e.g., treat MPTCP as a floor for
>> privacy when multipath isn't in use).
>>
>
> I don't follow this line of thinking. MPTCP was explicitly designed with
> the goal of being a drop-in replacement for TCP -- see the relevant
> section in RFC 6182 .
> As a co-author of that RFC, I know for fact that backward-compatibility
> with applications was considered an important goal for MPTCP. Is the
> suggestion here that MPTCP brings up privacy issues that make it not a
> drop-in replacement for TCP? I would argue that the privacy properties of
> MPTCP are a reasonable floor for QUIC. That is the current state of the art
> when it comes to TCP with multipath operations.
>

I meant to say: "That is the current state of the art when it comes to TCP
with multipath operations, whether or not multiple paths are being used."


> To keep it simple, my suggestion for the wording is "This work will ensure
> that QUIC using TLS1.3 has security and privacy properties that are at
> least as good as a stack composed of TLS1.3 using MPTCP."
>
> - jana
>
>
>
>> Cheers,
>>
>>
>> >
>> > I'll point out that there's nothing in the current design of QUIC that
>> runs afoul of this statement (including use of the same connection ID for
>> multipath). Of course, we can make it better, so let's have that
>> conversation when specific design questions are being considered.
>> >
>> > - jana
>> >
>> > On Mon, May 23, 2016 at 12:28 AM, Olivier Bonaventure <
>> olivier.bonaventure@tessares.net> wrote:
>> > Mark,
>> >
>> > Shooting for perfect privacy is always going to fail.
>> >
>> > I totally agree
>> >
>> > What we should be aiming for is no worse than TCP -- having stable,
>> well-understood behaviour is the important thing here. The Internet (and
>> the Web) is a platform that people both design for and use with certain
>> assumptions in mind; we shouldn't violate them without very carefully
>> weighing the impact.
>> >
>> > Making it better than TCP would be a good outcome too, of course.
>> >
>> > It would be nice to have something in the charter stating "no worse
>> than TCP" for privacy and possibly other properties as well.
>> >
>> > This is exactly the type of wording that we should have in the charter
>> for various mechanisms that already exist and are/will be included in QUIC.
>> >
>> > For congestion control, QUIC should reuse the existing (single-path and
>> multipath) TCP congestion control schemes.
>> >
>> > For privacy, QUIC should not be worse than existing transport protocols
>> (TCP, Multipath TCP, SCTP). For Multipath TCP, we took this approach for
>> security and it turned out to be good.
>> >
>> > Same applies probably for the security features in relation with TLS
>> 1.3 and perhaps HTTP/2 for the API discussion.
>> >
>> > Olivier
>> >
>> > --
>> >
>> > ------------------------------
>> > DISCLAIMER.
>> > This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this email in error please notify the
>> system manager. This message contains confidential information and is
>> intended only for the individual named. If you are not the named addressee
>> you should not disseminate, distribute or copy this e-mail. Please notify
>> the sender immediately by e-mail if you have received this e-mail by
>> mistake and delete this e-mail from your system. If you are not the
>> intended recipient you are notified that disclosing, copying, distributing
>> or taking any action in reliance on the contents of this information is
>> strictly prohibited.
>> >
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>

--94eb2c0864a83c37c505338d0f37
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 23, 2016 at 7:07 PM, Jana Iyengar <jri@google.com> wrote:
On Mon, May 23, 2016 at 6:30 PM, Mark Nottingham <mnot@mnot.net><=
/span> wrote:


> On 24 May 2016, at 4:36 AM, Jana Iyengar <jri@google.com> wrote:

>

> I agree with the spirit of Mark's and Olivier's assessments. I=
'm happy to add wording to the charter but we'd have to be careful.=
 QUIC's comparisons are not to TCP, MPTCP, SCTP, or TLS1.3 individually=
, since they all implement different functions that are all combined in QUI=
C. I'm happy to state something along the lines of QUIC using TLS1.3 sh=
ould have privacy and security properties that are no worse than a stack co=
mprised of TLS1.3 over one of {TCP, MPTCP, or SCTP}.

>

> Does that sound reasonable?



SGTM, although some tweaking along the lines Michael suggests might =
help (it shouldn't be the case that we can e.g., treat MPTCP as a floor=
 for privacy when multipath isn't in use).

I don't follow this line of thinking. MPTCP was explicit=
ly designed with the goal of being a drop-in replacement for TCP -- see the=
 relevant sec=
tion in RFC 6182. As a co-author of that RFC, I know for fact that back=
ward-compatibility with applications was considered an important goal for M=
PTCP. Is the suggestion here that MPTCP brings up privacy issues that make =
it not a drop-in replacement for TCP? I would argue that the privacy proper=
ties of MPTCP are a reasonable floor for QUIC. That is the current state of=
 the art when it comes to TCP with multipath operations.
<=
/div>

I meant to say: "That is the cur=
rent state of the art when it comes to TCP with multipath operations, wheth=
er or not multiple paths are being used."
=C2=A0
To keep it simple, my suggestion for the wording is "This =
work will ensure that QUIC using TLS1.3 has security and privacy properties=
 that are at least as good as a stack composed of TLS1.3 using MPTCP."=


=
- jana

=C2=A0=


Cheers,





>

> I'll point out that there's nothing in the current design of Q=
UIC that runs afoul of this statement (including use of the same connection=
 ID for multipath). Of course, we can make it better, so let's have tha=
t conversation when specific design questions are being considered.

>

> - jana

>

> On Mon, May 23, 2016 at 12:28 AM, Olivier Bonaventure <olivier.bonaventure@tessares.net> wrote:

> Mark,

>

> Shooting for perfect privacy is always going to fail.

>

> I totally agree

>

> What we should be aiming for is no worse than TCP -- having stable, we=
ll-understood behaviour is the important thing here. The Internet (and the =
Web) is a platform that people both design for and use with certain assumpt=
ions in mind; we shouldn't violate them without very carefully weighing=
 the impact.

>

> Making it better than TCP would be a good outcome too, of course.

>

> It would be nice to have something in the charter stating "no wor=
se than TCP" for privacy and possibly other properties as well.

>

> This is exactly the type of wording that we should have in the charter=
 for various mechanisms that already exist and are/will be included in QUIC=
.

>

> For congestion control, QUIC should reuse the existing (single-path an=
d multipath) TCP congestion control schemes.

>

> For privacy, QUIC should not be worse than existing transport protocol=
s (TCP, Multipath TCP, SCTP). For Multipath TCP, we took this approach for =
security and it turned out to be good.

>

> Same applies probably for the security features in relation with TLS 1=
.3 and perhaps HTTP/2 for the API discussion.

>

> Olivier

>

> --

>

> ------------------------------

> DISCLAIMER.

> This email and any files transmitted with it are confidential and inte=
nded solely for the use of the individual or entity to whom they are addres=
sed. If you have received this email in error please notify the system mana=
ger. This message contains confidential information and is intended only fo=
r the individual named. If you are not the named addressee you should not d=
isseminate, distribute or copy this e-mail. Please notify the sender immedi=
ately by e-mail if you have received this e-mail by mistake and delete this=
 e-mail from your system. If you are not the intended recipient you are not=
ified that disclosing, copying, distributing or taking any action in relian=
ce on the contents of this information is strictly prohibited.

>










--94eb2c0864a83c37c505338d0f37--


From nobody Mon May 23 19:36:16 2016
Return-Path: 
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 7098912DB7E for ; Mon, 23 May 2016 19:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 R7aypokufGKD for ; Mon, 23 May 2016 19:36:10 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 E9C3D12D4FE for ; Mon, 23 May 2016 19:36:09 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id x189so3479123ywe.3 for ; Mon, 23 May 2016 19:36:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=47K21urCxRCDC2R2k81W0pDQIEuOb3/sllYKgzSxanM=; b=ZnNUVv+Jjs/50Jh8E4JQqxNvuVEe9+DpTL03g2Vvtj0fRjFFmdKL1vPT8jGBhQB33U 602xNAJnRnzb+BOgLHU7DbxXxZ5iFMTqrjp3jSqkzs2hiFAxdpgktQwa523CjF/39a3u VkaSAbkWTcENKVuIGU9Rg+oH8pvAzj9YGBTTQWIM6hyWcAOnFryTDaOdTiDFpVAl30Y3 W063dgU06JNO6FmRiNEfj431X9Mng/5z11gNPw02vms026oBkfemDFOIyT1RKHoTLkTK tWMtoDZnqAvbeGZtphkrcPInBjiWsFEQQYqPzAQkooYHDMYtTF3dVUFDATOCgFynXv0+ PqRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=47K21urCxRCDC2R2k81W0pDQIEuOb3/sllYKgzSxanM=; b=ew07SWU5qh7SVLKuPqCDB4cf6SZW32GndFx2ShwX7D9P6UAZTdfip+NEHTMKIq2m8s ULFqr1kE6VFdM8UYeq7OimG6dGmcl+klkHesVQFeD0lwMunhCWH94pJ8PI8pXSty4h7N 99XmIdgFtqOsWJOSY0SToryU7wCIoFqW8de3ca92EOcrh322OLxCccpcvY+o4TYeI7v3 iyvvJW8Y46j7+n9LZqivXcdtsRDvNZ6aAxCBXhXfacyW2iMcLF6DWVfTB+6TFJNp7+gi aqEc+gw4b16y8MPA3KqB7veDvYtx9mKcwspwiT1ki7+veLbVxFpKZ2bf9uqyRGH1hTzc Yl0A==
X-Gm-Message-State: ALyK8tKmVkI5V6IClzX0siZ2bqJP+bYru+d/3n2puqBUVFU2ayb+Svte7LQMWFtBDCvnPUoQjiSra7OhJ7gI+Pyv
X-Received: by 10.37.49.193 with SMTP id x184mr1152951ybx.57.1464057368847; Mon, 23 May 2016 19:36:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 19:36:08 -0700 (PDT)
In-Reply-To: 
References:  
From: Jana Iyengar 
Date: Mon, 23 May 2016 19:36:08 -0700
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=001a1148af1867376c05338d6b5d
Archived-At: 
Cc: quic@ietf.org
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 02:36:15 -0000

--001a1148af1867376c05338d6b5d
Content-Type: text/plain; charset=UTF-8

Hi Mark,

The word "negotiation" can be read as a certain style of protocol operation
> by some people; could you just say "protocol versioning and configuration"?
>

I can see multipath as "configurable" protocol behavior; if folks think
thats reasonable, I'm fine with using "configuration" instead of "options
negotiation".

The use of "versioning" is a bit ambiguous though because it seems to apply
to both the process of creating new versions and the process of negotiating
a version for use. "Versioning" is actually used later in the charter:
"[...] this work will describe a versioning process that enables
distributed experimentation with QUIC."

How about "version negotiation and protocol configuration"?

- jana

--001a1148af1867376c05338d6b5d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Mark,


The word "negotiation" can be read as a certain style of protocol=
 operation by some people; could you just say "protocol versioning and=
 configuration"?

I can see multipa=
th as "configurable" protocol behavior; if folks think thats reas=
onable, I'm fine with using "configuration" instead of "=
options negotiation".

The use of "versio=
ning" is a bit ambiguous though because it seems to apply to both the =
process of creating new versions and the process of negotiating a version f=
or use. "Versioning" is actually used later in the charter: "=
;[...]=C2=A0this work will describe a versioning process that enables distr=
ibuted experimentation with QUIC."

How about =
"version negotiation and protocol configuration"?

<=
/div>
- jana


--001a1148af1867376c05338d6b5d--


From nobody Mon May 23 20:23:04 2016
Return-Path: 
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 C773B12D5B3 for ; Mon, 23 May 2016 20:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=microsoft.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 4kKON4VhLfxg for ; Mon, 23 May 2016 20:22:59 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCF212D120 for ; Mon, 23 May 2016 20:22:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ka8rrSba+iXiAG7qXfiR95waePptPs7EO4+CCzViMV0=; b=XcvTtCSUJGsv+aAobuQtQKYp9Z9ErSUzAU37To3faNRpQdhlAonou1kH0ucffvo0RKdp89Ld5OoWE2x1TcOr9TVfXZbL/mCmeyuoSy18pRpTjiV1XO4R6Sk6TAEshj0nHqJiOoVuJi0p24VV6XxsCDb5gruv2uY3Rb1hxQf8Hzk=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 24 May 2016 03:22:41 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0492.020; Tue, 24 May 2016 03:22:40 +0000
From: Christian Huitema 
To: Jana Iyengar , Mark Nottingham 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynMN6GVCYzd10uovw2jcGWCDZ/DaqoAgAAj/QCAAaspAIAARJaAgAAp5oCAAEbugIAAM9KAgAC6vACAAHOzAIAACk8AgAAAu4CAABHU4A==
Date: Tue, 24 May 2016 03:22:40 +0000
Message-ID: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [24.16.156.113]
x-ms-office365-filtering-correlation-id: c0576797-471f-4428-592c-08d38382a997
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:yfSGLq4VF1Qe3wtIApMXaOqJjxPuIviy4QjWq6I9Rsgrmq5zaE9pcsT6DcZ7U8RLSP+kH4Fdfcfd9uYDWNwTuOD1ovSw0vf6pyyoSy8SdRUfcXz6ijONzcKqmiQTMs1a+AnuDA3RhrzYzAXU9juG5A==; 24:UsuW2zhJ+LidhCKgGXRJWXZji0NIa+MVrnV+I2GeBzqkooFNYV8oAKZcqLcbEYOnPXdJJ/Znqm4sNOlCkc54AWOAeposrXM9I8hfTyrTQkQ=; 7:EN9c8hBi/HoNNMQ9UMZC/OGt9Axul+gquKwIYrAL0Kl2T+e4/vRwQSAcMEKaSui19EFDbniZgpVt7n9dHcNVz9z+XFKhV0RPmd2zg6M8yA4lPudhRsmYReOauQHAF7ClhgefCG8dnB2Kpdwz+hLr+maIUc+juHNtNn4nRPju+/VRUMPgU4ZNgwF12qgJrVEB82c4ub+mUK8T7yMxMZY/fg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; 
x-forefront-prvs: 09525C61DB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(93886004)(5002640100001)(66066001)(8676002)(5003600100002)(5005710100001)(8936002)(92566002)(10090500001)(19580405001)(19580395003)(76176999)(10290500002)(10400500002)(81166006)(74316001)(54356999)(87936001)(33656002)(2950100001)(2900100001)(5004730100002)(15975445007)(5001770100001)(86362001)(586003)(3660700001)(3280700002)(122556002)(189998001)(106116001)(50986999)(76576001)(5008740100001)(1220700001)(2906002)(3846002)(102836003)(6116002)(9686002)(4326007)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 03:22:40.0658 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653
Archived-At: 
Cc: Olivier Bonaventure , Kyle Rose , "Scharf, Michael \(Nokia - DE\)" , Ryan Hamilton , Brian Trammell , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 03:23:02 -0000

T24gTW9uZGF5LCBNYXkgMjMsIDIwMTYgNDoxMCBQTSwgSmFuYSBJeWVuZ2FyIHdyb3RlOg0KPiBP
biBNb24sIE1heSAyMywgMjAxNiBhdCA3OjA3IFBNLCBKYW5hIEl5ZW5nYXIgPG1haWx0bzpqcmlA
Z29vZ2xlLmNvbT4gd3JvdGU6DQo+PiBPbiBNb24sIE1heSAyMywgMjAxNiBhdCA2OjMwIFBNLCBN
YXJrIE5vdHRpbmdoYW0gPG1haWx0bzptbm90QG1ub3QubmV0PiB3cm90ZToNCuKApg0KPj4+IFNH
VE0sIGFsdGhvdWdoIHNvbWUgdHdlYWtpbmcgYWxvbmcgdGhlIGxpbmVzIE1pY2hhZWwgc3VnZ2Vz
dHMgbWlnaHQgaGVscCAoaXQgc2hvdWxkbid0IGJlDQo+Pj4gIHRoZSBjYXNlIHRoYXQgd2UgY2Fu
IGUuZy4sIHRyZWF0IE1QVENQIGFzIGEgZmxvb3IgZm9yIHByaXZhY3kgd2hlbiBtdWx0aXBhdGgg
aXNuJ3QgaW4gdXNlKS4NCj4+DQo+PiBJIGRvbid0IGZvbGxvdyB0aGlzIGxpbmUgb2YgdGhpbmtp
bmcuIE1QVENQIHdhcyBleHBsaWNpdGx5IGRlc2lnbmVkIHdpdGggdGhlIGdvYWwgb2YgYmVpbmcg
YSANCj4+IGRyb3AtaW4gcmVwbGFjZW1lbnQgZm9yIFRDUCAtLSBzZWUgdGhlIGh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTgyI3NlY3Rpb24tMi4yLjEuIA0KPj4gQXMgYSBjby1hdXRo
b3Igb2YgdGhhdCBSRkMsIEkga25vdyBmb3IgZmFjdCB0aGF0IGJhY2t3YXJkLWNvbXBhdGliaWxp
dHkgd2l0aCBhcHBsaWNhdGlvbnMNCj4+IHdhcyBjb25zaWRlcmVkIGFuIGltcG9ydGFudCBnb2Fs
IGZvciBNUFRDUC4gSXMgdGhlIHN1Z2dlc3Rpb24gaGVyZSB0aGF0IE1QVENQIGJyaW5ncyB1cA0K
Pj4gcHJpdmFjeSBpc3N1ZXMgdGhhdCBtYWtlIGl0IG5vdCBhIGRyb3AtaW4gcmVwbGFjZW1lbnQg
Zm9yIFRDUD8gDQoNClllcy4gVGhpcyB3YXMgYWN0dWFsbHkgZGlzY3Vzc2VkIGR1cmluZyB0aGUg
TVBUQ1AgbWVldGluZyBpbiBCQS4gTVBUQ1AgdXNlcyBhIHNpbXBsZSBjbGVhci10ZXh0IHRva2Vu
IHRvIGxpbmsgbXVsdGlwbGUgcGF0aHMgdG9nZXRoZXIsIGFuZCB0aGF0IGhhcyBzaWduaWZpY2Fu
dCBwcml2YWN5IGltcGxpY2F0aW9ucy4gVGhlcmUgaXMgbm8gZGVmaW5pdGl2ZSBzb2x1dGlvbiB5
ZXQsIGJ1dCB0aGUgImJpcyIgdmVyc2lvbiBvZiBNUFRDUCBjb3VsZCBhZGRyZXNzIHRoYXQuDQoN
Cj4+IEkgd291bGQgYXJndWUgdGhhdCB0aGUgcHJpdmFjeSBwcm9wZXJ0aWVzIG9mIE1QVENQIGFy
ZSBhIHJlYXNvbmFibGUgZmxvb3IgZm9yIFFVSUMuIFRoYXQgaXMgDQo+PiB0aGUgY3VycmVudCBz
dGF0ZSBvZiB0aGUgYXJ0IHdoZW4gaXQgY29tZXMgdG8gVENQIHdpdGggbXVsdGlwYXRoIG9wZXJh
dGlvbnMuDQo+DQo+IEkgbWVhbnQgdG8gc2F5OiAiVGhhdCBpcyB0aGUgY3VycmVudCBzdGF0ZSBv
ZiB0aGUgYXJ0IHdoZW4gaXQgY29tZXMgdG8gVENQIHdpdGggbXVsdGlwYXRoIG9wZXJhdGlvbnMs
IA0KPiB3aGV0aGVyIG9yIG5vdCBtdWx0aXBsZSBwYXRocyBhcmUgYmVpbmcgdXNlZC4iDQoNCkl0
IGlzIHRoZSBwcmV2aW91cyBzdGF0ZSBvZiB0aGUgYXJ0LCBidXQgd2Ugc3VyZSB3aXNoIHRvIHBy
b2dyZXNzIHRoYXQuwqANCg0KPiBUbyBrZWVwIGl0IHNpbXBsZSwgbXkgc3VnZ2VzdGlvbiBmb3Ig
dGhlIHdvcmRpbmcgaXMgIlRoaXMgd29yayB3aWxsIGVuc3VyZSB0aGF0IFFVSUMgdXNpbmcNCj4g
IFRMUzEuMyBoYXMgc2VjdXJpdHkgYW5kIHByaXZhY3kgcHJvcGVydGllcyB0aGF0IGFyZSBhdCBs
ZWFzdCBhcyBnb29kIGFzIGEgc3RhY2sgY29tcG9zZWQgb2YgVExTMS4zIA0KPiB1c2luZyBNUFRD
UC4iDQoNCk1ha2UgdGhhdCAiYXMgZ29vZCBhcyBhIHN0YWNrIGNvbXBvc2VkIG9mIFRMUzEuMyB1
c2luZyBUQ1AiIGFuZCBldmVyeWJvZHkgd2lsbCBiZSBoYXBweS4NCg0KLS0gQ2hyaXN0aWFuIEh1
aXRlbWENCg0KDQo=


From nobody Mon May 23 20:34:41 2016
Return-Path: 
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 696BD12DC3A for ; Mon, 23 May 2016 20:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 slpksthSwB22 for ; Mon, 23 May 2016 20:34:38 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 A7A3812DC38 for ; Mon, 23 May 2016 20:34:38 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id t40so4622808ioi.0 for ; Mon, 23 May 2016 20:34:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KlMAGrYNnobS6URjKhgQhGINhKPTonQat/4bf3w/5WU=; b=P0/MNKhDdS+ntr6SsIeqIzSdnz8jkv3Gz83DtGKjAAIAnruEYUWBZLRTSU+g4h74ao LdfuG5xSuz0YDTvnyeJBbRkmEuyjp8s3jY3lo9WwDdnE1Hlh7t54iOxzA+1n8Um3SgtK 6CKYt/nTlbtzPe4DSpd/LW6Gz+H5YVXYHzhxNUWNccFQA0i8pHTrtu2JVG+4nFDmLC5n Zi1VfZZjMVog+GCjXUxKAJJTQDzT4CHBQHPsvXrNPAehbxWQPNeOEHkSVM+BZHRcZNAK +GC7VQmRe0jta2iJzfSkBPp8+KHo9i3C8F+UtT4ybdCy2xT1MW37Nci+Y6LlwN7lTcYw lJGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KlMAGrYNnobS6URjKhgQhGINhKPTonQat/4bf3w/5WU=; b=Ry27fNL/ZG2m8GZhvCCOUPDMuL5DRmQKdixBjZL73vFxeJnjFbRCJg4f2swBkbn9YQ nG79G0NMW4CTNzErByizT3cXjZ+PJ/lvQuTbGYhQAep/ZDCTH2yggFN6xc6NOGT0zg1u KWpG+ytI/An+XOUZ1g8AQ6NJokKkeUYDt5dFu50/nUAGJrFI5e3EO4/cSN5M3aPx2iix zUTFe/rcAyxV+RICGAtq4i2Fn3JFxHhp38s0zfB7hXJycSHWgri7Ne2WvysgkEhYhaCM tQlBvz+TR0TBull+QgiXbgj+X1FfRo+v3EjACv/bKx90Ftu61L2TQQ7kZsSbtaQyd8V5 OrhQ==
X-Gm-Message-State: AOPr4FUQWTfR0UD8p2lbo55ftKbGwDZDZJNu3Omxm2S8PNOx02Gp5Kyx9HoYsulafWfr++H1urjknV8yk8WA/88R
X-Received: by 10.107.140.133 with SMTP id o127mr15529530iod.32.1464060877841;  Mon, 23 May 2016 20:34:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.227.227 with HTTP; Mon, 23 May 2016 20:34:18 -0700 (PDT)
In-Reply-To: 
References:   
From: Ian Swett 
Date: Mon, 23 May 2016 23:34:18 -0400
Message-ID: 
To: Jana Iyengar 
Content-Type: multipart/alternative; boundary=94eb2c05c9488e059205338e3cee
Archived-At: 
Cc: Mark Nottingham , quic@ietf.org
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 03:34:40 -0000

--94eb2c05c9488e059205338e3cee
Content-Type: text/plain; charset=UTF-8

In TCP, I believe options negotiation is known as options negotiation.  So
unless there is an important difference between QUIC's options and TCP's, I
would prefer the same naming as TCP.  My understanding is that they're
sufficiently similar they should use the same name.

Configuration implies pre-configuration on both ends.  In this case, I
believe we expect clients to offer up new features and have the server
accept or deny the offer.

On Mon, May 23, 2016 at 10:36 PM, Jana Iyengar  wrote:

> Hi Mark,
>
> The word "negotiation" can be read as a certain style of protocol
>> operation by some people; could you just say "protocol versioning and
>> configuration"?
>>
>
> I can see multipath as "configurable" protocol behavior; if folks think
> thats reasonable, I'm fine with using "configuration" instead of "options
> negotiation".
>
> The use of "versioning" is a bit ambiguous though because it seems to
> apply to both the process of creating new versions and the process of
> negotiating a version for use. "Versioning" is actually used later in the
> charter: "[...] this work will describe a versioning process that enables
> distributed experimentation with QUIC."
>
> How about "version negotiation and protocol configuration"?
>
> - jana
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>

--94eb2c05c9488e059205338e3cee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


In TCP, I believe options negotiation is known as options =
negotiation.=C2=A0 So unless there is an important difference between QUIC&=
#39;s options and TCP's, I would prefer the same naming as TCP.=C2=A0 M=
y understanding is that they're sufficiently similar they should use th=
e same name.

Configuration implies pre-configuration on =
both ends.=C2=A0 In this case, I believe we expect clients to offer up new =
features and have the server accept or deny the offer. =C2=A0

On Mon, May 23, 201=
6 at 10:36 PM, Jana Iyengar <jri@google.com> wrote:
Hi Mark,


The word "negotiation" can be read as a certain style of protocol=
 operation by some people; could you just say "protocol versioning and=
 configuration"?

I can see =
multipath as "configurable" protocol behavior; if folks think tha=
ts reasonable, I'm fine with using "configuration" instead of=
 "options negotiation".

The use of "=
;versioning" is a bit ambiguous though because it seems to apply to bo=
th the process of creating new versions and the process of negotiating a ve=
rsion for use. "Versioning" is actually used later in the charter=
: "[...]=C2=A0this work will describe a versioning process that enable=
s distributed experimentation with QUIC."

How=
 about "version negotiation and protocol configuration"?

- jana


_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--94eb2c05c9488e059205338e3cee--


From nobody Mon May 23 21:00:30 2016
Return-Path: 
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 94CF212B05E for ; Mon, 23 May 2016 21:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 b4H64PEyprgq for ; Mon, 23 May 2016 21:00:27 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5645A12D5DA for ; Mon, 23 May 2016 20:54:59 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 655FF22E255; Mon, 23 May 2016 23:54:55 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Tue, 24 May 2016 13:54:53 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    
To: Ian Swett 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , quic@ietf.org
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 04:00:28 -0000

In H2, it's not really a negotiation mechanism; it's configuration =
advertisement.

Is the intent that this will cover things like SETTINGS, or is that =
separate?

Cheers,



> On 24 May 2016, at 1:34 PM, Ian Swett  wrote:
>=20
> In TCP, I believe options negotiation is known as options negotiation. =
 So unless there is an important difference between QUIC's options and =
TCP's, I would prefer the same naming as TCP.  My understanding is that =
they're sufficiently similar they should use the same name.
>=20
> Configuration implies pre-configuration on both ends.  In this case, I =
believe we expect clients to offer up new features and have the server =
accept or deny the offer. =20
>=20
> On Mon, May 23, 2016 at 10:36 PM, Jana Iyengar  wrote:
> Hi Mark,
>=20
> The word "negotiation" can be read as a certain style of protocol =
operation by some people; could you just say "protocol versioning and =
configuration"?
>=20
> I can see multipath as "configurable" protocol behavior; if folks =
think thats reasonable, I'm fine with using "configuration" instead of =
"options negotiation".
>=20
> The use of "versioning" is a bit ambiguous though because it seems to =
apply to both the process of creating new versions and the process of =
negotiating a version for use. "Versioning" is actually used later in =
the charter: "[...] this work will describe a versioning process that =
enables distributed experimentation with QUIC."
>=20
> How about "version negotiation and protocol configuration"?
>=20
> - jana
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>=20
>=20

--
Mark Nottingham   https://www.mnot.net/


From nobody Mon May 23 21:07:18 2016
Return-Path: 
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 B33C012D5DA for ; Mon, 23 May 2016 21:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 p06m_vsvOsG6 for ; Mon, 23 May 2016 21:07:15 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 933DB12B05E for ; Mon, 23 May 2016 21:07:14 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id a136so51912141wme.0 for ; Mon, 23 May 2016 21:07:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U98NxmvjCq9HX8kyq3shoKSH2ode2Lj0WR7Vr6Lu4M4=; b=JUDqYLHD99wraMgvBMe1L1ccnAAkQuNcKyCji/+2048GwtY3UvRVRMUhI4GUQCfShM BHZpOSryI5qunkmNRd1/HGUAoqcN6desatpHgA1ke19HKPUD+RxzPxnbM1HEVmxiY35f B6OfEpEnG6J2zUlGbkkg5JbfwCtvcepgw430oK2XMGu/1mDuGzPr5n+7TB9zEhTlv1Yr SiE758kT6whXYOEa+Mjvh/OgflpJX0S3K0X5odVD87mLoQNe7Qh/cK4S+rLFpfbVOFyo +QlsygMcMrW1xLFU72G+tjCQe1jwjDuRqvPLPbGqXQmre8G9OLfw0Z14NOZL4gYpAHHT /smg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U98NxmvjCq9HX8kyq3shoKSH2ode2Lj0WR7Vr6Lu4M4=; b=RR2ulmaIVtyfdZzC7qqVUYdB3mXhMyiUHDnIEOZgbAk4Eegu9pEZ1RuyRF81TiC0oe uN/ufojjHRy7Uj5ZBX6L4dHKVpgQyD7QERMhsMeYtaorHENjmXn2bmTFa2EbPQT2sJHy YJEKKX/E6L5cXrK1dHR4VwisYBYxy46dpeq2f1wnaufzO0I41WJLCvDI3ix9rMye9bLD O2K01WLkQMb/y5bvkA937j4HhcAbWgfRyy2ImfROVuNJqhlntsUwnMlgnDs+L+QzfGwP fT8e6cu+eEc0PbAmLt3iqfuR4OG8n8fd2YEPIotNIflrNCt1Xo2HDbotahGjd+7NmuGw knUA==
X-Gm-Message-State: ALyK8tILPFDW6MH0j7/QzgZpImw05iz7y5GNN3QVpUxexYmgzuJ9c/9ZLH6E471lwlogzAs1JgIKAx6lViD9uW7a
X-Received: by 10.194.116.9 with SMTP id js9mr2241450wjb.112.1464062832787; Mon, 23 May 2016 21:07:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.31.85 with HTTP; Mon, 23 May 2016 21:07:11 -0700 (PDT)
In-Reply-To: 
References:     
From: Ryan Hamilton 
Date: Mon, 23 May 2016 21:07:11 -0700
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=001a1130d2181413e705338eb1df
Archived-At: 
Cc: Jana Iyengar , Ian Swett , quic@ietf.org
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 04:07:17 -0000

--001a1130d2181413e705338eb1df
Content-Type: text/plain; charset=UTF-8

I would imagine that the H2 over QUIC mapping can specify how to map the
HTTP/2 SETTINGS onto QUIC. The simplest choice would be to send an HTTP/2
SETTINGS frame on the headers stream, but it might also make sense to use
the underlying QUIC mechanisms. In any case I would expect this to be a
work item of the HTTP/2 mapping focus area.

On Mon, May 23, 2016 at 8:54 PM, Mark Nottingham  wrote:

> In H2, it's not really a negotiation mechanism; it's configuration
> advertisement.
>
> Is the intent that this will cover things like SETTINGS, or is that
> separate?
>
> Cheers,
>
>
>
> > On 24 May 2016, at 1:34 PM, Ian Swett  wrote:
> >
> > In TCP, I believe options negotiation is known as options negotiation.
> So unless there is an important difference between QUIC's options and
> TCP's, I would prefer the same naming as TCP.  My understanding is that
> they're sufficiently similar they should use the same name.
> >
> > Configuration implies pre-configuration on both ends.  In this case, I
> believe we expect clients to offer up new features and have the server
> accept or deny the offer.
> >
> > On Mon, May 23, 2016 at 10:36 PM, Jana Iyengar  wrote:
> > Hi Mark,
> >
> > The word "negotiation" can be read as a certain style of protocol
> operation by some people; could you just say "protocol versioning and
> configuration"?
> >
> > I can see multipath as "configurable" protocol behavior; if folks think
> thats reasonable, I'm fine with using "configuration" instead of "options
> negotiation".
> >
> > The use of "versioning" is a bit ambiguous though because it seems to
> apply to both the process of creating new versions and the process of
> negotiating a version for use. "Versioning" is actually used later in the
> charter: "[...] this work will describe a versioning process that enables
> distributed experimentation with QUIC."
> >
> > How about "version negotiation and protocol configuration"?
> >
> > - jana
> >
> > _______________________________________________
> > QUIC mailing list
> > QUIC@ietf.org
> > https://www.ietf.org/mailman/listinfo/quic
> >
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>

--001a1130d2181413e705338eb1df
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I would imagine that the H2 over QUIC mapping can specify =
how to map the HTTP/2 SETTINGS onto QUIC. The simplest choice would be to s=
end an HTTP/2 SETTINGS frame on the headers stream, but it might also make =
sense to use the underlying QUIC mechanisms. In any case I would expect thi=
s to be a work item of the HTTP/2 mapping focus area.

On Mon, May 23, 2016 at 8:5=
4 PM, Mark Nottingham <mnot@mnot.net> wrote:
In H2, it's not really a negotiation mechanism; it's=
 configuration advertisement.



Is the intent that this will cover things like SETTINGS, or is that separat=
e?



Cheers,








> On 24 May 2016, at 1:34 PM, Ian Swett <ianswett@google.com> wrote:

>

> In TCP, I believe options negotiation is known as options negotiation.=
=C2=A0 So unless there is an important difference between QUIC's option=
s and TCP's, I would prefer the same naming as TCP.=C2=A0 My understand=
ing is that they're sufficiently similar they should use the same name.=


>

> Configuration implies pre-configuration on both ends.=C2=A0 In this ca=
se, I believe we expect clients to offer up new features and have the serve=
r accept or deny the offer.

>

> On Mon, May 23, 2016 at 10:36 PM, Jana Iyengar <jri@google.com> wrote:

> Hi Mark,

>

> The word "negotiation" can be read as a certain style of pro=
tocol operation by some people; could you just say "protocol versionin=
g and configuration"?

>

> I can see multipath as "configurable" protocol behavior; if =
folks think thats reasonable, I'm fine with using "configuration&q=
uot; instead of "options negotiation".

>

> The use of "versioning" is a bit ambiguous though because it=
 seems to apply to both the process of creating new versions and the proces=
s of negotiating a version for use. "Versioning" is actually used=
 later in the charter: "[...] this work will describe a versioning pro=
cess that enables distributed experimentation with QUIC."

>

> How about "version negotiation and protocol configuration"?<=
br>
>

> - jana

>

> _______________________________________________

> QUIC mailing list

> QUIC@ietf.org

> https://www.ietf.org/mailman/listinfo/quic

>

>




--

Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/




____________________________=
___________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--001a1130d2181413e705338eb1df--


From nobody Mon May 23 22:51:44 2016
Return-Path: 
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 83E2912D5BF for ; Mon, 23 May 2016 22:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 zYkVk2Vp9gR0 for ; Mon, 23 May 2016 22:51:42 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F39212D178 for ; Mon, 23 May 2016 22:51:41 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-47-5743ebebaa3f
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2B.04.12926.BEBE3475; Tue, 24 May 2016 07:51:40 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Tue, 24 May 2016 07:51:39 +0200
From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= 
To: Jana Iyengar , Mark Nottingham 
Thread-Topic: [QUIC] Version Negotiation vs. Option Negotiation
Thread-Index: AQHRsJ1wfont+Zxz+keecrKTcpwjSZ/F1BkAgAFzMgCAAFglgA==
Date: Tue, 24 May 2016 05:51:38 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.4.160422
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7qO6b187hBnsncVlMOrqQxWL9p8eM Fj0LuB2YPRZsKvVYsuQnk8fGxd9ZA5ijuGxSUnMyy1KL9O0SuDIWPJMv+MRccenkFuYGxifM XYycHBICJhJfjrSxQNhiEhfurWfrYuTiEBI4wihx4/wpKGcJo8SHlvNMIFVsAt4SbS2HwTpE BJwkrm99zAhiMwsoS0w53cAKYgsL2En8WnaWDaLGXuLxnYvsMPUts5rAalgEVCXed/SD2bwC 1hKbV01ghlh2klHi7c+VYA2cAoESt3v+ghUxCshK3P9+jwVimbjErSfzmSDOFpBYsuc81Dui Ei8f/wOrFxXQk/hybx4jRFxJYu3h7UC9HEC9mhLrd+lDmNYS2255QkxUlJjS/ZAd4hxBiZMz n7BMYJSYhWTZLITmWQjNs5A0z0LSvICRdRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYEQe 3PJbdQfj5TeOhxgFOBiVeHgTap3DhVgTy4orcw8xSnAwK4nwLr8OFOJNSaysSi3Kjy8qzUkt PsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbLxMEp1cDIf1DQ/M3evXE/ZO9mKhjW129o6Gm5 lHLn4B4Hh8VzX2zgOCIrF7LtivR774qOqV+TftbWqtvkO7ULZPk5Zr1K6pn29twJ2w61K8+/ TVttm6ek8Hzq9ei2ZfJStrzPFvlnWl+eyfP+xdbo5NrP5+011zOZqc8+sHR/sNoa3pMSyf+F 1m52KTJTYinOSDTUYi4qTgQAKaiFc8QCAAA=
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 05:51:43 -0000

DQo+SSBjYW4gc2VlIG11bHRpcGF0aCBhcyAiY29uZmlndXJhYmxlIiBwcm90b2NvbCBiZWhhdmlv
cjsgaWYgZm9sa3MgdGhpbmsNCj50aGF0cyByZWFzb25hYmxlLCBJJ20gZmluZSB3aXRoIHVzaW5n
ICJjb25maWd1cmF0aW9uIiBpbnN0ZWFkIG9mICJvcHRpb25zDQo+bmVnb3RpYXRpb24iLg0KDQpJ
IHVuZGVyc3RhbmQgdGhhdCB0byBtZWFuIFFVSUMgY2FuIGJlIOKAnGNvbmZpZ3VyZWTigJ0gdG8g
YmUgdHVybmVkIG9uIG9yIG9mZg0KbXVsdGkgcGF0aCBhdCBsZWFzdCwgb3IgbW9yZSBhZHZhbmNl
ZCwgZGV0YWlsZWQgY29uZmlndXJhdGlvbiBvZiBpdCBtdWx0aQ0KcGF0aCBzZWxlY3Rpb24/DQoN
ClJlZ2FyZHMNCkfDtnJhbg0KDQo=


From nobody Mon May 23 22:58:40 2016
Return-Path: 
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 1A4F512D632 for ; Mon, 23 May 2016 22:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level: 
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 BQLxCd5_ljA1 for ; Mon, 23 May 2016 22:58:37 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D799612D63C for ; Mon, 23 May 2016 22:58:36 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 8E643A17E629B; Tue, 24 May 2016 05:58:33 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4O5wYYe000477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2016 05:58:34 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4O5wXAJ013800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 May 2016 07:58:34 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 24 May 2016 07:58:34 +0200
From: "Scharf, Michael (Nokia - DE)" 
To: "Salz, Rich" , Jana Iyengar 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynFCnTysxHU/0GFj3E4WoIavJ/DSSMAgAAj/ACAALzBAIABBqOQgAGB/gCAACh9YIAAApeAgAAk0AD//+rPAIAAAM+AgACqRJA=
Date: Tue, 24 May 2016 05:58:32 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48866C3E@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D48863C11@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D4886662C@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <47cd7d685cf54acda0f867e9a9032a90@usma1ex-dag1mb1.msg.corp.akamai.com>
In-Reply-To: <47cd7d685cf54acda0f867e9a9032a90@usma1ex-dag1mb1.msg.corp.akamai.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 05:58:38 -0000

PiA+LTEgb24gdGhhdCB1c2VyIHByaXZhY3kgY2FuIHNpbXBseSB3YWl0IHVudGlsIHRoZSBXRyBp
cyBmb3JtZWQNCj4gDQo+IEkgYW0gY29uZnVzZWQgYnkgdGhpcy4gIEEgV0cgZ2V0cyBmb3JtZWQg
dG8gZG8gdGhpbmdzLiAgU28gcHV0dGluZw0KPiBwcml2YWN5IGluIHRoZSBjaGFydGVyIHNob3Vs
ZCBiZSBhbGwgdGhhdCdzIG5lZWRlZCwgcmlnaHQ/DQoNCk15IHBvaW50IGlzIHRoYXQgdXNlciBw
cml2YWN5IGhhcyB0byAoYWxzbykgYmUgYSBmaXJzdC1jbGFzcyBjaXRpemVuIGluIHRoZSBwcm90
b2NvbCBkZXNpZ24uDQoNCkkgd2lsbCBiZSBmaW5lIHdpdGggYSBjaGFydGVyIHRoYXQgZ3VhcmFu
dGVlcyB1c2VyIHByaXZhY3kgImFzIGdvb2QgYXMgYSBzdGFjayBjb21wb3NlZCBvZiBUTFMxLjMg
dXNpbmcgVENQIi4gDQoNCkhhdmluZyBzb21lIHNvcnQgb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlv
biBzZWN0aW9uIHdvdWxkIHBlcmhhcHMgaGVscCB0byBiZXR0ZXIgdW5kZXJzdGFuZCB3aGF0IHN1
Y2ggd29yZGluZyBpbiByZWFsaXR5IG1heSBpbXBseSBmb3IgcHJvdG9jb2wgZGVzaWduIGNob2lj
ZXMsIGJ1dCwgaW5kZWVkLCBmaW5hbGx5IHRoZSBjaGFydGVyIHdvcmRpbmcgaXMgd2hhdCBtYXR0
ZXJzLg0KDQpNaWNoYWVsDQo=


From nobody Mon May 23 23:30:35 2016
Return-Path: 
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 AB5EA12B059 for ; Mon, 23 May 2016 23:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 G4Jitpzyomvf for ; Mon, 23 May 2016 23:30:24 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 D5CD012DC5E for ; Mon, 23 May 2016 23:30:23 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id a136so55556506wme.0 for ; Mon, 23 May 2016 23:30:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8f5KydttHDouXEIv+ivo9bQHTmYI0ZxEE+x53Uk6Emo=; b=FaxrlB5c6fP2vuvzY7EaO/hzzXpDhhxMbFQB1+3XNndrw2sHR91sWUlEkt1/ahIcvW XPRCoOh6fT7W1i57paNv09nHorJNc2ALPZoAoPwjy2mij6EI0Bk3bc9uKlEWROs+uy6/ t2Utk/2n2DyFE432pWrhTYjtYRXy0BVJe7KTkizDqNEK8OPo7N1Te0UZAiqKsLc8/x8k 7tN6r0/pl06fjulPCPxeG8YJze7ijhK/36PNZGRDTtAPv+ELgFbxhI5KW4wMc9TNJ5tx LXYc5gsyPdPaS6XCvIDlTAlnod7zFsjcplmpMD9lYmJHDsZ8y3Wqd+6pwDPR42g4au2E BSFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8f5KydttHDouXEIv+ivo9bQHTmYI0ZxEE+x53Uk6Emo=; b=ake4qQ3abKiNs577GfGAyZCsD8NCKfaGVej4I89q2WbuWayRDMA3DJZBkK8aKLfftp h2nPACv5Jr1iqRvMUy/TKAVwlTSMR+VfwHSWU9CH4fD8x/zTwh3O+lo8R9iZJMRyufDY q6+YPXOyow+jRd6/SGlr2o5pa9VptzFqERipvy7aVB+K5ijTWRFfb2gW6RVyZ2CAVk8m RqY/A/yJ8PGunaEAHs3w+4Jbb5YnSrCPW12SkxrY50UykrDOBpPRxXSmera24V5a39kP SlvuhtEdupjwCjtGmiC9wNEd6ofX6rUtstVppCcbDo3Saqa8vRcVBw6p2LbClHB+G/A3 ajzQ==
X-Gm-Message-State: ALyK8tKb9P74tTkmsl4LDPIpuCZ4dUrxqv5h8Nlxe0lJrfdUfe4zgDV+uIYp0UE5xuxvlg==
X-Received: by 10.194.172.228 with SMTP id bf4mr2333419wjc.123.1464071422284;  Mon, 23 May 2016 23:30:22 -0700 (PDT)
Received: from [192.168.137.252] ([109.253.199.242]) by smtp.gmail.com with ESMTPSA id d7sm2140142wmd.11.2016.05.23.23.30.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 May 2016 23:30:21 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir 
In-Reply-To: <655C07320163294895BBADA28372AF5D48866C3E@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Date: Tue, 24 May 2016 09:30:15 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D48863C11@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D4886662C@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <47cd7d685cf54acda0f867e9a9032a90@usma1ex-dag1mb1.msg.corp.akamai.com> <655C07320163294895BBADA28372AF5D48866C3E@FR712WXCHMBA15.zeu.alcatel-lucent.com>
To: "Scharf, Michael (Nokia - DE)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Rich Salz , "quic@ietf.org" , Ryan Hamilton , Jana Iyengar 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 06:30:34 -0000

> On 24 May 2016, at 8:58 AM, Scharf, Michael (Nokia - DE) =
 wrote:
>=20
>>> -1 on that user privacy can simply wait until the WG is formed
>>=20
>> I am confused by this.  A WG gets formed to do things.  So putting
>> privacy in the charter should be all that's needed, right?
>=20
> My point is that user privacy has to (also) be a first-class citizen =
in the protocol design.
>=20
> I will be fine with a charter that guarantees user privacy "as good as =
a stack composed of TLS1.3 using TCP=E2=80=9D.=20

I=E2=80=99d rather go with =E2=80=9CTLS=E2=80=9D rather than =E2=80=9CTLS =
1.3=E2=80=9D because TLS 1.3 is still a moving target.
>=20
> Having some sort of security consideration section would perhaps help =
to better understand what such wording in reality may imply for protocol =
design choices, but, indeed, finally the charter wording is what =
matters.

IMO the charter wording on this does not matter much. If the output =
document of the working group has poor privacy or security properties, =
anyone reading it could object even if the charter was entirely silent =
on these topics. Same goes for efficiency, congestion control and any =
other property that is part of good engineering.

The utility of a charter is in limiting the scope of a working group=E2=80=
=99s work by defining the deliverables. It is not in stating generic =
desirable properties of those deliverables, and privacy is desirable in =
any protocol. If we had specific requirements like =E2=80=9Cmessages =
should not exceed 140 bytes=E2=80=9D, that would be OK to state in the =
charter, but =E2=80=9Cthe protocol should be secure=E2=80=9D is not.

Yoav


From nobody Mon May 23 23:32:07 2016
Return-Path: 
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 4FFA212DC5F for ; Mon, 23 May 2016 23:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 6z_igLmoeyRb for ; Mon, 23 May 2016 23:32:04 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 6D2E612DC5C for ; Mon, 23 May 2016 23:32:04 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id o16so6929815ywd.2 for ; Mon, 23 May 2016 23:32:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1CGOGWvbEaQdmXVXqO7U5JInnEhrdxdS4ScSpAn+aNk=; b=IiTiAsN/ZnBExM/FEUpULtHColuJWEQb1+DV43yM2t5f3t4Eg/RljL+lBHt0Td0D7C WfxVgp3LeaHGCOWwbdF4LytsavkzipauGRvPw3qYm6sU4UzcDAeTBKIGHEHWCxI0nYTQ k3TSrG3/hAzYtGxQ4DZN7/LI2zVUSBkaJSkaLemSo2FFGBT/ABSAEFthZuJ2UzURl+cm bs6xF65GU2Ilif52r2g17+mMbns3RfqzrgZ+ntYDOzh2EEA8miF8kPaulVBptm+A188v hA2iB2i4pCBv1SbStA4pkhaNcXInzvIXvG+aU++8WI4rP/WIN4mASLhlXbfxuOFZ5SO0 h3nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1CGOGWvbEaQdmXVXqO7U5JInnEhrdxdS4ScSpAn+aNk=; b=OLbceOMKwGoW0w/Aq7GcAc57Iym6zV9FGDq4k/ij/rthiWGcLubv7zUXH7LFn2rBoF maHzJ8iLf1cv0rgIBQT26iRb4brWfGrUmv+luTf8R/wi4mjD+5GoHeMTj1/oaun9rnFe 6/R71xw85TEq2ozPyrNLAfjUgGmv43gIOBW5m6hyB+6y7zP1IgsVS8g5Hk6uREuDNbfe kFlDwQ9V4iXM15nYK6g2eOVsrJkRp/Y3toIo0KPTKuMLQEmKigX86eFkdWR7ZAFIytZI 7gZH4Gfcha/r1btQiKXspt46l8mHvZ4Z6Q80oAL4h5BSRSrqTPG6KQq8hfR9H4b0v3ev QZbg==
X-Gm-Message-State: ALyK8tK8+XzoKHat3Ir0A/o1TAV0ghkQ40QJ1sJdTUxoHACqMG4B+4rgAbSkdYenrM+9ii+SeaSuDxVfd1qG2fUf
X-Received: by 10.13.218.65 with SMTP id c62mr1487565ywe.36.1464071523523; Mon, 23 May 2016 23:32:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 23:32:02 -0700 (PDT)
In-Reply-To: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>   
From: Jana Iyengar 
Date: Mon, 23 May 2016 23:32:02 -0700
Message-ID: 
To: Christian Huitema 
Content-Type: multipart/alternative; boundary=94eb2c0805081648e6053390b719
Archived-At: 
Cc: Olivier Bonaventure , Kyle Rose , "Scharf, Michael \(Nokia - DE\)" , Ryan Hamilton , Mark Nottingham , Brian Trammell , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 06:32:06 -0000

--94eb2c0805081648e6053390b719
Content-Type: text/plain; charset=UTF-8

>
>
> Yes. This was actually discussed during the MPTCP meeting in BA. MPTCP
> uses a simple clear-text token to link multiple paths together, and that
> has significant privacy implications. There is no definitive solution yet,
> but the "bis" version of MPTCP could address that.


I'm aware of the cleartext token, but if the MPTCP wg has agreed to fix
this in a bis document, doesn't that automatically raise the privacy bar
that QUIC needs to meet if we say "QUIC must be at least as good as MPTCP"?

>> I would argue that the privacy properties of MPTCP are a reasonable
> floor for QUIC. That is
> >> the current state of the art when it comes to TCP with multipath
> operations.
> >
> > I meant to say: "That is the current state of the art when it comes to
> TCP with multipath operations,
> > whether or not multiple paths are being used."
>
> It is the previous state of the art, but we sure wish to progress that.


It is the current state of the art until we have something better. QUIC
could certainly move this state forward, but nevertheless, MPTCP is the
IETF's latest multipath solution. Note that I'm not saying that QUIC should
be exactly as good as MPTCP, just that it should be at least as good as
MPTCP. This is a minimum bar -- you are arguing that this minimum is too
low, but I really think that's a discussion in the wg when we need to
discuss multipath, not a charter one when we're trying to lay ground rules.

> To keep it simple, my suggestion for the wording is "This work will
> ensure that QUIC using
> >  TLS1.3 has security and privacy properties that are at least as good as
> a stack composed of TLS1.3
> > using MPTCP."
>
> Make that "as good as a stack composed of TLS1.3 using TCP" and everybody
> will be happy.


How does this apply to multipath?

My higher-order point is that making MPTCP the bar is consistent with where
the IETF is right now with transport. I am totally for discussing the
merits of raising this bar in QUIC, but it seems like this discussion
belongs in the wg, where we can debate the cost and merits of doing better,
and I'm looking forward to that conversation. The charter is laying out
what the minimum bar is, and the higher-order goal is to say that we won't
do worse than X, where X is the state of the art for IETF-TCP. This is
currently MPTCP.

I could go with what Mark and Michael suggested; something like: "This work
will ensure that QUIC using TLS1.3 has security and privacy properties that
are at least as good as a stack composed of TLS1.3 using TCP (or MPTCP when
using multipath.)"

What do folks think?
- jana


> -- Christian Huitema
>
>
>

--94eb2c0805081648e6053390b719
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Yes. This was actually discussed during the MPTCP meeting =
in BA. MPTCP uses a simple clear-text token to link multiple paths together=
, and that has significant privacy implications. There is no definitive sol=
ution yet, but the "bis" version of MPTCP could address that.

I'm aware of the cleartext token, but if t=
he MPTCP wg has agreed to fix this in a bis document, doesn't that auto=
matically raise the privacy bar that QUIC needs to meet if we say "QUI=
C must be at least as good as MPTCP"?


>> I would argue that the privacy properties of MPTCP are a reasonabl=
e floor for QUIC. That is

>> the current state of the art when it comes to TCP with multipath o=
perations.

>

> I meant to say: "That is the current state of the art when it com=
es to TCP with multipath operations,

> whether or not multiple paths are being used."



It is the previous state of the art, but we sure wish to progress th=
at.=C2=A0

It is the current state of the ar=
t until we have something better. QUIC could certainly move this state forw=
ard, but nevertheless, MPTCP is the IETF's latest multipath solution. N=
ote that I'm not saying that QUIC should be exactly as good as MPTCP, j=
ust that it should be at least as good as MPTCP. This is a minimum bar -- y=
ou are arguing that this minimum is too low, but I really think that's =
a discussion in the wg when we need to discuss multipath, not a charter one=
 when we're trying to lay ground rules.


> To keep it simple, my suggestion for the wording is "This work wi=
ll ensure that QUIC using

>=C2=A0 TLS1.3 has security and privacy properties that are at least as =
good as a stack composed of TLS1.3

> using MPTCP."



Make that "as good as a stack composed of TLS1.3 using TCP"=
; and everybody will be happy.

How does thi=
s apply to multipath?

My higher-order point is that makin=
g MPTCP the bar is consistent with where the IETF is right now with transpo=
rt. I am totally for discussing the merits of raising this bar in QUIC, but=
 it seems like this discussion belongs in the wg, where we can debate the c=
ost and merits of doing better, and I'm looking forward to that convers=
ation. The charter is laying out what the minimum bar is, and the higher-or=
der goal is to say that we won't do worse than X, where X is the state =
of the art for IETF-TCP. This is currently MPTCP.

=
I could go with what Mark and Michael suggested; something like: "This=
 work will ensure that QUIC using TLS1.3 has security and privacy propertie=
s that are at least as good as a stack composed of TLS1.3 using TCP (or MPT=
CP when using multipath.)"

What do folks thin=
k?
- jana



-- Christian Huitema









--94eb2c0805081648e6053390b719--


From nobody Mon May 23 23:36:23 2016
Return-Path: 
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 AD56812DC67 for ; Mon, 23 May 2016 23:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 hR1abdxJE8uX for ; Mon, 23 May 2016 23:36:20 -0700 (PDT)
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 08F1112D568 for ; Mon, 23 May 2016 23:36:20 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id c127so7016513ywb.1 for ; Mon, 23 May 2016 23:36:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pxs9n3lnDggPfqtU3l6VATEEaJzaxlnVSfqu/T+2660=; b=I9b2pxpFlwU+dcRcpDsB0wxqYUfYFvUz/GKne1bnLhsfklk+N923cT9aiXK33n85Ru PMBf0RkgoTyYNfYXn5ZxxL3qzQSXVyYgKw1jprjwG/6nRMhb9KCCSqvaTBucmxTt6RKl iFCJNcxsmGLeLRlimGyszZCy51qxuHjomju++JM4+xOBl+4AYoktLbY6+2gdGJRsNkAc zxhqiDtZgJTFq95qyEOIN6PWhzpqUa41V6AbRRG+dYTorRTQgMfowm1prr3K23A8+Y6G Ovhr1C0EHdRfyw6JzDxpk0fc/m6uGJnwgEcP+ZetaX4Hs1TKLa1Rg57ik2YZ9Ytoeeb1 vOfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pxs9n3lnDggPfqtU3l6VATEEaJzaxlnVSfqu/T+2660=; b=i5VLALqMHhXR97j/Hw4CPqGYrF/haGMFM8+AWLvNeSnsOBoShdD96R/fRZYxUyb+5P HxgYaQ4vpJJ+YsgJRLu8n3QcgjQndeJf0iE3OWnOgybT1+UDoCf/KNdbmaI+tUYDIv+J 1C0JmnXpYDGh33z/0CyMvmIERossDHGxVvVYHrWZ/uilW9g100tn1LlDtJaQfGgEVyS9 AzuKVsPLceom39zmjYpRnk7gL5OIGbGUQWMiOLvom+aWBaYnvEQCs6JlhLnWS4vwRHsK U/NJcKSSwvDpftu2YUuSpG5PNERDuKnc7RiDDj9pE7Xq+CJL1v2mlypeUan6urMT2K8j oeJw==
X-Gm-Message-State: ALyK8tJrIlw6o8ZGTqCv6NdbNINwm4rLpGJmygzCGAcQImJekyPWzL3PKv/xx8eVJBqRNHr7aWIaIxUNnCQKeHXF
X-Received: by 10.129.91.132 with SMTP id p126mr1667870ywb.188.1464071779233;  Mon, 23 May 2016 23:36:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 23 May 2016 23:36:18 -0700 (PDT)
In-Reply-To: <655C07320163294895BBADA28372AF5D48866C3E@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>    <655C07320163294895BBADA28372AF5D4886201E@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D48863C11@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <655C07320163294895BBADA28372AF5D4886662C@FR712WXCHMBA15.zeu.alcatel-lucent.com>  <47cd7d685cf54acda0f867e9a9032a90@usma1ex-dag1mb1.msg.corp.akamai.com> <655C07320163294895BBADA28372AF5D48866C3E@FR712WXCHMBA15.zeu.alcatel-lucent.com>
From: Jana Iyengar 
Date: Mon, 23 May 2016 23:36:18 -0700
Message-ID: 
To: "Scharf, Michael (Nokia - DE)" 
Content-Type: multipart/alternative; boundary=001a114c7862541b7d053390c6d2
Archived-At: 
Cc: "Salz, Rich" , "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 06:36:22 -0000

--001a114c7862541b7d053390c6d2
Content-Type: text/plain; charset=UTF-8

On Mon, May 23, 2016 at 10:58 PM, Scharf, Michael (Nokia - DE) <
michael.scharf@nokia.com> wrote:

> > >-1 on that user privacy can simply wait until the WG is formed
> >
> > I am confused by this.  A WG gets formed to do things.  So putting
> > privacy in the charter should be all that's needed, right?
>
> My point is that user privacy has to (also) be a first-class citizen in
> the protocol design.
>

+1.

I will be fine with a charter that guarantees user privacy "as good as a
> stack composed of TLS1.3 using TCP".
>

Please take a look at the text that I've proposed in the other email... I
hope that's satisfactory.

- jana


> Having some sort of security consideration section would perhaps help to
> better understand what such wording in reality may imply for protocol
> design choices, but, indeed, finally the charter wording is what matters.

--001a114c7862541b7d053390c6d2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 23, 2016 at 10:58 PM, Scharf, Michael (Nokia - DE) <michael=
.scharf@nokia.com> wrote:
<=
span class=3D"">> >-1 on that user privacy can simply wait until the =
WG is formed

>

> I am confused by this.=C2=A0 A WG gets formed to do things.=C2=A0 So p=
utting

> privacy in the charter should be all that's needed, right?



My point is that user privacy has to (also) be a first-class citizen=
 in the protocol design.

+1.
=


I will be fine with a charter that guarantees user privacy "as good as=
 a stack composed of TLS1.3 using TCP".

Please take a look at the text that I've proposed in the other em=
ail... I hope that's satisfactory.

- jana
=C2=A0

Having some sort of security consideration section would perhaps help to be=
tter understand what such wording in reality may imply for protocol design =
choices, but, indeed, finally the charter wording is what matters.




--001a114c7862541b7d053390c6d2--


From nobody Tue May 24 00:04:28 2016
Return-Path: 
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 3A7FB12DC91 for ; Tue, 24 May 2016 00:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 y6lq-PNzdiyz for ; Tue, 24 May 2016 00:04:21 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B323912DC93 for ; Tue, 24 May 2016 00:04:20 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 11FD4A347E494; Tue, 24 May 2016 07:04:17 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4O74F2m028940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2016 07:04:16 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4O74Bxj008738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 May 2016 09:04:14 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 24 May 2016 09:04:12 +0200
From: "Scharf, Michael (Nokia - DE)" 
To: Jana Iyengar , Christian Huitema 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynFCnTysxHU/0GFj3E4WoIavJ/DSSMAgAAj/ACAAcge0IAAJ6KAgAAp5oCAAEbugIAAM9KAgAC6vACAAHOzAIAACk8AgAAAu4CAABQ1AIAANOgAgAAiH0A=
Date: Tue, 24 May 2016 07:04:11 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48866E63@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>    
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48866E63FR712WXCHMBA15z_"
MIME-Version: 1.0
Archived-At: 
Cc: Olivier Bonaventure , Kyle Rose , Ryan Hamilton , Mark Nottingham , Brian Trammell , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 07:04:24 -0000

--_000_655C07320163294895BBADA28372AF5D48866E63FR712WXCHMBA15z_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

TVBUQ1AgaXMgZXhwZXJpbWVudGFsIHJpZ2h0IG5vdyBhbmQgbWF5IGJlIHBhcnRseSBhIG1vdmlu
ZyB0YXJnZXQuIEFzIGZhciBhcyBJIGtub3csIFNDVFAgaXMgbWFpbmx5IGRlcGxveWVkIGluIGNv
bnRyb2xsZWQgZW52aXJvbm1lbnRzIHNpZ25hbGluZyBlbnZpcm9ubWVudHMsIGluIHdoaWNoIHVz
ZXIgcHJpdmFjeSBpcyBub3QgYSBjb25jZXJuLiBUQ1AgaXMgdGhlIEludGVybmV0IHN0YW5kYXJk
IHRyYW5zcG9ydCBmb3IgbW9zdCBhcHBsaWNhdGlvbnMgYW5kIG1vc3Qgbm90YWJseSB0aGUgV2Vi
Lg0KDQpTbyB0aGUgYmFyIGZvciBzZWN1cml0eSBhbmQgcHJpdmFjeSBpcyBUQ1AsIGluIG15IHBv
aW50IG9mIHZpZXcuIEFjdHVhbGx5LCB0aGVyZSBpcyBubyBuZWVkIHRvIG1lbnRpb24gTVBUQ1Ag
YXQgYWxsLiBJZiBsb3dlcmluZyBvZiBzZWN1cml0eSBhbmQgcHJpdmFjeSBzdGFuZGFyZHMgY29t
cGFyZWQgdG8gVENQIGlzIHJlcXVpcmVkLCBhcyBtZW50aW9uZWQgYmVmb3JlLCB0aGUgY2hhcnRl
ciBjb3VsZCBtZW50aW9uIHRoYXQgdGhlIHByb3RvY29sIGRlc2lnbiBjYW4gZm9yZXNlZSBhZGRp
dGlvbmFsLCBlbnRpcmVseSBvcHRpb25hbCBhZGRpdGlvbmFsIHByb3RvY29sIGZlYXR1cmVzLCBv
biBhbiBvcHQtaW4gYmFzaXMuDQoNCk1pY2hhZWwNCg0KDQpGcm9tOiBKYW5hIEl5ZW5nYXIgW21h
aWx0bzpqcmlAZ29vZ2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1heSAyNCwgMjAxNiA4OjMyIEFN
DQpUbzogQ2hyaXN0aWFuIEh1aXRlbWENCkNjOiBNYXJrIE5vdHRpbmdoYW07IE9saXZpZXIgQm9u
YXZlbnR1cmU7IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk7IEt5bGUgUm9zZTsgUnlhbiBI
YW1pbHRvbjsgQnJpYW4gVHJhbW1lbGw7IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbUVVJ
Q10gUVVJQyBwcml2YWN5IGltcGFjdA0KDQoNClllcy4gVGhpcyB3YXMgYWN0dWFsbHkgZGlzY3Vz
c2VkIGR1cmluZyB0aGUgTVBUQ1AgbWVldGluZyBpbiBCQS4gTVBUQ1AgdXNlcyBhIHNpbXBsZSBj
bGVhci10ZXh0IHRva2VuIHRvIGxpbmsgbXVsdGlwbGUgcGF0aHMgdG9nZXRoZXIsIGFuZCB0aGF0
IGhhcyBzaWduaWZpY2FudCBwcml2YWN5IGltcGxpY2F0aW9ucy4gVGhlcmUgaXMgbm8gZGVmaW5p
dGl2ZSBzb2x1dGlvbiB5ZXQsIGJ1dCB0aGUgImJpcyIgdmVyc2lvbiBvZiBNUFRDUCBjb3VsZCBh
ZGRyZXNzIHRoYXQuDQoNCkknbSBhd2FyZSBvZiB0aGUgY2xlYXJ0ZXh0IHRva2VuLCBidXQgaWYg
dGhlIE1QVENQIHdnIGhhcyBhZ3JlZWQgdG8gZml4IHRoaXMgaW4gYSBiaXMgZG9jdW1lbnQsIGRv
ZXNuJ3QgdGhhdCBhdXRvbWF0aWNhbGx5IHJhaXNlIHRoZSBwcml2YWN5IGJhciB0aGF0IFFVSUMg
bmVlZHMgdG8gbWVldCBpZiB3ZSBzYXkgIlFVSUMgbXVzdCBiZSBhdCBsZWFzdCBhcyBnb29kIGFz
IE1QVENQIj8NCg0KPj4gSSB3b3VsZCBhcmd1ZSB0aGF0IHRoZSBwcml2YWN5IHByb3BlcnRpZXMg
b2YgTVBUQ1AgYXJlIGEgcmVhc29uYWJsZSBmbG9vciBmb3IgUVVJQy4gVGhhdCBpcw0KPj4gdGhl
IGN1cnJlbnQgc3RhdGUgb2YgdGhlIGFydCB3aGVuIGl0IGNvbWVzIHRvIFRDUCB3aXRoIG11bHRp
cGF0aCBvcGVyYXRpb25zLg0KPg0KPiBJIG1lYW50IHRvIHNheTogIlRoYXQgaXMgdGhlIGN1cnJl
bnQgc3RhdGUgb2YgdGhlIGFydCB3aGVuIGl0IGNvbWVzIHRvIFRDUCB3aXRoIG11bHRpcGF0aCBv
cGVyYXRpb25zLA0KPiB3aGV0aGVyIG9yIG5vdCBtdWx0aXBsZSBwYXRocyBhcmUgYmVpbmcgdXNl
ZC4iDQoNCkl0IGlzIHRoZSBwcmV2aW91cyBzdGF0ZSBvZiB0aGUgYXJ0LCBidXQgd2Ugc3VyZSB3
aXNoIHRvIHByb2dyZXNzIHRoYXQuDQoNCkl0IGlzIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBh
cnQgdW50aWwgd2UgaGF2ZSBzb21ldGhpbmcgYmV0dGVyLiBRVUlDIGNvdWxkIGNlcnRhaW5seSBt
b3ZlIHRoaXMgc3RhdGUgZm9yd2FyZCwgYnV0IG5ldmVydGhlbGVzcywgTVBUQ1AgaXMgdGhlIElF
VEYncyBsYXRlc3QgbXVsdGlwYXRoIHNvbHV0aW9uLiBOb3RlIHRoYXQgSSdtIG5vdCBzYXlpbmcg
dGhhdCBRVUlDIHNob3VsZCBiZSBleGFjdGx5IGFzIGdvb2QgYXMgTVBUQ1AsIGp1c3QgdGhhdCBp
dCBzaG91bGQgYmUgYXQgbGVhc3QgYXMgZ29vZCBhcyBNUFRDUC4gVGhpcyBpcyBhIG1pbmltdW0g
YmFyIC0tIHlvdSBhcmUgYXJndWluZyB0aGF0IHRoaXMgbWluaW11bSBpcyB0b28gbG93LCBidXQg
SSByZWFsbHkgdGhpbmsgdGhhdCdzIGEgZGlzY3Vzc2lvbiBpbiB0aGUgd2cgd2hlbiB3ZSBuZWVk
IHRvIGRpc2N1c3MgbXVsdGlwYXRoLCBub3QgYSBjaGFydGVyIG9uZSB3aGVuIHdlJ3JlIHRyeWlu
ZyB0byBsYXkgZ3JvdW5kIHJ1bGVzLg0KDQo+IFRvIGtlZXAgaXQgc2ltcGxlLCBteSBzdWdnZXN0
aW9uIGZvciB0aGUgd29yZGluZyBpcyAiVGhpcyB3b3JrIHdpbGwgZW5zdXJlIHRoYXQgUVVJQyB1
c2luZw0KPiAgVExTMS4zIGhhcyBzZWN1cml0eSBhbmQgcHJpdmFjeSBwcm9wZXJ0aWVzIHRoYXQg
YXJlIGF0IGxlYXN0IGFzIGdvb2QgYXMgYSBzdGFjayBjb21wb3NlZCBvZiBUTFMxLjMNCj4gdXNp
bmcgTVBUQ1AuIg0KDQpNYWtlIHRoYXQgImFzIGdvb2QgYXMgYSBzdGFjayBjb21wb3NlZCBvZiBU
TFMxLjMgdXNpbmcgVENQIiBhbmQgZXZlcnlib2R5IHdpbGwgYmUgaGFwcHkuDQoNCkhvdyBkb2Vz
IHRoaXMgYXBwbHkgdG8gbXVsdGlwYXRoPw0KTXkgaGlnaGVyLW9yZGVyIHBvaW50IGlzIHRoYXQg
bWFraW5nIE1QVENQIHRoZSBiYXIgaXMgY29uc2lzdGVudCB3aXRoIHdoZXJlIHRoZSBJRVRGIGlz
IHJpZ2h0IG5vdyB3aXRoIHRyYW5zcG9ydC4gSSBhbSB0b3RhbGx5IGZvciBkaXNjdXNzaW5nIHRo
ZSBtZXJpdHMgb2YgcmFpc2luZyB0aGlzIGJhciBpbiBRVUlDLCBidXQgaXQgc2VlbXMgbGlrZSB0
aGlzIGRpc2N1c3Npb24gYmVsb25ncyBpbiB0aGUgd2csIHdoZXJlIHdlIGNhbiBkZWJhdGUgdGhl
IGNvc3QgYW5kIG1lcml0cyBvZiBkb2luZyBiZXR0ZXIsIGFuZCBJJ20gbG9va2luZyBmb3J3YXJk
IHRvIHRoYXQgY29udmVyc2F0aW9uLiBUaGUgY2hhcnRlciBpcyBsYXlpbmcgb3V0IHdoYXQgdGhl
IG1pbmltdW0gYmFyIGlzLCBhbmQgdGhlIGhpZ2hlci1vcmRlciBnb2FsIGlzIHRvIHNheSB0aGF0
IHdlIHdvbid0IGRvIHdvcnNlIHRoYW4gWCwgd2hlcmUgWCBpcyB0aGUgc3RhdGUgb2YgdGhlIGFy
dCBmb3IgSUVURi1UQ1AuIFRoaXMgaXMgY3VycmVudGx5IE1QVENQLg0KDQpJIGNvdWxkIGdvIHdp
dGggd2hhdCBNYXJrIGFuZCBNaWNoYWVsIHN1Z2dlc3RlZDsgc29tZXRoaW5nIGxpa2U6ICJUaGlz
IHdvcmsgd2lsbCBlbnN1cmUgdGhhdCBRVUlDIHVzaW5nIFRMUzEuMyBoYXMgc2VjdXJpdHkgYW5k
IHByaXZhY3kgcHJvcGVydGllcyB0aGF0IGFyZSBhdCBsZWFzdCBhcyBnb29kIGFzIGEgc3RhY2sg
Y29tcG9zZWQgb2YgVExTMS4zIHVzaW5nIFRDUCAob3IgTVBUQ1Agd2hlbiB1c2luZyBtdWx0aXBh
dGguKSINCg0KV2hhdCBkbyBmb2xrcyB0aGluaz8NCi0gamFuYQ0KDQoNCi0tIENocmlzdGlhbiBI
dWl0ZW1hDQoNCg0K

--_000_655C07320163294895BBADA28372AF5D48866E63FR712WXCHMBA15z_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u
Z21haWwtDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLmdtYWlsLWhvZW56Yg0KCXtt
c28tc3R5bGUtbmFtZTpnbWFpbC1ob2VuemI7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMTkN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z
dHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w
cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X
b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw
MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv
Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu
Zz0iREUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TVBUQ1AgaXMgZXhwZXJpbWVudGFsIHJpZ2h0IG5v
dyBhbmQgbWF5IGJlIHBhcnRseSBhIG1vdmluZyB0YXJnZXQuIEFzIGZhciBhcyBJIGtub3csIFND
VFAgaXMgbWFpbmx5IGRlcGxveWVkIGluIGNvbnRyb2xsZWQgZW52aXJvbm1lbnRzIHNpZ25hbGlu
Zw0KIGVudmlyb25tZW50cywgaW4gd2hpY2ggdXNlciBwcml2YWN5IGlzIG5vdCBhIGNvbmNlcm4u
IFRDUCBpcyB0aGUgSW50ZXJuZXQgc3RhbmRhcmQgdHJhbnNwb3J0IGZvciBtb3N0IGFwcGxpY2F0
aW9ucyBhbmQgbW9zdCBub3RhYmx5IHRoZSBXZWIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPlNvIHRoZSBiYXIgZm9yIHNlY3VyaXR5IGFuZCBwcml2YWN5IGlzIFRDUCwgaW4g
bXkgcG9pbnQgb2Ygdmlldy4gQWN0dWFsbHksIHRoZXJlIGlzIG5vIG5lZWQgdG8gbWVudGlvbiBN
UFRDUCBhdCBhbGwuIElmIGxvd2VyaW5nIG9mIHNlY3VyaXR5IGFuZA0KIHByaXZhY3kgc3RhbmRh
cmRzIGNvbXBhcmVkIHRvIFRDUCBpcyByZXF1aXJlZCwgYXMgbWVudGlvbmVkIGJlZm9yZSwgdGhl
IGNoYXJ0ZXIgY291bGQgbWVudGlvbiB0aGF0IHRoZSBwcm90b2NvbCBkZXNpZ24gY2FuIGZvcmVz
ZWUgYWRkaXRpb25hbCwgZW50aXJlbHkgb3B0aW9uYWwgYWRkaXRpb25hbCBwcm90b2NvbCBmZWF0
dXJlcywgb24gYW4gb3B0LWluIGJhc2lzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5NaWNoYWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmFuYSBJeWVuZ2FyIFttYWlsdG86anJp
QGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDI0LCAyMDE2IDg6
MzIgQU08YnI+DQo8Yj5Ubzo8L2I+IENoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5yaXN0aWFuIEh1aXRlbWE8YnI+DQo8Yj5DYzo8L2I+IE1hcmsgTm90dGluZ2hhbTsgT2xpdmll
ciBCb25hdmVudHVyZTsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTsgS3lsZSBSb3NlOyBS
eWFuIEhhbWlsdG9uOyBCcmlhbiBUcmFtbWVsbDsgcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl
Y3Q6PC9iPiBSZTogW1FVSUNdIFFVSUMgcHJpdmFjeSBpbXBhY3Q8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu
MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGJyPg0KWWVzLiBUaGlzIHdhcyBhY3R1YWxseSBkaXNjdXNzZWQgZHVyaW5nIHRoZSBN
UFRDUCBtZWV0aW5nIGluIEJBLiBNUFRDUCB1c2VzIGEgc2ltcGxlIGNsZWFyLXRleHQgdG9rZW4g
dG8gbGluayBtdWx0aXBsZSBwYXRocyB0b2dldGhlciwgYW5kIHRoYXQgaGFzIHNpZ25pZmljYW50
IHByaXZhY3kgaW1wbGljYXRpb25zLiBUaGVyZSBpcyBubyBkZWZpbml0aXZlIHNvbHV0aW9uIHll
dCwgYnV0IHRoZSAmcXVvdDtiaXMmcXVvdDsgdmVyc2lvbiBvZiBNUFRDUCBjb3VsZCBhZGRyZXNz
DQogdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkknbSBhd2FyZSBvZiB0aGUgY2xlYXJ0ZXh0IHRva2VuLCBidXQgaWYgdGhl
IE1QVENQIHdnIGhhcyBhZ3JlZWQgdG8gZml4IHRoaXMgaW4gYSBiaXMgZG9jdW1lbnQsIGRvZXNu
J3QgdGhhdCBhdXRvbWF0aWNhbGx5IHJhaXNlIHRoZSBwcml2YWN5IGJhciB0aGF0IFFVSUMgbmVl
ZHMgdG8gbWVldCBpZiB3ZSBzYXkgJnF1b3Q7UVVJQyBtdXN0IGJlIGF0IGxlYXN0IGFzIGdvb2Qg
YXMgTVBUQ1AmcXVvdDs/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsmZ3Q7IEkgd291bGQg
YXJndWUgdGhhdCB0aGUgcHJpdmFjeSBwcm9wZXJ0aWVzIG9mIE1QVENQIGFyZSBhIHJlYXNvbmFi
bGUgZmxvb3IgZm9yIFFVSUMuIFRoYXQgaXM8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWls
LSI+Jmd0OyZndDsgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGFydCB3aGVuIGl0IGNvbWVzIHRv
IFRDUCB3aXRoIG11bHRpcGF0aCBvcGVyYXRpb25zLjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0i
Z21haWwtIj4mZ3Q7PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsgSSBtZWFu
dCB0byBzYXk6ICZxdW90O1RoYXQgaXMgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGFydCB3aGVu
IGl0IGNvbWVzIHRvIFRDUCB3aXRoIG11bHRpcGF0aCBvcGVyYXRpb25zLDwvc3Bhbj48YnI+DQo8
c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IHdoZXRoZXIgb3Igbm90IG11bHRpcGxlIHBhdGhzIGFy
ZSBiZWluZyB1c2VkLiZxdW90Ozwvc3Bhbj48YnI+DQo8YnI+DQpJdCBpcyB0aGUgcHJldmlvdXMg
c3RhdGUgb2YgdGhlIGFydCwgYnV0IHdlIHN1cmUgd2lzaCB0byBwcm9ncmVzcyB0aGF0LiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SXQgaXMgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGFydCB1bnRpbCB3ZSBoYXZlIHNv
bWV0aGluZyBiZXR0ZXIuIFFVSUMgY291bGQgY2VydGFpbmx5IG1vdmUgdGhpcyBzdGF0ZSBmb3J3
YXJkLCBidXQgbmV2ZXJ0aGVsZXNzLCBNUFRDUCBpcyB0aGUgSUVURidzIGxhdGVzdCBtdWx0aXBh
dGggc29sdXRpb24uIE5vdGUgdGhhdCBJJ20gbm90IHNheWluZyB0aGF0IFFVSUMgc2hvdWxkIGJl
IGV4YWN0bHkgYXMgZ29vZA0KIGFzIE1QVENQLCBqdXN0IHRoYXQgaXQgc2hvdWxkIGJlIGF0IGxl
YXN0IGFzIGdvb2QgYXMgTVBUQ1AuIFRoaXMgaXMgYSBtaW5pbXVtIGJhciAtLSB5b3UgYXJlIGFy
Z3VpbmcgdGhhdCB0aGlzIG1pbmltdW0gaXMgdG9vIGxvdywgYnV0IEkgcmVhbGx5IHRoaW5rIHRo
YXQncyBhIGRpc2N1c3Npb24gaW4gdGhlIHdnIHdoZW4gd2UgbmVlZCB0byBkaXNjdXNzIG11bHRp
cGF0aCwgbm90IGEgY2hhcnRlciBvbmUgd2hlbiB3ZSdyZSB0cnlpbmcgdG8gbGF5DQogZ3JvdW5k
IHJ1bGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw
Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IFRvIGtlZXAgaXQgc2ltcGxlLCBt
eSBzdWdnZXN0aW9uIGZvciB0aGUgd29yZGluZyBpcyAmcXVvdDtUaGlzIHdvcmsgd2lsbCBlbnN1
cmUgdGhhdCBRVUlDIHVzaW5nPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsm
bmJzcDsgVExTMS4zIGhhcyBzZWN1cml0eSBhbmQgcHJpdmFjeSBwcm9wZXJ0aWVzIHRoYXQgYXJl
IGF0IGxlYXN0IGFzIGdvb2QgYXMgYSBzdGFjayBjb21wb3NlZCBvZiBUTFMxLjM8L3NwYW4+PGJy
Pg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyB1c2luZyBNUFRDUC4mcXVvdDs8L3NwYW4+PGJy
Pg0KPGJyPg0KTWFrZSB0aGF0ICZxdW90O2FzIGdvb2QgYXMgYSBzdGFjayBjb21wb3NlZCBvZiBU
TFMxLjMgdXNpbmcgVENQJnF1b3Q7IGFuZCBldmVyeWJvZHkgd2lsbCBiZSBoYXBweS48bzpwPjwv
bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SG93IGRvZXMgdGhpcyBhcHBseSB0byBtdWx0aXBh
dGg/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N
eSBoaWdoZXItb3JkZXIgcG9pbnQgaXMgdGhhdCBtYWtpbmcgTVBUQ1AgdGhlIGJhciBpcyBjb25z
aXN0ZW50IHdpdGggd2hlcmUgdGhlIElFVEYgaXMgcmlnaHQgbm93IHdpdGggdHJhbnNwb3J0LiBJ
IGFtIHRvdGFsbHkgZm9yIGRpc2N1c3NpbmcgdGhlIG1lcml0cyBvZiByYWlzaW5nIHRoaXMgYmFy
IGluIFFVSUMsIGJ1dCBpdCBzZWVtcyBsaWtlIHRoaXMgZGlzY3Vzc2lvbiBiZWxvbmdzIGluIHRo
ZSB3Zywgd2hlcmUNCiB3ZSBjYW4gZGViYXRlIHRoZSBjb3N0IGFuZCBtZXJpdHMgb2YgZG9pbmcg
YmV0dGVyLCBhbmQgSSdtIGxvb2tpbmcgZm9yd2FyZCB0byB0aGF0IGNvbnZlcnNhdGlvbi4gVGhl
IGNoYXJ0ZXIgaXMgbGF5aW5nIG91dCB3aGF0IHRoZSBtaW5pbXVtIGJhciBpcywgYW5kIHRoZSBo
aWdoZXItb3JkZXIgZ29hbCBpcyB0byBzYXkgdGhhdCB3ZSB3b24ndCBkbyB3b3JzZSB0aGFuIFgs
IHdoZXJlIFggaXMgdGhlIHN0YXRlIG9mIHRoZSBhcnQgZm9yIElFVEYtVENQLg0KIFRoaXMgaXMg
Y3VycmVudGx5IE1QVENQLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5JIGNvdWxkIGdvIHdpdGggd2hhdCBNYXJrIGFuZCBNaWNoYWVsIHN1Z2dl
c3RlZDsgc29tZXRoaW5nIGxpa2U6ICZxdW90O1RoaXMgd29yayB3aWxsIGVuc3VyZSB0aGF0IFFV
SUMgdXNpbmcgVExTMS4zIGhhcyBzZWN1cml0eSBhbmQgcHJpdmFjeSBwcm9wZXJ0aWVzIHRoYXQg
YXJlIGF0IGxlYXN0IGFzIGdvb2QgYXMgYSBzdGFjayBjb21wb3NlZCBvZiBUTFMxLjMgdXNpbmcg
VENQIChvciBNUFRDUCB3aGVuIHVzaW5nIG11bHRpcGF0aC4pJnF1b3Q7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgZG8gZm9sa3MgdGhp
bms/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t
IGphbmE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6
Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLWhvZW56YiI+LS0gQ2hyaXN0aWFuIEh1
aXRlbWE8L3NwYW4+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_655C07320163294895BBADA28372AF5D48866E63FR712WXCHMBA15z_--


From nobody Tue May 24 06:09:19 2016
Return-Path: 
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 0187912D733 for ; Tue, 24 May 2016 06:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Eom55i0gSNP4 for ; Tue, 24 May 2016 06:09:16 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8687112D747 for ; Tue, 24 May 2016 06:07:20 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-7d-57445206e3f8
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D8.15.12516.60254475; Tue, 24 May 2016 15:07:18 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0294.000; Tue, 24 May 2016 15:07:18 +0200
From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= 
To: "Scharf, Michael (Nokia - DE)" , Jana Iyengar , Christian Huitema 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynLzG7Kc0WafEWNs7kTj2FsFJ/DSSMAgAAj/ACAAasqAIAARJaAgAAp5oCAAEbugIAAM9KAgAC6vACAAHOzAIAACk8AgAAAu4CAABQ1AIAANOgAgAAI/ICAAIbxAA==
Date: Tue, 24 May 2016 13:07:18 +0000
Message-ID: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>     <655C07320163294895BBADA28372AF5D48866E63@FR712WXCHMBA15.zeu.alcatel-lucent.com>
In-Reply-To: <655C07320163294895BBADA28372AF5D48866E63@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.4.160422
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUyM2K7vS5bkEu4wcGjqhZNn/sYLTa2vGOz mHR0IYvF+heT2Cx+XtSyWP/pMaPF7MbjLBY9C7gt5n/sZXHg9FiwqdRjyZKfTB5dF78zebTu +MvusXHxd1aPu7cuMXncaZrO7PFk/0yWAI4oLpuU1JzMstQifbsEroyVH5vYC6axVTxb+YS5 gbGBrYuRk0NCwERi7tZfjBC2mMSFe+uB4lwcQgJHGCU2XG9nhHCWMEqs+vCaFaSKTcBboq3l MAtIQkSgk1Hiyso9YC3MAo8YJV62PAWbJSygLtG8ZjYziC0ioCGxau8pJoiOSUBzb99iAkmw CKhKPL5/DczmFbCWaJ5ziAli3wMOiU0Hf4BN4hSIlfi3/y/YtYwCshL3v99jAbGZBcQlbj2Z zwRxuYDEkj3nmSFsUYmXj/+B3SoqoCfx5d48qO+UJBbd/gxUzwHUqymxfpc+hGkt8eGuHcRE RYkp3Q/ZIc4RlDg58wnLBEaJWUiWzUJonoXQPAtJ8ywkzQsYWVcxihanFhfnphsZ66UWZSYX F+fn6eWllmxiBCaBg1t+6+5gXP3a8RCjAAejEg9vQq1zuBBrYllxZe4hRgkOZiUR3lsBLuFC vCmJlVWpRfnxRaU5qcWHGKU5WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUaGNO86moShMNf 9MyVTJt6ZWKtk3Fh7lKlnyc62dhX/g5zcJryplMu0unFwWZ5gYCnr5d8tlUz+tdd9caNc3ak 5IHZ6iz5yl90nxyNE0v5fsb/hQ2Pj1zHNrb1xuGO31f1TJ3fsCpt6VpN3m9mph6KT+T2hqoo N5dO5T8Z7HV8nffSQ40GMuvXKbEUZyQaajEXFScCAGBY6Dv+AgAA
Archived-At: 
Cc: Olivier Bonaventure , Kyle Rose , Ryan Hamilton , Mark Nottingham , Brian Trammell , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 13:09:18 -0000

DQoNCj5TbyB0aGUgYmFyIGZvciBzZWN1cml0eSBhbmQgcHJpdmFjeSBpcyBUQ1AsIGluIG15IHBv
aW50IG9mIHZpZXcuDQo+QWN0dWFsbHksIHRoZXJlIGlzIG5vIG5lZWQgdG8gbWVudGlvbiBNUFRD
UCBhdCBhbGwuIElmIGxvd2VyaW5nIG9mDQo+c2VjdXJpdHkgYW5kIHByaXZhY3kgc3RhbmRhcmRz
IGNvbXBhcmVkIHRvIFRDUCBpcyByZXF1aXJlZCwgYXMgbWVudGlvbmVkDQo+YmVmb3JlLCB0aGUg
Y2hhcnRlciBjb3VsZCBtZW50aW9uIHRoYXQgdGhlIHByb3RvY29sIGRlc2lnbiBjYW4gZm9yZXNl
ZQ0KPmFkZGl0aW9uYWwsIGVudGlyZWx5IG9wdGlvbmFsIGFkZGl0aW9uYWwgcHJvdG9jb2wgZmVh
dHVyZXMsIG9uIGFuIG9wdC1pbg0KPmJhc2lzLg0KDQpJIGFtIHRyeWluZyB0byB1bmRlcnN0YW5k
IHdoYXQgeW91IGFyZSBzYXlpbmcgaGVyZTsgYSkgZG9lcyBpdCBtZWFuIHRoYXQNCnVzZXIgc2hv
dWxkIOKAnG9wdC1pbuKAnSB0byBhZGRpdGlvbmFsIGZlYXR1cmVzIGFuZCBiKSBpcyBtdWx0aSBw
YXRoIHN1Y2ggYW4NCmFkZGl0aW9uYWwg4oCcZmVhdHVyZeKAnT8NCg0KUmVnYXJkcw0KR8O2cmFu
DQoNCg==


From nobody Tue May 24 08:37:47 2016
Return-Path: 
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 B2C7412D8B1 for ; Tue, 24 May 2016 08:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level: 
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 o75y-GM__Gcj for ; Tue, 24 May 2016 08:37:44 -0700 (PDT)
Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED8C12B043 for ; Tue, 24 May 2016 08:37:43 -0700 (PDT)
Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.14.3) with ESMTP id u4OFbe3V002658; Tue, 24 May 2016 16:37:40 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1009.national.core.bbc.co.uk ([10.161.14.23]) with mapi id 14.03.0195.001; Tue, 24 May 2016 16:37:40 +0100
From: Lucas Pardue 
To: Mark Nottingham , Martin Thomson 
Thread-Topic: [QUIC] Choice of area (and scope of work)
Thread-Index: AQHRtLydHkoPws3zzU6Mtqn4p5RVj5/GEtQAgABuAgCAAANLgIAAAFqAgAAWXYCAABU8gIAABO4AgAAB0QCAAAD+gIAAKkAAgAAGxoCAAFPogIAA8zHg
Date: Tue, 24 May 2016 15:37:39 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A2A81644B@bgb01xud1012>
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>         <0AE43B24-8B4A-4F9C-AF93-F4222268E072@mnot.net>
In-Reply-To: <0AE43B24-8B4A-4F9C-AF93-F4222268E072@mnot.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.161.213]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22342.007
x-tm-as-result: No--47.795000-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: Ted Hardie , "Julian F. Reschke" , Ian Swett , Cory Benfield , Christian Huitema , Jana Iyengar , "quic@ietf.org" 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 15:37:46 -0000

Bringing this back to the original topic - the charter - is it worth adding=
 text to indicate that the scope of third focus area work includes the abil=
ity to accommodate extensions to HTTP/2. If it is possible to achieve this =
by specifying simple reusable recipes for the blocking and non-blocking cas=
es, then so much the better. Otherwise, each new extension will need to exp=
licitly specify the required mappings to h2c/h2 and h2q.

Ryan has made a suggestion to send HTTP/2 extension frames on the QUIC Head=
ers stream (stream 3). It seems sub-optimal to mix such frames, which will =
be dropped if unknown/unsupported, with the HEADERS frames. Could such fram=
es be sent on other streams, and can other streams provide in-order guarant=
ees as Martin seems to suggest?

Lucas

> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham
> Sent: 24 May 2016 02:28
> To: Martin Thomson 
> Cc: Ted Hardie ; Julian F. Reschke
> ; Ian Swett ; Cory Benfield
> ; Christian Huitema ; Jana
> Iyengar ; quic@ietf.org
> Subject: Re: [QUIC] Choice of area (and scope of work)
>=20
>=20
> > On 24 May 2016, at 6:27 AM, Martin Thomson
>  wrote:
> >
> > On 23 May 2016 at 16:03, Jana Iyengar  wrote:
> >> By extension, HTTP/2 extensions will by default extend h2 and not
> >> h2q, and may rely on TCP underneath. As a rule, I think we have to
> >> assume that they'll need to explicitly map to QUIC.
> >
> > I think that this is the safest assumption.  Extensions for "h2" don't
> > immediately port to "h2q".
> >
> > That said, we do have in order guarantees on both stream 3 and stream
> > N, so maybe, just maybe, there is a simple set of guidelines we can
> > produce that will be generally applicable to most, if not all,
> > extensions.
>=20
> +1. We should be looking at how we can minimise the differences wherever
> possible.
>=20
> --
> Mark Nottingham   https://www.mnot.net/
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic


From nobody Tue May 24 08:47:22 2016
Return-Path: 
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 91DDD12D0C7 for ; Tue, 24 May 2016 08:47:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.426
X-Spam-Level: 
X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 oHQsOUGABXyF for ; Tue, 24 May 2016 08:47:19 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 C2B2C12B02A for ; Tue, 24 May 2016 08:47:19 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id z189so47417898itg.0 for ; Tue, 24 May 2016 08:47:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bZ9zGREWavV2PHtdiuk2ap/dcabXwhWtzwPo4HAGUD4=; b=jzPX3c1UC9+p+axF++i1lR0E/0Eao8CmVB9kl9j+PMbfFGtWOrqKgw5KKco8Ji0q1T 87K1DHUAojxSht5XT3qXw3oqA8LHzudxlb5mU9VnHc/mx5y74nTzpXOwxbN3zYgOyb81 R+bczSagHJq+qMSrfkWMI8jTKTUwuao+//I/9ARibhzM/isU1iKeGxcSLWjz/yaI/wHJ wJkukxyYenwXpidjnOW3WD/PQ/TDNhSnp6XhQKm3WF1kjnc5/kyN/bxcwcmAdacqFXv0 M9065PL/I60TrEmCulwL0wZ8QRrN/QvGZbns4JACaP4yjdqTM6yZV8jBMvrPpAMmDN9K Zw5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bZ9zGREWavV2PHtdiuk2ap/dcabXwhWtzwPo4HAGUD4=; b=b3UBm/bN1t8UxromvJ7dlvn+jNvYOozRAfqlSy2YZ4WiggYi5IGsWJ/cf/1fzjkEAW KoEU6oarD0QPf9VAJewkjfGzGsQC3wknGDaXQtT7EOMbENSfoIb7FDitDk8V8xqWdQ7O J7KMZFskqvyumlQGnODhzYob1ITUqYLc5AJBLQbDQ9d+h/QZEvU4FDdcGq+2sYkKyrWh 50hNvHjCPHhu8V9/6TT8WKbyZZpzwjXgCx1zk+6hG5xT3DROkLSRpmrD5k6hvEqqSQjj euqaodfplr/v1ffd2F0NFSOPfEjpDyHl8WYUvm+3s1F27iHHGeUnCrl2IIZixHB0brao 7UYA==
X-Gm-Message-State: AOPr4FWplzSX/7aQS+W8cq3vBA1xL6xzYBIrXjYiqCGnANvVbrUzpfvAUKix4KL0sR0DqEVJqMRtFTrsXGoRF7B6
X-Received: by 10.36.66.199 with SMTP id i190mr18052113itb.30.1464104838859; Tue, 24 May 2016 08:47:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.227.227 with HTTP; Tue, 24 May 2016 08:46:59 -0700 (PDT)
In-Reply-To: 
References:    
From: Ian Swett 
Date: Tue, 24 May 2016 11:46:59 -0400
Message-ID: 
To: =?UTF-8?Q?G=C3=B6ran_Eriksson_AP?= 
Content-Type: multipart/alternative; boundary=001a1144b132d5f85c05339878bc
Archived-At: 
Cc: Jana Iyengar , Mark Nottingham , "quic@ietf.org" 
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 15:47:21 -0000

--001a1144b132d5f85c05339878bc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Mark, I think I understand the confusion.  You're thinking of a third
feature advertisement that's separate from version negotiation and options
negotiation.

To provide some examples:
1) Version negotiation: Allows changing critical protocol elements, such as
what the encoding of the public flags mean.  For example, one could imagine
we decide QUIC needs 0, 8 or 16 byte connection ids.  That would require
protocol version negotiation.
2) Option negotiation:  Allows adding new functionality, likely within the
encrypted envelope.  For example, the ability to do multipath or FEC or any
transport level feature.  This allows different organizations to experiment
with different features, similar to how TCP does with options, but without
the deployment challenges of unencrypted TCP options.
3) Application level negotiation: This would be specific to the application
running on top of QUIC, and hopefully as Ryan said, would be in the scope
of any mapping document.

On Tue, May 24, 2016 at 1:51 AM, G=C3=B6ran Eriksson AP <
goran.ap.eriksson@ericsson.com> wrote:

>
> >I can see multipath as "configurable" protocol behavior; if folks think
> >thats reasonable, I'm fine with using "configuration" instead of "option=
s
> >negotiation".
>
> I understand that to mean QUIC can be =E2=80=9Cconfigured=E2=80=9D to be =
turned on or off
> multi path at least, or more advanced, detailed configuration of it multi
> path selection?
>
> Regards
> G=C3=B6ran
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>

--001a1144b132d5f85c05339878bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Mark, I think I understand the confusion.=C2=A0 You're=
 thinking of a third feature advertisement that's separate from version=
 negotiation and options negotiation.

To provide some ex=
amples:
1) Version negotiation: Allows changing critical protocol=
 elements, such as what the encoding of the public flags mean.=C2=A0 For ex=
ample, one could imagine we decide QUIC needs 0, 8 or 16 byte connection id=
s.=C2=A0 That would require protocol version negotiation.
2) Opti=
on negotiation: =C2=A0Allows adding new functionality, likely within the en=
crypted envelope.=C2=A0 For example, the ability to do multipath or FEC or =
any transport level feature.=C2=A0 This allows different organizations to e=
xperiment with different features, similar to how TCP does with options, bu=
t without the deployment challenges of unencrypted TCP options.
3=
) Application level negotiation: This would be specific to the application =
running on top of QUIC, and hopefully as Ryan said, would be in the scope o=
f any mapping document.

On Tue, May 24, 2016 at 1:51 AM, G=C3=B6ran Eriksson AP <=
span dir=3D"ltr"><goran.ap.eriksson@ericsson.com> wrote:


>I can see multipath as "configurable" protocol behavior; if f=
olks think

>thats reasonable, I'm fine with using "configuration" ins=
tead of "options

>negotiation".



I understand that to mean QUIC can be =E2=80=9Cconfigured=E2=80=9D t=
o be turned on or off

multi path at least, or more advanced, detailed configuration of it multi
path selection?



Regards

G=C3=B6ran




_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--001a1144b132d5f85c05339878bc--


From nobody Tue May 24 08:54:40 2016
Return-Path: 
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 0507412D882 for ; Tue, 24 May 2016 08:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 oH6Lz2puVl8f for ; Tue, 24 May 2016 08:54:35 -0700 (PDT)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 BB28C12B02A for ; Tue, 24 May 2016 08:54:35 -0700 (PDT)
Received: by mail-io0-x22e.google.com with SMTP id f8so14751748ioe.3 for ; Tue, 24 May 2016 08:54:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i//q0bK6o1N9zb8tq7oeFCqJ3svaWDWZE9uACQus+NM=; b=kbOg7a4BAYBvdH7Nkd49iQ8/RhXlimqE4CM7UX8TNXzJnx3Zb3FUEm1TZdnwWND/AE gd3kDzt1HNuiiG5O9B9waohy4avMoTx9vUQfoOXQpkmFrFUbC96tLtUJHYH5mwamZH/o ev7LZB+loPy/+J6saIDWwhe8QLhSKH0UeGDlzkqNUFXA0ZL/JxeKu1vuGJ1CesYn2QOs oyLGieF/IUx0xp/Q60BotdOHF1ZpWbuYbJ6citBvMa8w8zjo4IY+rOWx8KXzERYMAg4b +x1LiCQjyhJ0Y8gn6zJlJIn/isBuZtjqL/orofkC587Gif/cnBEmG+QT5F2N5pPsh4mA 6q6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i//q0bK6o1N9zb8tq7oeFCqJ3svaWDWZE9uACQus+NM=; b=HPnsiD3VALflv1c+0LROsfiXb/JZeHXgp0fsBv/kwYN9HCG0Pn6mTq+1/gcAEFj1MQ DYeD9OWlP2fdPqs8dfPVvJ3IkP1sTDFXIRZIjipTG5E9bW5GDRegNP46hGwI+6pYAIgs 5xBJpwutFs+GGhx+6P3NFHj25D2p+vZ0IiTbe3TL2dHu2coeVDgDM20hsCWW1Igo37tQ 2WSxY7/kEEyJYLvsMA/KVtZBiD9gTtxRBxWHOFJsbUPC2S8hRp17IReWZmAA2NvuI5Fv cY0L2UZxCKkLGuMnW2WyOKIUAP3W33NQ06H0OEao9JvQSODQhZSdQTCgTqUCOTDo7cJL EP9g==
X-Gm-Message-State: AOPr4FX1pjhnzlwRUcdCXZLTT3uQEVhaqsT+lSgV+OdlP8IOTEqHSYX/OiaENM4WeBcN9NOUp9Pr1G2UHMlChmTT
X-Received: by 10.107.140.133 with SMTP id o127mr18064628iod.32.1464105274927;  Tue, 24 May 2016 08:54:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.227.227 with HTTP; Tue, 24 May 2016 08:54:15 -0700 (PDT)
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A2A81644B@bgb01xud1012>
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>         <0AE43B24-8B4A-4F9C-AF93-F4222268E072@mnot.net> <7CF7F94CB496BF4FAB1676F375F9666A2A81644B@bgb01xud1012>
From: Ian Swett 
Date: Tue, 24 May 2016 11:54:15 -0400
Message-ID: 
To: Lucas Pardue 
Content-Type: multipart/alternative; boundary=94eb2c05c948d3b85b0533989207
Archived-At: 
Cc: Ted Hardie , "Julian F. Reschke" , Cory Benfield , Mark Nottingham , Jana Iyengar , Christian Huitema , "quic@ietf.org" , Martin Thomson 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 15:54:38 -0000

--94eb2c05c948d3b85b0533989207
Content-Type: text/plain; charset=UTF-8

All streams guarantee in order delivery, so HTTP/2 extension frames could
be sent on a different stream if desired.

QUIC definitely needs to be able to accommodate extensions to H2, otherwise
it's not really supporting H2.  That could be stated explicitly if it's
important to clarify?

On Tue, May 24, 2016 at 11:37 AM, Lucas Pardue 
wrote:

> Bringing this back to the original topic - the charter - is it worth
> adding text to indicate that the scope of third focus area work includes
> the ability to accommodate extensions to HTTP/2. If it is possible to
> achieve this by specifying simple reusable recipes for the blocking and
> non-blocking cases, then so much the better. Otherwise, each new extension
> will need to explicitly specify the required mappings to h2c/h2 and h2q.
>
> Ryan has made a suggestion to send HTTP/2 extension frames on the QUIC
> Headers stream (stream 3). It seems sub-optimal to mix such frames, which
> will be dropped if unknown/unsupported, with the HEADERS frames. Could such
> frames be sent on other streams, and can other streams provide in-order
> guarantees as Martin seems to suggest?
>
> Lucas
>
> > -----Original Message-----
> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham
> > Sent: 24 May 2016 02:28
> > To: Martin Thomson 
> > Cc: Ted Hardie ; Julian F. Reschke
> > ; Ian Swett ; Cory Benfield
> > ; Christian Huitema ; Jana
> > Iyengar ; quic@ietf.org
> > Subject: Re: [QUIC] Choice of area (and scope of work)
> >
> >
> > > On 24 May 2016, at 6:27 AM, Martin Thomson
> >  wrote:
> > >
> > > On 23 May 2016 at 16:03, Jana Iyengar  wrote:
> > >> By extension, HTTP/2 extensions will by default extend h2 and not
> > >> h2q, and may rely on TCP underneath. As a rule, I think we have to
> > >> assume that they'll need to explicitly map to QUIC.
> > >
> > > I think that this is the safest assumption.  Extensions for "h2" don't
> > > immediately port to "h2q".
> > >
> > > That said, we do have in order guarantees on both stream 3 and stream
> > > N, so maybe, just maybe, there is a simple set of guidelines we can
> > > produce that will be generally applicable to most, if not all,
> > > extensions.
> >
> > +1. We should be looking at how we can minimise the differences wherever
> > possible.
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
> > _______________________________________________
> > QUIC mailing list
> > QUIC@ietf.org
> > https://www.ietf.org/mailman/listinfo/quic
>

--94eb2c05c948d3b85b0533989207
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


All streams guarantee in order delivery, so HTTP/2 extensi=
on frames could be sent on a different stream if desired. =C2=A0

QUIC definitely needs to be able to accommodate extensions to H2, =
otherwise it's not really supporting H2.=C2=A0 That could be stated exp=
licitly if it's important to clarify?

On Tue, May 24, 2016 at 11:37 AM, Lucas=
 Pardue <Lucas.Pardue@bbc.co.uk> wrote:
Bringing this back to the original topic - the charter -=
 is it worth adding text to indicate that the scope of third focus area wor=
k includes the ability to accommodate extensions to HTTP/2. If it is possib=
le to achieve this by specifying simple reusable recipes for the blocking a=
nd non-blocking cases, then so much the better. Otherwise, each new extensi=
on will need to explicitly specify the required mappings to h2c/h2 and h2q.=




Ryan has made a suggestion to send HTTP/2 extension frames on the QUIC Head=
ers stream (stream 3). It seems sub-optimal to mix such frames, which will =
be dropped if unknown/unsupported, with the HEADERS frames. Could such fram=
es be sent on other streams, and can other streams provide in-order guarant=
ees as Martin seems to suggest?



Lucas




> -----Original Message-----

> From: QUIC [mailto:quic-bounc=
es@ietf.org] On Behalf Of Mark Nottingham

> Sent: 24 May 2016 02:28

> To: Martin Thomson <mar=
tin.thomson@gmail.com>

> Cc: Ted Hardie <ted.ietf@gmai=
l.com>; Julian F. Reschke

> <julian.reschke@gmx.de=
>; Ian Swett <ianswett@google.=
com>; Cory Benfield

> <cory@lukasa.co.uk>; Ch=
ristian Huitema <huitema@micros=
oft.com>; Jana

> Iyengar <jri@google.com>; =
quic@ietf.org

> Subject: Re: [QUIC] Choice of area (and scope of work)

>

>

> > On 24 May 2016, at 6:27 AM, Martin Thomson

> <martin.thomson@gmail.c=
om> wrote:

> >

> > On 23 May 2016 at 16:03, Jana Iyengar <jri@google.com> wrote:

> >> By extension, HTTP/2 extensions will by default extend h2 and=
 not

> >> h2q, and may rely on TCP underneath. As a rule, I think we ha=
ve to

> >> assume that they'll need to explicitly map to QUIC.

> >

> > I think that this is the safest assumption.=C2=A0 Extensions for =
"h2" don't

> > immediately port to "h2q".

> >

> > That said, we do have in order guarantees on both stream 3 and st=
ream

> > N, so maybe, just maybe, there is a simple set of guidelines we c=
an

> > produce that will be generally applicable to most, if not all,
> > extensions.

>

> +1. We should be looking at how we can minimise the differences wherev=
er

> possible.

>

> --

> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

>


> __________________=
_____________________________

> QUIC mailing list

> QUIC@ietf.org

> https://www.ietf.org/mailman/listinfo/quic





--94eb2c05c948d3b85b0533989207--


From nobody Tue May 24 09:22:39 2016
Return-Path: 
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 1A72A12D844 for ; Tue, 24 May 2016 09:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 6TixkJPQ6N05 for ; Tue, 24 May 2016 09:22:36 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 716E512D7A8 for ; Tue, 24 May 2016 09:22:36 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id z189so48040607itg.0 for ; Tue, 24 May 2016 09:22:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=pC5p8o6Cnmu+mWnv/WUhzglI/EgLGKoU8Ux2dkB1L1g=; b=fUxo9CHHG4SDlGjVpWqbKFh1KR60RSDR4Alg3BpMhOIfYI/jNVzJdk04CBsPAy8ZMH 7eHdd18tP95aLmHMVqUy5kk/oxAkkQxPV4kOuyS/UcOrUAw28T8aYwWFYn4rs8DuN/Et 9p/sj88vxN1GpdXo+Hs4yr473CJ37BKgyiFTdFcxKlJ1QwQdcGLMoe4ZzLJ765zmxZul 06itRsohbRRcQomESa0iF6leovb2foVQkeihEYp7jKz+7oxcguQcRgHczPRv1yaS9Gwt 1K8P2RCNS2igs/4Cr30yhJXGQG2cBdO9MBQ0Jgpjq5LQmGygtptbdEQVZFfvGQB/LkcN Ohfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=pC5p8o6Cnmu+mWnv/WUhzglI/EgLGKoU8Ux2dkB1L1g=; b=Y4AUXptyjP8cF3RjzVC1hE+PV8dBFwE9JyiuWFy2/j7GkFARmnNxXdHSr5p2YzPSCk b5N/GcAx1P0wVR3ZlmDWoRUZc7ryRQH5O0FT4S+gJVRBiuPSXd2XR1HV1z9dHh34+pkI UZCQPGOnXL28eN8aN1zEy0D7UPRW8wPdqjlEt7KJBY6GdMpATU1IU7hHSWmcFBakKUS3 z6xrsrARmKlhzGObpI7yb2ko66vIVTCUSGPJPWSLO/HYIQ4J/srya76IM762pCcZ5O09 y0UCd6kDg+oDdsm50gbpSaitGVPMSl7TkqqccaQXMd070dAi7O9UC+O2hXbp9OyniZ4F we7Q==
X-Gm-Message-State: AOPr4FWmQVPh2zzziFX3Y4Khu8QrbwCs8nEuYxHlolhfcDSn5nuiRP+AyaqGRVPIAxSTDI9VF9uVw7VDDvgLYw==
MIME-Version: 1.0
X-Received: by 10.36.9.129 with SMTP id 123mr18150258itm.68.1464106955429; Tue, 24 May 2016 09:22:35 -0700 (PDT)
Received: by 10.36.43.23 with HTTP; Tue, 24 May 2016 09:22:35 -0700 (PDT)
In-Reply-To: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>    
Date: Tue, 24 May 2016 09:22:35 -0700
Message-ID: 
From: Martin Thomson 
To: Jana Iyengar 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Olivier Bonaventure , "Scharf, Michael \(Nokia - DE\)" , Kyle Rose , Ryan Hamilton , Mark Nottingham , Brian Trammell , Christian Huitema , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 16:22:38 -0000

On 23 May 2016 at 23:32, Jana Iyengar  wrote:
> I could go with what Mark and Michael suggested; something like: "This work
> will ensure that QUIC using TLS1.3 has security and privacy properties that
> are at least as good as a stack composed of TLS1.3 using TCP (or MPTCP when
> using multipath.)"

I disagree with the implication that MPTCP or even TCP is good enough.
It's been a little while, we've learned a few things about the world
and how to design protocols that retain important things like privacy
and security without sacrificing other goals, like performance.

This text sets a pretty low bar.  Too low perhaps.  But I don't know
for sure right now because I don't have the entire design space mapped
out.  And a charter discussion isn't the place for that (thanks
Rich!).  How about we not try to decide the outcome of the discussion
and simply say that we will design for the optimum tradeoff between
functionality, performance, security and privacy.  In other words, we
will do our jobs.

I propose: "This work will address security and privacy issues arising
from the protocol design." and leave it at that.


From nobody Tue May 24 09:51:46 2016
Return-Path: 
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 32DA712D8EF for ; Tue, 24 May 2016 09:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 4_YSP1UwAZjO for ; Tue, 24 May 2016 09:50:01 -0700 (PDT)
Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6D712D147 for ; Tue, 24 May 2016 09:49:56 -0700 (PDT)
Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.14.3) with ESMTP id u4OGavgK023720; Tue, 24 May 2016 17:36:57 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1011.national.core.bbc.co.uk ([10.161.14.15]) with mapi id 14.03.0195.001; Tue, 24 May 2016 17:36:57 +0100
From: Lucas Pardue 
To: Ian Swett 
Thread-Topic: [QUIC] Choice of area (and scope of work)
Thread-Index: AQHRtLydHkoPws3zzU6Mtqn4p5RVj5/GEtQAgABuAgCAAANLgIAAAFqAgAAWXYCAABU8gIAABO4AgAAB0QCAAAD+gIAAKkAAgAAGxoCAAFPogIAA8zHg///+3oCAABH1EA==
Date: Tue, 24 May 2016 16:36:57 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A2A818487@bgb01xud1012>
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>         <0AE43B24-8B4A-4F9C-AF93-F4222268E072@mnot.net> <7CF7F94CB496BF4FAB1676F375F9666A2A81644B@bgb01xud1012> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.161.213]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22344.000
x-tm-as-result: No--50.628500-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A2A818487bgb01xud1012_"
MIME-Version: 1.0
Archived-At: 
Cc: Ted Hardie , "Julian F. Reschke" , Cory Benfield , Mark Nottingham , Jana Iyengar , Christian Huitema , "quic@ietf.org" , Martin Thomson 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 16:50:43 -0000
X-List-Received-Date: Tue, 24 May 2016 16:50:43 -0000

--_000_7CF7F94CB496BF4FAB1676F375F9666A2A818487bgb01xud1012_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB0aGluayBhIHNpbXBsZSBzZW50ZW5jZSBpbiB0aGUgcGFyYWdyYXBoIGRpc2N1c3NpbmcgdGhl
IHRoaXJkIGZvY3VzIGFyZWEgd291bGQgc3VmZmljZS4gU29tZXRoaW5nIHN1Y2ggYXM6DQoNCuKA
nFRoaXMgbWFwcGluZyB3aWxsIGFjY29tbW9kYXRlIHRoZSBleHRlbnNpb24gbWVjaGFuaXNtcyBk
ZWZpbmVkIGluIHRoZSBIVFRQLzIgc3BlY2lmaWNhdGlvbi7igJ0NCg0KTHVjYXMNCg0KRnJvbTog
SWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NClNlbnQ6IDI0IE1heSAyMDE2
IDE2OjU0DQpUbzogTHVjYXMgUGFyZHVlIDxMdWNhcy5QYXJkdWVAYmJjLmNvLnVrPg0KQ2M6IE1h
cmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldD47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhv
bXNvbkBnbWFpbC5jb20+OyBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+OyBKdWxpYW4g
Ri4gUmVzY2hrZSA8anVsaWFuLnJlc2Noa2VAZ214LmRlPjsgQ29yeSBCZW5maWVsZCA8Y29yeUBs
dWthc2EuY28udWs+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBtaWNyb3NvZnQuY29tPjsg
SmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl
OiBbUVVJQ10gQ2hvaWNlIG9mIGFyZWEgKGFuZCBzY29wZSBvZiB3b3JrKQ0KDQpBbGwgc3RyZWFt
cyBndWFyYW50ZWUgaW4gb3JkZXIgZGVsaXZlcnksIHNvIEhUVFAvMiBleHRlbnNpb24gZnJhbWVz
IGNvdWxkIGJlIHNlbnQgb24gYSBkaWZmZXJlbnQgc3RyZWFtIGlmIGRlc2lyZWQuDQoNClFVSUMg
ZGVmaW5pdGVseSBuZWVkcyB0byBiZSBhYmxlIHRvIGFjY29tbW9kYXRlIGV4dGVuc2lvbnMgdG8g
SDIsIG90aGVyd2lzZSBpdCdzIG5vdCByZWFsbHkgc3VwcG9ydGluZyBIMi4gIFRoYXQgY291bGQg
YmUgc3RhdGVkIGV4cGxpY2l0bHkgaWYgaXQncyBpbXBvcnRhbnQgdG8gY2xhcmlmeT8NCg0KT24g
VHVlLCBNYXkgMjQsIDIwMTYgYXQgMTE6MzcgQU0sIEx1Y2FzIFBhcmR1ZSA8THVjYXMuUGFyZHVl
QGJiYy5jby51azxtYWlsdG86THVjYXMuUGFyZHVlQGJiYy5jby51az4+IHdyb3RlOg0KQnJpbmdp
bmcgdGhpcyBiYWNrIHRvIHRoZSBvcmlnaW5hbCB0b3BpYyAtIHRoZSBjaGFydGVyIC0gaXMgaXQg
d29ydGggYWRkaW5nIHRleHQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgc2NvcGUgb2YgdGhpcmQgZm9j
dXMgYXJlYSB3b3JrIGluY2x1ZGVzIHRoZSBhYmlsaXR5IHRvIGFjY29tbW9kYXRlIGV4dGVuc2lv
bnMgdG8gSFRUUC8yLiBJZiBpdCBpcyBwb3NzaWJsZSB0byBhY2hpZXZlIHRoaXMgYnkgc3BlY2lm
eWluZyBzaW1wbGUgcmV1c2FibGUgcmVjaXBlcyBmb3IgdGhlIGJsb2NraW5nIGFuZCBub24tYmxv
Y2tpbmcgY2FzZXMsIHRoZW4gc28gbXVjaCB0aGUgYmV0dGVyLiBPdGhlcndpc2UsIGVhY2ggbmV3
IGV4dGVuc2lvbiB3aWxsIG5lZWQgdG8gZXhwbGljaXRseSBzcGVjaWZ5IHRoZSByZXF1aXJlZCBt
YXBwaW5ncyB0byBoMmMvaDIgYW5kIGgycS4NCg0KUnlhbiBoYXMgbWFkZSBhIHN1Z2dlc3Rpb24g
dG8gc2VuZCBIVFRQLzIgZXh0ZW5zaW9uIGZyYW1lcyBvbiB0aGUgUVVJQyBIZWFkZXJzIHN0cmVh
bSAoc3RyZWFtIDMpLiBJdCBzZWVtcyBzdWItb3B0aW1hbCB0byBtaXggc3VjaCBmcmFtZXMsIHdo
aWNoIHdpbGwgYmUgZHJvcHBlZCBpZiB1bmtub3duL3Vuc3VwcG9ydGVkLCB3aXRoIHRoZSBIRUFE
RVJTIGZyYW1lcy4gQ291bGQgc3VjaCBmcmFtZXMgYmUgc2VudCBvbiBvdGhlciBzdHJlYW1zLCBh
bmQgY2FuIG90aGVyIHN0cmVhbXMgcHJvdmlkZSBpbi1vcmRlciBndWFyYW50ZWVzIGFzIE1hcnRp
biBzZWVtcyB0byBzdWdnZXN0Pw0KDQpMdWNhcw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+IEZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1
aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBNYXJrIE5vdHRpbmdoYW0NCj4gU2Vu
dDogMjQgTWF5IDIwMTYgMDI6MjgNCj4gVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNv
bkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+DQo+IENjOiBUZWQg
SGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbT4+OyBK
dWxpYW4gRi4gUmVzY2hrZQ0KPiA8anVsaWFuLnJlc2Noa2VAZ214LmRlPG1haWx0bzpqdWxpYW4u
cmVzY2hrZUBnbXguZGU+PjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzpp
YW5zd2V0dEBnb29nbGUuY29tPj47IENvcnkgQmVuZmllbGQNCj4gPGNvcnlAbHVrYXNhLmNvLnVr
PG1haWx0bzpjb3J5QGx1a2FzYS5jby51az4+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBt
aWNyb3NvZnQuY29tPG1haWx0bzpodWl0ZW1hQG1pY3Jvc29mdC5jb20+PjsgSmFuYQ0KPiBJeWVu
Z2FyIDxqcmlAZ29vZ2xlLmNvbTxtYWlsdG86anJpQGdvb2dsZS5jb20+PjsgcXVpY0BpZXRmLm9y
ZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtRVUlDXSBDaG9pY2Ugb2Yg
YXJlYSAoYW5kIHNjb3BlIG9mIHdvcmspDQo+DQo+DQo+ID4gT24gMjQgTWF5IDIwMTYsIGF0IDY6
MjcgQU0sIE1hcnRpbiBUaG9tc29uDQo+IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRv
Om1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4gT24gMjMgTWF5IDIw
MTYgYXQgMTY6MDMsIEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29n
bGUuY29tPj4gd3JvdGU6DQo+ID4+IEJ5IGV4dGVuc2lvbiwgSFRUUC8yIGV4dGVuc2lvbnMgd2ls
bCBieSBkZWZhdWx0IGV4dGVuZCBoMiBhbmQgbm90DQo+ID4+IGgycSwgYW5kIG1heSByZWx5IG9u
IFRDUCB1bmRlcm5lYXRoLiBBcyBhIHJ1bGUsIEkgdGhpbmsgd2UgaGF2ZSB0bw0KPiA+PiBhc3N1
bWUgdGhhdCB0aGV5J2xsIG5lZWQgdG8gZXhwbGljaXRseSBtYXAgdG8gUVVJQy4NCj4gPg0KPiA+
IEkgdGhpbmsgdGhhdCB0aGlzIGlzIHRoZSBzYWZlc3QgYXNzdW1wdGlvbi4gIEV4dGVuc2lvbnMg
Zm9yICJoMiIgZG9uJ3QNCj4gPiBpbW1lZGlhdGVseSBwb3J0IHRvICJoMnEiLg0KPiA+DQo+ID4g
VGhhdCBzYWlkLCB3ZSBkbyBoYXZlIGluIG9yZGVyIGd1YXJhbnRlZXMgb24gYm90aCBzdHJlYW0g
MyBhbmQgc3RyZWFtDQo+ID4gTiwgc28gbWF5YmUsIGp1c3QgbWF5YmUsIHRoZXJlIGlzIGEgc2lt
cGxlIHNldCBvZiBndWlkZWxpbmVzIHdlIGNhbg0KPiA+IHByb2R1Y2UgdGhhdCB3aWxsIGJlIGdl
bmVyYWxseSBhcHBsaWNhYmxlIHRvIG1vc3QsIGlmIG5vdCBhbGwsDQo+ID4gZXh0ZW5zaW9ucy4N
Cj4NCj4gKzEuIFdlIHNob3VsZCBiZSBsb29raW5nIGF0IGhvdyB3ZSBjYW4gbWluaW1pc2UgdGhl
IGRpZmZlcmVuY2VzIHdoZXJldmVyDQo+IHBvc3NpYmxlLg0KPg0KPiAtLQ0KPiBNYXJrIE5vdHRp
bmdoYW0gICBodHRwczovL3d3dy5tbm90Lm5ldC8NCj4NCj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUVVJQyBtYWlsaW5nIGxpc3QNCj4gUVVJQ0Bp
ZXRmLm9yZzxtYWlsdG86UVVJQ0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9xdWljDQoNCg==

--_000_7CF7F94CB496BF4FAB1676F375F9666A2A818487bgb01xud1012_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z
by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj
b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v
bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp
bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl
OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu
ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk
aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+
PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1
ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J
IHRoaW5rIGEgc2ltcGxlIHNlbnRlbmNlIGluIHRoZSBwYXJhZ3JhcGggZGlzY3Vzc2luZyB0aGUg
dGhpcmQgZm9jdXMgYXJlYSB3b3VsZCBzdWZmaWNlLiBTb21ldGhpbmcgc3VjaCBhczo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+4oCcVGhpcyBtYXBwaW5nIHdpbGwgYWNjb21tb2RhdGUgdGhlIGV4dGVuc2lvbiBtZWNo
YW5pc21zIGRlZmluZWQgaW4gdGhlIEhUVFAvMiBzcGVjaWZpY2F0aW9uLuKAnTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij5MdWNhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1
ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw
Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy
b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0
dEBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI0IE1heSAyMDE2IDE2OjU0PGJyPg0K
PGI+VG86PC9iPiBMdWNhcyBQYXJkdWUgJmx0O0x1Y2FzLlBhcmR1ZUBiYmMuY28udWsmZ3Q7PGJy
Pg0KPGI+Q2M6PC9iPiBNYXJrIE5vdHRpbmdoYW0gJmx0O21ub3RAbW5vdC5uZXQmZ3Q7OyBNYXJ0
aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0OzsgVGVkIEhhcmRpZSAm
bHQ7dGVkLmlldGZAZ21haWwuY29tJmd0OzsgSnVsaWFuIEYuIFJlc2Noa2UgJmx0O2p1bGlhbi5y
ZXNjaGtlQGdteC5kZSZndDs7IENvcnkgQmVuZmllbGQgJmx0O2NvcnlAbHVrYXNhLmNvLnVrJmd0
OzsgQ2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAbWljcm9zb2Z0LmNvbSZndDs7IEphbmEg
SXllbmdhciAmbHQ7anJpQGdvb2dsZS5jb20mZ3Q7Ow0KIHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFtRVUlDXSBDaG9pY2Ugb2YgYXJlYSAoYW5kIHNjb3BlIG9mIHdvcmsp
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFs
bCBzdHJlYW1zIGd1YXJhbnRlZSBpbiBvcmRlciBkZWxpdmVyeSwgc28gSFRUUC8yIGV4dGVuc2lv
biBmcmFtZXMgY291bGQgYmUgc2VudCBvbiBhIGRpZmZlcmVudCBzdHJlYW0gaWYgZGVzaXJlZC4g
Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5RVUlD
IGRlZmluaXRlbHkgbmVlZHMgdG8gYmUgYWJsZSB0byBhY2NvbW1vZGF0ZSBleHRlbnNpb25zIHRv
IEgyLCBvdGhlcndpc2UgaXQncyBub3QgcmVhbGx5IHN1cHBvcnRpbmcgSDIuJm5ic3A7IFRoYXQg
Y291bGQgYmUgc3RhdGVkIGV4cGxpY2l0bHkgaWYgaXQncyBpbXBvcnRhbnQgdG8gY2xhcmlmeT88
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
VHVlLCBNYXkgMjQsIDIwMTYgYXQgMTE6MzcgQU0sIEx1Y2FzIFBhcmR1ZSAmbHQ7PGEgaHJlZj0i
bWFpbHRvOkx1Y2FzLlBhcmR1ZUBiYmMuY28udWsiIHRhcmdldD0iX2JsYW5rIj5MdWNhcy5QYXJk
dWVAYmJjLmNvLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkJyaW5naW5nIHRoaXMgYmFjayB0byB0aGUgb3JpZ2luYWwgdG9waWMgLSB0aGUgY2hhcnRlciAt
IGlzIGl0IHdvcnRoIGFkZGluZyB0ZXh0IHRvIGluZGljYXRlIHRoYXQgdGhlIHNjb3BlIG9mIHRo
aXJkIGZvY3VzIGFyZWEgd29yayBpbmNsdWRlcyB0aGUgYWJpbGl0eSB0byBhY2NvbW1vZGF0ZSBl
eHRlbnNpb25zIHRvIEhUVFAvMi4gSWYgaXQgaXMgcG9zc2libGUgdG8gYWNoaWV2ZSB0aGlzIGJ5
IHNwZWNpZnlpbmcNCiBzaW1wbGUgcmV1c2FibGUgcmVjaXBlcyBmb3IgdGhlIGJsb2NraW5nIGFu
ZCBub24tYmxvY2tpbmcgY2FzZXMsIHRoZW4gc28gbXVjaCB0aGUgYmV0dGVyLiBPdGhlcndpc2Us
IGVhY2ggbmV3IGV4dGVuc2lvbiB3aWxsIG5lZWQgdG8gZXhwbGljaXRseSBzcGVjaWZ5IHRoZSBy
ZXF1aXJlZCBtYXBwaW5ncyB0byBoMmMvaDIgYW5kIGgycS48YnI+DQo8YnI+DQpSeWFuIGhhcyBt
YWRlIGEgc3VnZ2VzdGlvbiB0byBzZW5kIEhUVFAvMiBleHRlbnNpb24gZnJhbWVzIG9uIHRoZSBR
VUlDIEhlYWRlcnMgc3RyZWFtIChzdHJlYW0gMykuIEl0IHNlZW1zIHN1Yi1vcHRpbWFsIHRvIG1p
eCBzdWNoIGZyYW1lcywgd2hpY2ggd2lsbCBiZSBkcm9wcGVkIGlmIHVua25vd24vdW5zdXBwb3J0
ZWQsIHdpdGggdGhlIEhFQURFUlMgZnJhbWVzLiBDb3VsZCBzdWNoIGZyYW1lcyBiZSBzZW50IG9u
IG90aGVyIHN0cmVhbXMsIGFuZA0KIGNhbiBvdGhlciBzdHJlYW1zIHByb3ZpZGUgaW4tb3JkZXIg
Z3VhcmFudGVlcyBhcyBNYXJ0aW4gc2VlbXMgdG8gc3VnZ2VzdD88YnI+DQo8c3BhbiBzdHlsZT0i
Y29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+THVjYXM8L3NwYW4+PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBRVUlD
IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3Vu
Y2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE1hcmsgTm90dGluZ2hhbTxicj4NCiZndDsg
U2VudDogMjQgTWF5IDIwMTYgMDI6Mjg8YnI+DQomZ3Q7IFRvOiBNYXJ0aW4gVGhvbXNvbiAmbHQ7
PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSI+bWFydGluLnRob21zb25A
Z21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7IENjOiBUZWQgSGFyZGllICZsdDs8YSBocmVmPSJt
YWlsdG86dGVkLmlldGZAZ21haWwuY29tIj50ZWQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OzsgSnVs
aWFuIEYuIFJlc2Noa2U8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86anVsaWFuLnJlc2No
a2VAZ214LmRlIj5qdWxpYW4ucmVzY2hrZUBnbXguZGU8L2E+Jmd0OzsgSWFuIFN3ZXR0ICZsdDs8
YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSI+aWFuc3dldHRAZ29vZ2xlLmNvbTwv
YT4mZ3Q7OyBDb3J5IEJlbmZpZWxkPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcnlA
bHVrYXNhLmNvLnVrIj5jb3J5QGx1a2FzYS5jby51azwvYT4mZ3Q7OyBDaHJpc3RpYW4gSHVpdGVt
YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAbWljcm9zb2Z0LmNvbSI+aHVpdGVtYUBtaWNy
b3NvZnQuY29tPC9hPiZndDs7IEphbmE8YnI+DQomZ3Q7IEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1h
aWx0bzpqcmlAZ29vZ2xlLmNvbSI+anJpQGdvb2dsZS5jb208L2E+Jmd0OzsgPGEgaHJlZj0ibWFp
bHRvOnF1aWNAaWV0Zi5vcmciPg0KcXVpY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6
IFJlOiBbUVVJQ10gQ2hvaWNlIG9mIGFyZWEgKGFuZCBzY29wZSBvZiB3b3JrKTxicj4NCiZndDs8
YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIDI0IE1heSAyMDE2LCBhdCA2OjI3IEFNLCBNYXJ0
aW4gVGhvbXNvbjxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBn
bWFpbC5jb20iPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPbiAyMyBNYXkgMjAxNiBhdCAxNjowMywgSmFuYSBJeWVu
Z2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iPmpyaUBnb29nbGUuY29tPC9h
PiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBCeSBleHRlbnNpb24sIEhUVFAvMiBleHRl
bnNpb25zIHdpbGwgYnkgZGVmYXVsdCBleHRlbmQgaDIgYW5kIG5vdDxicj4NCiZndDsgJmd0OyZn
dDsgaDJxLCBhbmQgbWF5IHJlbHkgb24gVENQIHVuZGVybmVhdGguIEFzIGEgcnVsZSwgSSB0aGlu
ayB3ZSBoYXZlIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhc3N1bWUgdGhhdCB0aGV5J2xsIG5lZWQg
dG8gZXhwbGljaXRseSBtYXAgdG8gUVVJQy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg
SSB0aGluayB0aGF0IHRoaXMgaXMgdGhlIHNhZmVzdCBhc3N1bXB0aW9uLiZuYnNwOyBFeHRlbnNp
b25zIGZvciAmcXVvdDtoMiZxdW90OyBkb24ndDxicj4NCiZndDsgJmd0OyBpbW1lZGlhdGVseSBw
b3J0IHRvICZxdW90O2gycSZxdW90Oy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhh
dCBzYWlkLCB3ZSBkbyBoYXZlIGluIG9yZGVyIGd1YXJhbnRlZXMgb24gYm90aCBzdHJlYW0gMyBh
bmQgc3RyZWFtPGJyPg0KJmd0OyAmZ3Q7IE4sIHNvIG1heWJlLCBqdXN0IG1heWJlLCB0aGVyZSBp
cyBhIHNpbXBsZSBzZXQgb2YgZ3VpZGVsaW5lcyB3ZSBjYW48YnI+DQomZ3Q7ICZndDsgcHJvZHVj
ZSB0aGF0IHdpbGwgYmUgZ2VuZXJhbGx5IGFwcGxpY2FibGUgdG8gbW9zdCwgaWYgbm90IGFsbCw8
YnI+DQomZ3Q7ICZndDsgZXh0ZW5zaW9ucy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmIzQzOzEuIFdl
IHNob3VsZCBiZSBsb29raW5nIGF0IGhvdyB3ZSBjYW4gbWluaW1pc2UgdGhlIGRpZmZlcmVuY2Vz
IHdoZXJldmVyPGJyPg0KJmd0OyBwb3NzaWJsZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4N
CiZndDsgTWFyayBOb3R0aW5naGFtJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3Lm1u
b3QubmV0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lm1ub3QubmV0LzwvYT48YnI+DQom
Z3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KJmd0OyBRVUlDIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0i
bWFpbHRvOlFVSUNAaWV0Zi5vcmciPlFVSUNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3F1aWMiIHRhcmdldD0iX2Js
YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3F1aWM8L2E+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_7CF7F94CB496BF4FAB1676F375F9666A2A818487bgb01xud1012_--


From nobody Tue May 24 10:18:52 2016
Return-Path: 
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 50EF712D91A for ; Tue, 24 May 2016 10:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level: 
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 tFCO-LtXKJAV for ; Tue, 24 May 2016 10:18:47 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218FC12D920 for ; Tue, 24 May 2016 10:18:47 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id DA968DCB7E487; Tue, 24 May 2016 17:18:41 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4OHIgxh010812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2016 17:18:42 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4OHIHm1020117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 May 2016 19:18:41 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.44]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 24 May 2016 19:18:26 +0200
From: "Scharf, Michael (Nokia - DE)" 
To: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= , Jana Iyengar , Christian Huitema 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynFCnTysxHU/0GFj3E4WoIavJ/DSSMAgAAj/ACAAcge0IAAJ6KAgAAp5oCAAEbugIAAM9KAgAC6vACAAHOzAIAACk8AgAAAu4CAABQ1AIAANOgAgAAiH0CAAExRAIAAWogw
Date: Tue, 24 May 2016 17:18:25 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48867E45@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>     <655C07320163294895BBADA28372AF5D48866E63@FR712WXCHMBA15.zeu.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: Olivier Bonaventure , Kyle Rose , Ryan Hamilton , Mark Nottingham , Brian Trammell , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 17:18:49 -0000

V2l0aG91dCBrbm93aW5nIHRoZSBwcm90b2NvbCBtZWNoYW5pc20gYW5kIHNwZWNpZmljYWxseSB0
aGUgc2VjdXJpdHkgYW5kIHByaXZhY3kgY29uc2lkZXJhdGlvbnMsIGhvdyBzaG91bGQgSSBiZSBh
YmxlIHRvIGFuc3dlciB0aGlzPw0KDQpZZXQsIGZvciBlbmFibGluZy9kaXNhYmxpbmcgbXVsdGlw
YXRoLCBJIHdvdWxkIHN1Z2dlc3Qgc29tZXRoaW5nIGVxdWl2YWxlbnQgdG8gUkZDIDY4OTcgU2Vj
dGlvbiA0LjUgYW5kIHBvc3NpYmx5IHNvbWV0aGluZyBsaWtlIFJFUTEgaW4gU2VjdGlvbiA1LjIg
aW4gdGhlIHNhbWUgUkZDICh0aGUgbGF0dGVyIGlzIHJlbGF0ZWQgdG8gVEFQUykuDQoNCkkgYW0g
YW4gYXV0aG9yIG9mIFJGQyA2ODk3IGFuZCB0aHVzIG1heWJlIEkgYW0gYmlhc2VkIGhlcmUuIEJ1
dCB0aGVyZSB3YXMgcHJldHR5IHN0cm9uZyBjb25zZW5zdXMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAg
b24gdGhvc2UgdHdvIHNlY3Rpb25zLCBpLmUuLCB0aGF0IHRoZXJlIG11c3QgYmUgYSB3YXkgdG8g
dHVybiBvbiBhbmQgb2ZmIG11bHRpcGF0aC4gRG9lcyB0aGlzIG1ha2Ugc2Vuc2UgdG8geW91Pw0K
DQpNaWNoYWVsDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogR8O2cmFu
IEVyaWtzc29uIEFQIFttYWlsdG86Z29yYW4uYXAuZXJpa3Nzb25AZXJpY3Nzb24uY29tXSANClNl
bnQ6IFR1ZXNkYXksIE1heSAyNCwgMjAxNiAzOjA3IFBNDQpUbzogU2NoYXJmLCBNaWNoYWVsIChO
b2tpYSAtIERFKTsgSmFuYSBJeWVuZ2FyOyBDaHJpc3RpYW4gSHVpdGVtYQ0KQ2M6IE9saXZpZXIg
Qm9uYXZlbnR1cmU7IEt5bGUgUm9zZTsgUnlhbiBIYW1pbHRvbjsgTWFyayBOb3R0aW5naGFtOyBC
cmlhbiBUcmFtbWVsbDsgcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtRVUlDXSBRVUlDIHBy
aXZhY3kgaW1wYWN0DQoNCg0KDQo+U28gdGhlIGJhciBmb3Igc2VjdXJpdHkgYW5kIHByaXZhY3kg
aXMgVENQLCBpbiBteSBwb2ludCBvZiB2aWV3Lg0KPkFjdHVhbGx5LCB0aGVyZSBpcyBubyBuZWVk
IHRvIG1lbnRpb24gTVBUQ1AgYXQgYWxsLiBJZiBsb3dlcmluZyBvZiANCj5zZWN1cml0eSBhbmQg
cHJpdmFjeSBzdGFuZGFyZHMgY29tcGFyZWQgdG8gVENQIGlzIHJlcXVpcmVkLCBhcyANCj5tZW50
aW9uZWQgYmVmb3JlLCB0aGUgY2hhcnRlciBjb3VsZCBtZW50aW9uIHRoYXQgdGhlIHByb3RvY29s
IGRlc2lnbiANCj5jYW4gZm9yZXNlZSBhZGRpdGlvbmFsLCBlbnRpcmVseSBvcHRpb25hbCBhZGRp
dGlvbmFsIHByb3RvY29sIGZlYXR1cmVzLCANCj5vbiBhbiBvcHQtaW4gYmFzaXMuDQoNCkkgYW0g
dHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHNheWluZyBoZXJlOyBhKSBkb2VzIGl0
IG1lYW4gdGhhdCB1c2VyIHNob3VsZCDigJxvcHQtaW7igJ0gdG8gYWRkaXRpb25hbCBmZWF0dXJl
cyBhbmQgYikgaXMgbXVsdGkgcGF0aCBzdWNoIGFuIGFkZGl0aW9uYWwg4oCcZmVhdHVyZeKAnT8N
Cg0KUmVnYXJkcw0KR8O2cmFuDQoNCg==


From nobody Tue May 24 10:37:54 2016
Return-Path: 
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 E4B2612D935 for ; Tue, 24 May 2016 10:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 r6ZPEvLrVyHt for ; Tue, 24 May 2016 10:36:50 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 DAA1C12D91C for ; Tue, 24 May 2016 10:36:49 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id l63so16613405ita.1 for ; Tue, 24 May 2016 10:36:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=qlYShyhxANZtv42J0kuUjmoQs10p2cDOZIPIM2P2SSk=; b=fPXH5PBOAJ0hXx7qXHlc9MRKE4ekOLjM9KOlaMYvy20vAcY+6f1t9YkBr1/FJu+6Tf RlEk8CjKrP++owsGN0njbxG7xUlN4O4Vb80PNrVGEBVgpfCSdVNeIO1RF66gaDaVHhoz 8+5N9oqTOzkYQho4HW6v8SP+jDGGl0hMasZYYdgfaFFLnZVibIuvGQSjLmma8bhdymOS gXwQMf23U0W5eIe5B21egbczYVfL2r2RFzQpXFh4IJnJyk1BtsEBRxeJfHt4JB8iJk5i Ewt/1xGDON9GMVtwz633tbVqSIhYCgcc5uWR+9Y+V8Hd7hK/rKFIHcyhcYC5UkTWtrL0 j38w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=qlYShyhxANZtv42J0kuUjmoQs10p2cDOZIPIM2P2SSk=; b=jjSZ0Lt5+vL2MyENgbdz4X1OKpHRTI0ieB+FctUArlpyWkl0kR5+XZzNtVzqFY2lFZ uTFqoKCqdocPhO/def03oIdkO140lkR0sgg/oybYjBl/IZxAxBTrG9cZwrV+6Im8T5b9 A4Q6UbEYKNQBqaVZ28k4Jxs/6hecbiIl3zaYUbe8GvEmZzQ0GNEu6kL+HCsnT3D9FVuN XjEPVPMyec18ocuCfYX8WY2Ln3o8MTkx6HnHfK3439Q1+0at0cxaoAcLVesXQR6GTMht h4r8xcpon/Sqzc5Pp/Gu40avtQU/tJBsR3Ge5nCIY7JHUQg9sz2AGjOwwSrNP4OrT/h+ Yx0Q==
X-Gm-Message-State: AOPr4FW3zqJG28M9+u6ur8Ijicl1HrDAbLj5An7fEbmmQJGWgSPJ57GjvG/hBejQYF9vTSRZdCALdWOy2iS7dQ==
MIME-Version: 1.0
X-Received: by 10.36.44.200 with SMTP id i191mr17006110iti.99.1464111409128; Tue, 24 May 2016 10:36:49 -0700 (PDT)
Sender: nygren@gmail.com
Received: by 10.107.146.134 with HTTP; Tue, 24 May 2016 10:36:48 -0700 (PDT)
In-Reply-To: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>     
Date: Tue, 24 May 2016 13:36:48 -0400
X-Google-Sender-Auth: gk6YyDlLv6haxj2drs24M69x-g0
Message-ID: 
From: Erik Nygren 
To: Martin Thomson 
Content-Type: multipart/alternative; boundary=001a113f9f6c74101305339a00e2
Archived-At: 
X-Mailman-Approved-At: Tue, 24 May 2016 10:37:52 -0700
Cc: Olivier Bonaventure , Kyle Rose , "Scharf, Michael \(Nokia - DE\)" , Ryan Hamilton , Mark Nottingham , Brian Trammell , Jana Iyengar , "quic@ietf.org" , Christian Huitema 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 17:36:51 -0000

--001a113f9f6c74101305339a00e2
Content-Type: text/plain; charset=UTF-8

On Tue, May 24, 2016 at 12:22 PM, Martin Thomson 
wrote:

>
> I propose: "This work will address security and privacy issues arising
> from the protocol design." and leave it at that.
>

+1

(and we can always reference rfc6973 if we want to, although that may be
implicit)

--001a113f9f6c74101305339a00e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Tue, May 24, 2016 at 12:22 PM, Martin Thomson <=
martin.thomson@gmail.com> wrote:


I propose: "This work will address security and privacy issues arising=


from the protocol design." and leave it at that.
=

+1 =C2=A0 

(and we can always reference rfc6973 if we=
 want to, although that may be implicit) 


--001a113f9f6c74101305339a00e2--


From nobody Tue May 24 11:39:51 2016
Return-Path: 
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 8363E12D973 for ; Tue, 24 May 2016 11:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.027
X-Spam-Level: 
X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 JPpA4tiFSIIG for ; Tue, 24 May 2016 11:27:54 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D9212D0C8 for ; Tue, 24 May 2016 11:27:54 -0700 (PDT)
Received: from [192.168.1.100] (p508F14F6.dip0.t-ipconnect.de [80.143.20.246]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 56DA4721E280C for ; Tue, 24 May 2016 20:27:52 +0200 (CEST)
From: Michael Tuexen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>
Date: Tue, 24 May 2016 20:27:50 +0200
To: quic@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 18:29:11 -0000

Dear all,

in the last years Google has done a wonderful job of experimenting with =
transport
protocol features to improve the overall performance of HTTP-based =
traffic.

In the Bar BOF at the IETF 93 in Prague they presented some of their =
results
showing that several features are necessary to get the performance =
benefits:
* 0 RTT connections setup
* Cross layer optimisations with TLS
* Improved error recovery
* Multiple streams/flows to avoid head of line problems

There are also some requirements for the deployment:
* It MUST be implementable as part of an application and usable by a =
user
  without any specific privileges
* It MUST pass through a large part of middle boxes.

Obviously, these benefits can be realised by using QUIC.

But here is the question:

Are there any plans to analyse the requirements in a protocol =
independent
way and try to figure out if these requirements can also be met by =
evolving
one or more of the existing transport protocols (in combination with the =
appropriate
(D)TLS)? And then making a decision whether it is appropriate to
evolve existing protocols in addition to or instead of developing a new =
one...

Best regards
Michael=


From nobody Tue May 24 11:47:22 2016
Return-Path: 
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 EB2DA12D5C2 for ; Tue, 24 May 2016 11:47:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=netflix.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 I23O_ot3QVmW for ; Tue, 24 May 2016 11:47:20 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 D580B12D099 for ; Tue, 24 May 2016 11:46:32 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id o16so25065216ywd.2 for ; Tue, 24 May 2016 11:46:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=aCqoBrmO+WGqvMXI3bmyZAmOkwM83qzS2CbmqV+ZWEM=; b=Tv8t+ueVMOom/Pe8tTpncttlnmtcRn2h/8uKRP3u8Dsu9h1srHWvm4Rc7WfzlUnMGR fUD0GxXWAsibUdzSSYL6D2Au0TDNWtzX7yLB1Zbbg709FNSqpSlKVSrmmk2+htrbf5Dw G7mjTqM/WEyqYyDMcXUswa4nVc+dot0sSaxTE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=aCqoBrmO+WGqvMXI3bmyZAmOkwM83qzS2CbmqV+ZWEM=; b=Z6TB/N+zo7r6le4ha04FhQ4OZwRota7ivxO34VQsTNOGyvzaNjzrV9eImIYiv7Pqnw E8yIfr6804bjKoyEHL5TiVqheUru6i/JyM/QM7SQRkfki691AqnkBHWyPrpUjuBVRWNu mK+BfaeGt1c6G6h9h3LRUXgSXWZfeF9dXZyoWg3wNta9dHj0KVAFjcllj3pvYGF2EuMw RBVouwuIIo28jVdUp5H1zxd9r6z9PvbN4HLIQdcSW5pxHcSq6+K0dSJuroH7fzECu21L 0GRTLVorK6MfTsOKYdet3C4K8QFOXZ19EAfPUEHqSjlAbSEO3nh86DdyU7x6WMi7ifp6 1DpA==
X-Gm-Message-State: ALyK8tKl8Q8iZ5TNYr5I945cgN9q0/X4s3LKhPHFlVjbRqoMI9Q6WfiAPrnzbHymIVs0iIW1
X-Received: by 10.37.214.139 with SMTP id n133mr3544435ybg.179.1464115591973;  Tue, 24 May 2016 11:46:31 -0700 (PDT)
Received: from [192.168.3.124] (215.64-138-215-net.sccoast.net. [64.138.215.215]) by smtp.gmail.com with ESMTPSA id h68sm22851471ywd.42.2016.05.24.11.46.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 May 2016 11:46:30 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DB970A70-33FB-4331-B453-03F4A6764D6F"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Randall Stewart 
In-Reply-To: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>
Date: Tue, 24 May 2016 14:46:28 -0400
Message-Id: 
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>
To: =?iso-8859-1?Q?Michael_T=FCxen?= 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: quic@ietf.org
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 18:47:22 -0000

--Apple-Mail=_DB970A70-33FB-4331-B453-03F4A6764D6F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Michael:

I could not agree more. If this is going to be a WG to explore new
transport and/or transport features it should go through those steps
to see if an existing transport can=92t be extended or used.

I think even TCP could be extend to cover most of this except maybe FEC =
(that
might be hard). I believe ekr had some proposals for both TCP and SCTP =
for
=93fast start=94 which I believe was 0 RTT connection setup. Past things =
like
Minion have done multi-streaming in TCP.. and I think the list goes on =
:-)

It would be well worth exploring existing transports and their =
=93mold-ability=94 to
do what is required.

Of course if the intent is just to document Google=92s Quic then such =
requirements
workt is not needed and I would suppose neither is a WG..

R

On May 24, 2016, at 2:27 PM, Michael Tuexen =
 wrote:

> Dear all,
>=20
> in the last years Google has done a wonderful job of experimenting =
with transport
> protocol features to improve the overall performance of HTTP-based =
traffic.
>=20
> In the Bar BOF at the IETF 93 in Prague they presented some of their =
results
> showing that several features are necessary to get the performance =
benefits:
> * 0 RTT connections setup
> * Cross layer optimisations with TLS
> * Improved error recovery
> * Multiple streams/flows to avoid head of line problems
>=20
> There are also some requirements for the deployment:
> * It MUST be implementable as part of an application and usable by a =
user
>  without any specific privileges
> * It MUST pass through a large part of middle boxes.
>=20
> Obviously, these benefits can be realised by using QUIC.
>=20
> But here is the question:
>=20
> Are there any plans to analyse the requirements in a protocol =
independent
> way and try to figure out if these requirements can also be met by =
evolving
> one or more of the existing transport protocols (in combination with =
the appropriate
> (D)TLS)? And then making a decision whether it is appropriate to
> evolve existing protocols in addition to or instead of developing a =
new one...
>=20
> Best regards
> Michael
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic

--------
Randall Stewart
rrs@netflix.com
803-317-4952






--Apple-Mail=_DB970A70-33FB-4331-B453-03F4A6764D6F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Michael:

I could not agree more. =
If this is going to be a WG to explore new
transport and/or =
transport features it should go through those steps
to see if =
an existing transport can=92t be extended or =
used.

I think even TCP could be extend to cover =
most of this except maybe FEC (that
might be hard). I believe =
ekr had some proposals for both TCP and SCTP for
=93fast =
start=94 which I believe was 0 RTT connection setup. Past things =
like
Minion have done multi-streaming in TCP.. and I think the =
list goes on :-)

It would be well worth =
exploring existing transports and their =93mold-ability=94 =
to
do what is required.

Of course if =
the intent is just to document Google=92s Quic then such =
requirements
workt is not needed and I would suppose neither =
is a WG..

R

On May 24, =
2016, at 2:27 PM, Michael Tuexen <Michael.Tuexen@lurchi.fra=
nken.de> wrote:

Dear =
all,

in the last years Google has done a wonderful job of =
experimenting with transport
protocol features to improve the overall =
performance of HTTP-based traffic.

In the Bar BOF at the IETF 93 =
in Prague they presented some of their results
showing that several =
features are necessary to get the performance benefits:
* 0 RTT =
connections setup
* Cross layer optimisations with TLS
* Improved =
error recovery
* Multiple streams/flows to avoid head of line =
problems

There are also some requirements for the =
deployment:
* It MUST be implementable as part of an application and =
usable by a user
  without any specific privileges
* It MUST =
pass through a large part of middle boxes.

Obviously, these =
benefits can be realised by using QUIC.

But here is the =
question:

Are there any plans to analyse the requirements in a =
protocol independent
way and try to figure out if these requirements =
can also be met by evolving
one or more of the existing transport =
protocols (in combination with the appropriate
(D)TLS)? And then =
making a decision whether it is appropriate to
evolve existing =
protocols in addition to or instead of developing a new =
one...

Best =
regards
Michael
_______________________________________________
Q=
UIC mailing list
QUIC@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/quic



--------
Randall Stewart
803-317-4952=









=

--Apple-Mail=_DB970A70-33FB-4331-B453-03F4A6764D6F--


From nobody Tue May 24 12:09:43 2016
Return-Path: 
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 9F1F812D9DC for ; Tue, 24 May 2016 12:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 IYR90DmwPE77 for ; Tue, 24 May 2016 12:07:32 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2CB12D9D1 for ; Tue, 24 May 2016 12:07:30 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-4c-5744a670fb1f
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A7.49.12516.076A4475; Tue, 24 May 2016 21:07:28 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0294.000; Tue, 24 May 2016 21:07:27 +0200
From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= 
To: Erik Nygren , Martin Thomson 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynLzG7Kc0WafEWNs7kTj2FsFJ/DSSMAgAAj/ACAAasqAIAARJaAgAAp5oCAAEbugIAAM9KAgAC6vACAAHOzAIAACk8AgAAAu4CAABQ1AIAANOgAgAClAICAABS8AIAAOtoA
Date: Tue, 24 May 2016 19:07:27 +0000
Message-ID: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>      
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.4.160422
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="utf-8"
Content-ID: <47B59EF0304B0E4B874EB8CA7BB46C26@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUyM2J7lG7BMpdwgyt7RS3mv1vNZNH0uY/R YmPLOzaLSUcXslisfzGJzeLamX+MFj8valms//SY0WJ243EWi54F3BbzP/ayOHB77Jx1l91j waZSjyVLfjJ5dF38zuTRuuMvu8fGxd9ZPe7eusTkserxRXaPO03TmT2e7J/JEsAVxWWTkpqT WZZapG+XwJUx8fMV1oIu7ord/xcxNjA+4epi5OSQEDCRuPBlCxOELSZx4d56ti5GLg4hgSOM Esf+z4NyljBKrJj+kRWkik3AW6Kt5TBLFyMHh4hAsMSC+aYgNcwCr5kkpi4+zwxSIyygLtG8 ZjaYLSKgIbFq7ykmkCIRgWmMEk937WcDaWYRUJV4dF8AxOQVsJY4viYUpFxIYDanxM2OBBCb UyBQ4taSVjYQm1FAVuL+93ssIDazgLjErSfzoY4WkFiyB2KthICoxMvH/8DOFBXQk/hybx4j RFxJYu3h7WAnMwtoSqzfpQ8xxlri1NkJjBC2osSU7ofsIDavgKDEyZlPWCYwSsxCsm0WQvcs JN2zkHTPQtK9gJF1FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgmji45bfuDsbVrx0PMQpw MCrx8CbUOocLsSaWFVfmHmKU4GBWEuHdsNglXIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vF cCGB9MSS1OzU1ILUIpgsEwenVAOjRlqr9KVw0+/yMZNkLF8+W1cvwpht0rX/qsPe1w275ui6 vpF7/Dx//Uud71IsdlEZX42E3Vx+TN+2RO1ygzWj5fdJnzmub73RHqF7sLDjy9b9zOLGMye/ TE1fsKFhUnmOyLurN/+9FvaUFGjnm6d29e/Zq2YrRUwU3kw8xnHfwOJQ10PpJwc2K7EUZyQa ajEXFScCALzIEksPAwAA
Archived-At: 
X-Mailman-Approved-At: Tue, 24 May 2016 12:09:42 -0700
Cc: Olivier Bonaventure , "Scharf, Michael \(Nokia - DE\)" , Kyle Rose , Ryan Hamilton , Mark Nottingham , Jana Iyengar , Brian Trammell , "quic@ietf.org" , Christian Huitema 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 19:07:33 -0000

DQoNCj5PbiBUdWUsIE1heSAyNCwgMjAxNiBhdCAxMjoyMiBQTSwgTWFydGluIFRob21zb24NCj48
bWFydGluLnRob21zb25AZ21haWwuY29tPiB3cm90ZToNCj4NCj4NCj5JIHByb3Bvc2U6ICJUaGlz
IHdvcmsgd2lsbCBhZGRyZXNzIHNlY3VyaXR5IGFuZCBwcml2YWN5IGlzc3VlcyBhcmlzaW5nDQo+
ZnJvbSB0aGUgcHJvdG9jb2wgZGVzaWduLiIgYW5kIGxlYXZlIGl0IGF0IHRoYXQuDQo+DQo+DQo+
DQo+KzEgICANCj4NCj4NCj4oYW5kIHdlIGNhbiBhbHdheXMgcmVmZXJlbmNlIHJmYzY5NzMgaWYg
d2Ugd2FudCB0bywgYWx0aG91Z2ggdGhhdCBtYXkgYmUNCj5pbXBsaWNpdCkNCg0KKzEuIEtpbmQg
b2YgbGlrZSByZWZlcnJpbmcgdG8gc29tZXRoaW5nIGxpa2UgcmZjNjk3MyBzaWduYWxsaW5nIHRo
ZSBpbnRlbnQNCnRvIGdvIHRoYXQgZXh0cmEgbWlsZS4NCg0KSWYgSFRUUC8yIG1hcHBpbmcgb24g
UVVJQyBpcyBpbmNsdWRlZCBpbiB0aGUgV0csIEkgcHJvcG9zZSBjb25zaWRlcmluZyBhDQptaW5v
ciBhZGRpdGlvbiB0byBjbGFyaWZ5IHNlY3VyaXR5IGFuZCBwcml2YWN5IGlzc3VlcyBjb25jZXJu
cyB1c2luZyBRVUlDDQphcyBhIHN0YW5kYWxvbmUgcHJvdG9jb2wgYXMgd2VsbCBhcyBIVFRQLzIg
aW4gY29tYmluYXRpb24gd2l0aCBRVUlDLiBXb3VsZA0KZm9yIHNvbWUgcmVhc29uIGFsc28gUVVJ
QyBmb3IgV2ViUlRDIGJlIGluY2x1ZGVkIChsYXRlciksIHRoZW4gb2J2aW91c2x5DQp0aGUgV0cg
d291bGQgbmVlZCB0byBsb29rIGF0IHRoYXQgbWFwcGluZyBhcyBhIHNlcGFyYXRlIHRvcGljOg0K
DQoiVGhpcyB3b3JrIHdpbGwgYWRkcmVzcyBzZWN1cml0eSBhbmQgcHJpdmFjeSBpc3N1ZXMgYXJp
c2luZyBmcm9tIHRoZQ0KW05FV110cmFuc3BvcnRbL05FV10gcHJvdG9jb2wgZGVzaWduIFtORVdd
YXMgd2VsbCBhcyB0aGUgbWFwcGluZyBvZiB0aGUNCkhUVFAvMiBhcHBsaWNhdGlvbiBwcm90b2Nv
bCBhbmQgZXh0ZW5zaW9ucyBvbiB0aGUgdHJhbnNwb3J0DQpwcm90b2NvbFsvTkVXXeKAnS4NCg0K
DQo+IA0KDQo=


From nobody Tue May 24 12:17:59 2016
Return-Path: 
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 A9AB612D612 for ; Tue, 24 May 2016 12:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 yh1T6SpSij2c for ; Tue, 24 May 2016 12:17:57 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22AA12D9B9 for ; Tue, 24 May 2016 12:17:42 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-29-5744a8d4f904
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C9.4F.12926.4D8A4475; Tue, 24 May 2016 21:17:40 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0294.000; Tue, 24 May 2016 21:17:40 +0200
From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= 
To: "Scharf, Michael (Nokia - DE)" , Jana Iyengar , Christian Huitema 
Thread-Topic: [QUIC] Multipath configuration WAS: QUIC privacy impact
Thread-Index: AQHRtfDwf4BKJcddyE6RaJ9t46Oxgg==
Date: Tue, 24 May 2016 19:17:40 +0000
Message-ID: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.4.160422
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-ID: <997657E799B8704692BB46C99C14813D@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUyM2K7pe6VFS7hBi9faVo0fe5jtNjY8o7N YtLRhSwW619MYrP4eVHLYv2nx4wWsxuPs1j0LOC2mP+xl8WB02PBplKPJUt+Mnl0XfzO5NG6 4y+7x8bF31k97t66xORxp2k6s8eT/TNZAjiiuGxSUnMyy1KL9O0SuDLu7D/OWvBDsGLtom2s DYx7BLsYOTkkBEwkVl/tY4KwxSQu3FvP1sXIxSEkcIRRYvfjs+wQzhJGiXn77jGDVLEJeEu0 tRxmAUmICHQySlxZuQeshVngEaPEy5anjCBVwgIuEt1bzoLNFRFwldh1ezEbhK0ncXpiP9gk FgFViWm9x1hAbF4Ba4lbe8+A9TIKyErc/34PLM4sIC5x68l8qPsEJJbsOc8MYYtKvHz8jxXE FgWa+eXePEaIuJLEotufgeo5gHo1Jdbv0ocYYy3R1vaKCcJWlJjS/ZAdYq2gxMmZT1gmMIrN QrJtFkL3LCTds5B0z0LSvYCRdRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYFQf3PJbdQfj 5TeOhxgFOBiVeHgTap3DhVgTy4orcw8xSnAwK4nw/lrmEi7Em5JYWZValB9fVJqTWnyIUZqD RUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qBUdE9JG41Y0LOL5YX3YqFspYe3xf9Y9gcG5Yg W5X04+Kqqh0H1gm8TFLbMM18s+khKctvFzTqfTfv9qw1fjjdbrt8vcjhzR+L1p57Y1FX55co zb6pvuvFcf3l2Sy/KyRrDl/abPJ68e5TK0TrszaaynY8kjznzOilL1/EzdguHzX13bz9f/hS lFiKMxINtZiLihMBxsqsueYCAAA=
Archived-At: 
Cc: Olivier Bonaventure , Kyle Rose , Ryan Hamilton , Mark Nottingham , Brian Trammell , "quic@ietf.org" 
Subject: Re: [QUIC] Multipath configuration WAS: QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 19:17:59 -0000

DQoNCj5XaXRob3V0IGtub3dpbmcgdGhlIHByb3RvY29sIG1lY2hhbmlzbSBhbmQgc3BlY2lmaWNh
bGx5IHRoZSBzZWN1cml0eSBhbmQNCj5wcml2YWN5IGNvbnNpZGVyYXRpb25zLCBob3cgc2hvdWxk
IEkgYmUgYWJsZSB0byBhbnN3ZXIgdGhpcz8NCg0KRmFpciBwb2ludC4gSnVzdCB3YW50ZWQgdG8g
ZW5zdXJlIEkgdW5kZXJzdG9vZCB5b3UgY29ycmVjdGx5Lg0KDQo+DQo+WWV0LCBmb3IgZW5hYmxp
bmcvZGlzYWJsaW5nIG11bHRpcGF0aCwgSSB3b3VsZCBzdWdnZXN0IHNvbWV0aGluZw0KPmVxdWl2
YWxlbnQgdG8gUkZDIDY4OTcgU2VjdGlvbiA0LjUgYW5kIHBvc3NpYmx5IHNvbWV0aGluZyBsaWtl
IFJFUTEgaW4NCj5TZWN0aW9uIDUuMiBpbiB0aGUgc2FtZSBSRkMgKHRoZSBsYXR0ZXIgaXMgcmVs
YXRlZCB0byBUQVBTKS4NCj4NCj5JIGFtIGFuIGF1dGhvciBvZiBSRkMgNjg5NyBhbmQgdGh1cyBt
YXliZSBJIGFtIGJpYXNlZCBoZXJlLiBCdXQgdGhlcmUgd2FzDQo+cHJldHR5IHN0cm9uZyBjb25z
ZW5zdXMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgb24gdGhvc2UgdHdvIHNlY3Rpb25zLCBpLmUuLA0K
PnRoYXQgdGhlcmUgbXVzdCBiZSBhIHdheSB0byB0dXJuIG9uIGFuZCBvZmYgbXVsdGlwYXRoLiBE
b2VzIHRoaXMgbWFrZQ0KPnNlbnNlIHRvIHlvdT8NCg0KR290IHlvdS4gSXQgZG9lcy4gDQoNClRu
eA0KDQpSZWdhcmRzDQpHw7ZyYW4NCg0KDQoNCj4NCj5NaWNoYWVsDQo+DQo+DQo+DQo+LS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBHw7ZyYW4gRXJpa3Nzb24gQVAgW21haWx0bzpn
b3Jhbi5hcC5lcmlrc3NvbkBlcmljc3Nvbi5jb21dDQo+U2VudDogVHVlc2RheSwgTWF5IDI0LCAy
MDE2IDM6MDcgUE0NCj5UbzogU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKTsgSmFuYSBJeWVu
Z2FyOyBDaHJpc3RpYW4gSHVpdGVtYQ0KPkNjOiBPbGl2aWVyIEJvbmF2ZW50dXJlOyBLeWxlIFJv
c2U7IFJ5YW4gSGFtaWx0b247IE1hcmsgTm90dGluZ2hhbTsgQnJpYW4NCj5UcmFtbWVsbDsgcXVp
Y0BpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbUVVJQ10gUVVJQyBwcml2YWN5IGltcGFjdA0KPg0K
Pg0KPg0KPj5TbyB0aGUgYmFyIGZvciBzZWN1cml0eSBhbmQgcHJpdmFjeSBpcyBUQ1AsIGluIG15
IHBvaW50IG9mIHZpZXcuDQo+PkFjdHVhbGx5LCB0aGVyZSBpcyBubyBuZWVkIHRvIG1lbnRpb24g
TVBUQ1AgYXQgYWxsLiBJZiBsb3dlcmluZyBvZg0KPj5zZWN1cml0eSBhbmQgcHJpdmFjeSBzdGFu
ZGFyZHMgY29tcGFyZWQgdG8gVENQIGlzIHJlcXVpcmVkLCBhcw0KPj5tZW50aW9uZWQgYmVmb3Jl
LCB0aGUgY2hhcnRlciBjb3VsZCBtZW50aW9uIHRoYXQgdGhlIHByb3RvY29sIGRlc2lnbg0KPj5j
YW4gZm9yZXNlZSBhZGRpdGlvbmFsLCBlbnRpcmVseSBvcHRpb25hbCBhZGRpdGlvbmFsIHByb3Rv
Y29sIGZlYXR1cmVzLA0KPj5vbiBhbiBvcHQtaW4gYmFzaXMuDQo+DQo+SSBhbSB0cnlpbmcgdG8g
dW5kZXJzdGFuZCB3aGF0IHlvdSBhcmUgc2F5aW5nIGhlcmU7IGEpIGRvZXMgaXQgbWVhbiB0aGF0
DQo+dXNlciBzaG91bGQg4oCcb3B0LWlu4oCdIHRvIGFkZGl0aW9uYWwgZmVhdHVyZXMgYW5kIGIp
IGlzIG11bHRpIHBhdGggc3VjaCBhbg0KPmFkZGl0aW9uYWwg4oCcZmVhdHVyZeKAnT8NCj4NCj5S
ZWdhcmRzDQo+R8O2cmFuDQo+DQoNCg==


From nobody Tue May 24 13:40:04 2016
Return-Path: 
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 EE10D12D1BE for ; Tue, 24 May 2016 13:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 oyGpeW1d1vJG for ; Tue, 24 May 2016 13:40:03 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8BC12D1B1 for ; Tue, 24 May 2016 13:40:01 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-ae-5744bc1fe7ab
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.12.12516.F1CB4475; Tue, 24 May 2016 22:40:00 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0294.000; Tue, 24 May 2016 22:39:59 +0200
From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= 
To: Martin Thomson 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynLzG7Kc0WafEWNs7kTj2FsFJ/DSSMAgAAj/ACAAasqAIAARJaAgAAp5oCAAEbugIAAM9KAgAC6vACAAHOzAIAACk8AgAAAu4CAABQ1AIAANOgAgAClAICAABS8AIAAOtoA///sZoCAAC10AA==
Date: Tue, 24 May 2016 20:39:59 +0000
Message-ID: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>        
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.4.160422
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7q67CHpdwg2tz2C2unfnHaNGzgNuB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgypj1X6rgHlPF8qW6DYxXmLoYOTkkBEwk1ux4 yghhi0lcuLeeDcQWEjjCKLHoVWwXIxeQvYRRYtqkUywgCTYBb4m2lsNgtoiArsSisw/YQWxm AWWJKacbWEFsYQF1ieY1s5khajQkVu09xQQySERgGaPEyv/XwTawCKhKXH3YA9bMK2At8fD5 TkaIbVO4JGa8mALkcHBwCgRKdM33BalhFJCVuP/9HgvEMnGJW0/mQ30gILFkz3lmCFtU4uXj f2BHiAroSXy5Nw/qMyWJtYe3s4CMZBbQlFi/Sx9ijLXEzV3roO5XlJjS/RDqHEGJkzOfsExg lJiFZNsshO5ZSLpnIemehaR7ASPrKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzA+Du45bfu DsbVrx0PMQpwMCrx8CbUOocLsSaWFVfmHmKU4GBWEuGt3OUSLsSbklhZlVqUH19UmpNafIhR moNFSZzX/6ViuJBAemJJanZqakFqEUyWiYNTqoHRS+yJWH9nkdbDOTu21rNta3D9n7DE8fEG uY79Wq9ffVosuK6xeKXd7GXNb75uOstkrCVVVpKyno3v3p7swPijzPPyS0LcV2wo6lj1dyVP 8uvv+5zvHIpxkpmg/X9vyoMV77Z192ZqSXk3cTeXhIc6aM266LjuS/Heitwja/MjxfK3HJ1q doFBiaU4I9FQi7moOBEACJjgK7sCAAA=
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 20:40:04 -0000

DQo+DQo+RG9uJ3QgYmUgdG9vIHNwZWNpZmljLiAgSXQgY3JlYXRlcyB0aGUgc2Vuc2UgdGhhdCB0
aGVyZSBhcmUgZXhjZXB0aW9ucy4NCj4NCj5SRkMgNjk3MyBpcyBncmVhdCwgYnV0IHdlIGRvbid0
IG5lZWQgY2l0YXRpb25zIGZvciBpdCBvciB3ZSB3aWxsIGhhdmUNCj50byBhZGQgMzU1MiBhcyB3
ZWxsLg0KDQpBZHZpY2UgZnJvbSBhIHdpc2VyIG9uZSwgOi0pLiBTZWUgdGhlIHByb2JsZW0gd2l0
aCB0aGUgcHJvcG9zYWxzLiBUbnguDQoNCg==


From nobody Tue May 24 13:42:22 2016
Return-Path: 
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 F419E12D504 for ; Tue, 24 May 2016 12:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 8N8VozBsu4YW for ; Tue, 24 May 2016 12:57:18 -0700 (PDT)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (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 5A92A12D15D for ; Tue, 24 May 2016 12:57:18 -0700 (PDT)
Received: by mail-qg0-x229.google.com with SMTP id 90so12564565qgz.1 for ; Tue, 24 May 2016 12:57:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=mExIQXCaZp8nR/q34tDHqX7gzVq3ArCWkIgp0EtoemA=; b=K2zWEcMGJIL7UFLOQwoYX/VQw895EcQVJK1SnpHgh6x02tl/2giHvegzj2BbEC0mFQ Ljjl+qFhCIIzQR/S+z9VrwoV0XGOaTK6f7aF43r8/u/pogeC0/nY5y4Ub79TvUZGyBRh QfZudL477PUsDbFEWXOtgZ9/S6YkVphUM2ERn7XL698bKNinqjdI+JnXN3UGWSBiGfpY wQb7liyff/TKf9HVeo3fFh2oi5K2PUMuYcDKp02tI4k7mIPlhtCt9ScTK2qYiluVwjSB OwPDNKwfxCCo5O1iUGxSlaj9YcXQdme2oRLy6AkQVyQNUexeeKnNfmvY/+m/hukbPiyS ANaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=mExIQXCaZp8nR/q34tDHqX7gzVq3ArCWkIgp0EtoemA=; b=jxLJdmp0wYwWeMWWbZjDCZqh0EBZ72hJbGtrI+43pJyuOGC+SozF90XjQ6nokZYC7Y KACBzVITyxWmlSRzylyl5yn65W42ycl/VzmlhwHK8Br38bJhT7Wdt4Ks3oNOOAEM+a/r a8z+4qEm+9I+CjWqL8LvfcbdocyvZ2wX3QUVuduCaN0YPSMNbLFfOLR9M9yBlsP3JEGT m2aQCPoxpalrWQADCN9O/B1H45MPzfDdB7d1a+NqiAygEvzn+NEGohQsRsNmgTxjaONB GnfzJqnTZS9wZRvmPHm/o/8hD2YIjwHmMOiOxBVOmleBXOUh/mT2kp36kSeC4+EoLhOV eGUA==
X-Gm-Message-State: ALyK8tIlSeYPANKS+YfGoY2gGjw9KttJXdAThWNdrPLX+/kJiIjblsBMEEtwj0D0CIeF6ivHGuwRLYghaGmmcQ==
MIME-Version: 1.0
X-Received: by 10.140.248.84 with SMTP id t81mr5333759qhc.94.1464119837289; Tue, 24 May 2016 12:57:17 -0700 (PDT)
Received: by 10.140.104.70 with HTTP; Tue, 24 May 2016 12:57:17 -0700 (PDT)
In-Reply-To: 
References:  <655C07320163294895BBADA28372AF5D488612F2@FR712WXCHMBA15.zeu.alcatel-lucent.com>   <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>       
Date: Tue, 24 May 2016 12:57:17 -0700
Message-ID: 
From: Martin Thomson 
To: =?UTF-8?Q?G=C3=B6ran_Eriksson_AP?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-Mailman-Approved-At: Tue, 24 May 2016 13:42:18 -0700
Cc: Olivier Bonaventure , "Scharf, Michael \(Nokia - DE\)" , Kyle Rose , Ryan Hamilton , Erik Nygren , Mark Nottingham , Jana Iyengar , Brian Trammell , "quic@ietf.org" , Christian Huitema 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 19:57:20 -0000

On 24 May 2016 at 12:07, G=C3=B6ran Eriksson AP
 wrote:
> "This work will address security and privacy issues arising from the
> [NEW]transport[/NEW] protocol design [NEW]as well as the mapping of the
> HTTP/2 application protocol and extensions on the transport
> protocol[/NEW]=E2=80=9D.

Don't be too specific.  It creates the sense that there are exceptions.

RFC 6973 is great, but we don't need citations for it or we will have
to add 3552 as well.


From nobody Tue May 24 13:53:31 2016
Return-Path: 
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 E66FC12D52C for ; Tue, 24 May 2016 13:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 GgsF8OWmZMJK for ; Tue, 24 May 2016 13:53:28 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 1E74612D54F for ; Tue, 24 May 2016 13:53:28 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id n129so150043140wmn.1 for ; Tue, 24 May 2016 13:53:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=4BOhGjnSvZ/V5NFNyKxiI0aUaZJpbTqdbh4iqujkSQI=; b=EjbqMfmBENIYtCihfSCl0Y6gCYgy3dcixqISE9JJBlulVPidR4HRSBimoCti6MQCBu gKHsGxe/yPMEVN1hJG2731vJtmWPZMjN/ld/N/RiQvdPzCtnCXZbdmrDPMSnSxWOpBPT FAQhqEGltiZvM7eeKeHTkWM300+j09tVXU3qPm3lzxbAC9hCb6UQVMi+kI9Egi6Vt7xt LJp270yJhK6B3HIyB+zVOCnwsqVakjvXOYvyRfwCTEd2DckvG7NhIwL3CEUsYJ6oy8Ce Ed2zIBc3lneCa67y2dSvgfnI4t3OVhBSR+/Ire4yVHP/NDBYWDI0R0W2GHqP2UEY6dpM 9u9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=4BOhGjnSvZ/V5NFNyKxiI0aUaZJpbTqdbh4iqujkSQI=; b=GcqyLQma+NYHull+by2K35xvCiv+bua7TQppZgXu5fxbgyaoM16qY2icBz9BiBS8FN XB8p+M3tc07TV9ASXQzFvf8tlhbw5Vj8SjAWkOQricSQaPvBYeDPSve0NplnOETLN6b0 RvgxbZm5l8FnWZ5JrnN9FoseNaueOBA0oHkYPA+bYd9saNmxyG2Pjb3FL8dYlPyfHFeD ltb04GeOXmkMKd/jE/HHu78TdTNthKGKw1FhaIf/cwVzsEZ+uk5Gocz3y78D+PTevhN2 +DhqK40zA1uRfbJ23k5fx0BU+reGrBSgpxDwEq8L3yvo3LBBoAVI8f84B0Xc+F2EIcvI lrhQ==
X-Gm-Message-State: ALyK8tLR3gnsd2RheALf72OLGas35z+OlBz9IOCOZ3UvpXFmCU3tMoihMw/tiZL3pWXBQ0AbwW2EXZ3nb85U0NLW+P7xarturLn1oP5kIHZfQuH+TBCpqgJF
X-Received: by 10.194.89.168 with SMTP id bp8mr152303wjb.57.1464123206612; Tue, 24 May 2016 13:53:26 -0700 (PDT)
Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be. [78.129.6.94]) by smtp.gmail.com with ESMTPSA id g8sm5574192wme.23.2016.05.24.13.53.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 13:53:25 -0700 (PDT)
To: Martin Thomson , Jana Iyengar 
References:    <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>     
From: Olivier Bonaventure 
Message-ID: 
Date: Tue, 24 May 2016 22:53:24 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Archived-At: 
Cc: Kyle Rose , "Scharf, Michael \(Nokia - DE\)" , Ryan Hamilton , Mark Nottingham , Christian Huitema , Brian Trammell , "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 20:53:30 -0000

On 24/05/16 18:22, Martin Thomson wrote:
> On 23 May 2016 at 23:32, Jana Iyengar  wrote:
>> I could go with what Mark and Michael suggested; something like: "This work
>> will ensure that QUIC using TLS1.3 has security and privacy properties that
>> are at least as good as a stack composed of TLS1.3 using TCP (or MPTCP when
>> using multipath.)"
>
> I disagree with the implication that MPTCP or even TCP is good enough.
> It's been a little while, we've learned a few things about the world
> and how to design protocols that retain important things like privacy
> and security without sacrificing other goals, like performance.
>
> This text sets a pretty low bar.  Too low perhaps.  But I don't know
> for sure right now because I don't have the entire design space mapped
> out.  And a charter discussion isn't the place for that (thanks
> Rich!).  How about we not try to decide the outcome of the discussion
> and simply say that we will design for the optimum tradeoff between
> functionality, performance, security and privacy.  In other words, we
> will do our jobs.
>
> I propose: "This work will address security and privacy issues arising
> from the protocol design." and leave it at that.

I think that it is useful to specify a reasonable expectation that is 
not unrealistic. Otherwise, we might end up in never ending discussions 
within the working group.

Olivier



-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.


From nobody Tue May 24 14:06:23 2016
Return-Path: 
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 C368B12D13D for ; Tue, 24 May 2016 14:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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=microsoft.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 V2K2niliJL8p for ; Tue, 24 May 2016 14:06:20 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0145.outbound.protection.outlook.com [65.55.169.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848AB12B051 for ; Tue, 24 May 2016 14:06:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WXESiFEuWCvjRjFjxnyBFp1FjioqUYRuY0/wiMUCYTo=; b=d3c0WMyNDmDX6FNdGckHNrzpcoLBCUwP3y2zfTt/gcLCxWpVhMDWWuE1CJeU6qDUiPnZ8Jhntb8QPQQs5e6Xx2227FnDgK/beHvcSecf4I7fJjTtKzI+U4br3bla+KZMKdVcDOkduwMgRZmR0rOhYq70GllwWu0AoqzWcuM3mHM=
Received: from CY1PR0301MB0649.namprd03.prod.outlook.com (10.160.158.143) by CY1PR0301MB0649.namprd03.prod.outlook.com (10.160.158.143) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 24 May 2016 21:06:18 +0000
Received: from CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) by CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) with mapi id 15.01.0497.019; Tue, 24 May 2016 21:06:16 +0000
From: Christian Huitema 
To: Olivier Bonaventure 
Thread-Topic: [QUIC] QUIC privacy impact
Thread-Index: AQHRsynMN6GVCYzd10uovw2jcGWCDZ/DaqoAgAAj/QCAAaspAIAARJaAgAAp5oCAAEbugIAAM9KAgAC6vACAAHOzAIAACk8AgAAAu4CAABHU4IAAN0kAgAClAICAAEuqAIAAAhCg
Date: Tue, 24 May 2016 21:06:15 +0000
Message-ID: 
References:    <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: tessares.net; dkim=none (message not signed) header.d=none; tessares.net; dmarc=none action=none header.from=microsoft.com; 
x-originating-ip: [2001:4898:80e8:9::10d]
x-ms-office365-filtering-correlation-id: b1e77099-d80a-46ad-6d26-08d384173ecd
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0649; 5:yAUIv0k8aYQb9MwrTDpGQkNGpM4FOFA2S4f51xqCbWfgRfYmN7222mk6jagyLw8t1olD0ZdZ43lZuIwzpByswg0FJvK2xG3khWfZaHqNRU7+Lsn8RnsPimbFcFn6MVwVOyNuQwdc/XaSkVtEx6QEPA==; 24:hTqByz6obl1xnU6s6BwcXntzFFoQHkH2OZ3fENIi8ejAxtR/N1mhevOk1vLt5bX85DoIFy0RyfsrSwCTHByXWJtZETOAuBJ6WsqHG5ZlNfY=; 7:WBz01QmGc2sDnZL/MLYuiy7JRkgkpCknBfGHV2MQDUvgReaUp23RhHsC3SevrvXiC5Ne6aNrWDvmehhEVyyO+J2qdABREJ+hkAoV9B4esB0emi/5UHyaWWr+hKC8BAmZ4JJTQd8UUztgZRjf3NRRO+KV0FY8YrwPOfhnIlpWA9xaVks0VP1Prdrw1THXmIARP9+/vhPEyy2h33rjVhNc/g==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0649;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0649; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0649; 
x-forefront-prvs: 09525C61DB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(24454002)(377454003)(106116001)(33656002)(5002640100001)(4326007)(19580405001)(10090500001)(8936002)(10290500002)(5008740100001)(122556002)(5003600100002)(86362001)(10400500002)(86612001)(5005710100001)(87936001)(2906002)(92566002)(99286002)(19580395003)(81166006)(586003)(54356999)(76176999)(74316001)(9686002)(3280700002)(3660700001)(1220700001)(50986999)(8676002)(110136002)(189998001)(76576001)(2950100001)(102836003)(2900100001)(6116002)(77096005)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0649; H:CY1PR0301MB0649.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 21:06:15.9323 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0649
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 21:06:22 -0000

On Tuesday, May 24, 2016 1:53 PM, Olivier Bonaventure wrote:
> =20
> On 24/05/16 18:22, Martin Thomson wrote:
> > On 23 May 2016 at 23:32, Jana Iyengar  wrote:
> >> I could go with what Mark and Michael suggested; something like:
> >> "This work will ensure that QUIC using TLS1.3 has security and
> >> privacy properties that are at least as good as a stack composed of
> >> TLS1.3 using TCP (or MPTCP when using multipath.)"
...
> > I propose: "This work will address security and privacy issues arising
> > from the protocol design." and leave it at that.
>=20
> I think that it is useful to specify a reasonable expectation that is not
> unrealistic. Otherwise, we might end up in never ending discussions withi=
n the
> working group.

Au contraire. Any discussion in the WG will require that proponent of a "mo=
re private" option propose a design. There may be good reasons to reject a =
proposed design, if it is for example way too complicated, or too unreliabl=
e. But such designs should not be pre-emptively ruled out by some provision=
 of the charter.  I think Martin has the right formulation.

-- Christian Huitema



From nobody Tue May 24 14:20:03 2016
Return-Path: 
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 52BD012D16B for ; Tue, 24 May 2016 14:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 NfjFZMrAsMRR for ; Tue, 24 May 2016 14:20:00 -0700 (PDT)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (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 E696612D119 for ; Tue, 24 May 2016 14:19:59 -0700 (PDT)
Received: by mail-qg0-x22d.google.com with SMTP id q32so13653388qgq.3 for ; Tue, 24 May 2016 14:19:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=qQ0+mZG5uJ7MoyliM7Wk8sqzCbEGypRQp+tqHubrgsU=; b=H1jDjajue1bhYj06KyPT9UzrSxCuStBHF0nIpQMncsJQRMQuaIOIIhPt/4WQFvE0ZZ dT9Ef8QzVOM884vHxfIppKOpcKjKl/ty26q99sjbN/Czvv7RApOlBeTtZq+I9b9t8fmQ lC4B9Nk149Hs/M+KcucwsCSYsg0b0WdAnJKA4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=qQ0+mZG5uJ7MoyliM7Wk8sqzCbEGypRQp+tqHubrgsU=; b=lyiK35mbGUOB5vO42cR8ZKKvnw5i/MxbwHluWlzACWqh0CVr4rBCwnIL4ltqdZNeQu /09fadzaaETSgVMY7sweXTw0x47jbPZ1iGLd9OmfGbWVOh/OF04Crz6vSkArB3sVUEMo mV8bqbTdxPCOwrvlZirMumCZC/rjrH7QCNZpue4/bcU1SIvdQgU2sHIuDVpy9lPez51u GTPqqiTv/rNl02WQ7ARDLb+HDOpLZvPxER4GeMdRets/S0c714IHPZ4J8Xr7R0ngu+ss yPSl1LnjvSwqlb0gCxQYCkXy3IQ8ZWX6VF38pSsjha3iuhnmplPIeq7bWmIB/rfP2Fxn 6ofA==
X-Gm-Message-State: ALyK8tKHSRw5GCyGtyLptQpgejNLqma54bpH4vRkCj/bF1KryVoaCP2ZpSr9JASJvd2X9a//fICi/Udn/D5HUg==
MIME-Version: 1.0
X-Received: by 10.140.42.78 with SMTP id b72mr314246qga.48.1464124799009; Tue, 24 May 2016 14:19:59 -0700 (PDT)
Received: by 10.55.96.130 with HTTP; Tue, 24 May 2016 14:19:58 -0700 (PDT)
X-Originating-IP: [72.246.0.14]
In-Reply-To: 
References:    <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>      
Date: Tue, 24 May 2016 17:19:58 -0400
Message-ID: 
From: Kyle Rose 
To: Olivier Bonaventure 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Christian Huitema , "Scharf, Michael \(Nokia - DE\)" , Ryan Hamilton , Mark Nottingham , Jana Iyengar , Brian Trammell , "quic@ietf.org" , Martin Thomson 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 21:20:01 -0000

>> I propose: "This work will address security and privacy issues arising
>> from the protocol design." and leave it at that.
>
> I think that it is useful to specify a reasonable expectation that is not
> unrealistic. Otherwise, we might end up in never ending discussions within
> the working group.

But right now it's ok?

Charter formation doesn't seem like the right place to constrain the
space of security and privacy properties with references to existing
protocols, the relationships to QUIC of which aren't yet fully
understood and the precise meanings of which are not clear. (E.g., is
"as good as a stack composed of TLS1.3 using TCP" even well defined?)

OTOH, I think we can all agree that QUIC needs to "address security
and privacy issues", and can pursue clarification of the implications
of that statement within the WG via rough consensus.

+1 to Martin's proposal to keep the wording in the charter high-level.


From nobody Tue May 24 14:49:26 2016
Return-Path: 
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 6CABE12D9DF for ; Tue, 24 May 2016 14:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 d9eGJU8nO6ll for ; Tue, 24 May 2016 14:49:20 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB40F12D9E0 for ; Tue, 24 May 2016 14:49:19 -0700 (PDT)
Received: from [192.168.1.109] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7432E22E259; Tue, 24 May 2016 17:49:13 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 25 May 2016 07:49:11 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>       
To: Kyle Rose 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Olivier Bonaventure , Christian Huitema , "Scharf, Michael \(Nokia - DE\)" , Ryan Hamilton , Jana Iyengar , Brian Trammell , "quic@ietf.org" , Martin Thomson 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 21:49:24 -0000

The point of including something like this in a charter is to serve as a =
contract between the WG and the rest of the community; it states the =
expectations upon the work, so everyone's on the same page.=20

It also gives the chair(s) a way to short-circuit unproductive =
discussions, if they stray past the expressed limits. Given the scope of =
this work, I think any and all such advice we can get into the charter =
will be helpful.

That doesn't mean it has to be design-in-charter; it only needs to =
define a floor. I think the text Jana came up with served that purpose =
well. We can always exceed it, based upon justifications other than the =
charter.

Cheers,


> On 25 May 2016, at 7:19 AM, Kyle Rose  wrote:
>=20
>>> I propose: "This work will address security and privacy issues =
arising
>>> from the protocol design." and leave it at that.
>>=20
>> I think that it is useful to specify a reasonable expectation that is =
not
>> unrealistic. Otherwise, we might end up in never ending discussions =
within
>> the working group.
>=20
> But right now it's ok?
>=20
> Charter formation doesn't seem like the right place to constrain the
> space of security and privacy properties with references to existing
> protocols, the relationships to QUIC of which aren't yet fully
> understood and the precise meanings of which are not clear. (E.g., is
> "as good as a stack composed of TLS1.3 using TCP" even well defined?)
>=20
> OTOH, I think we can all agree that QUIC needs to "address security
> and privacy issues", and can pursue clarification of the implications
> of that statement within the WG via rough consensus.
>=20
> +1 to Martin's proposal to keep the wording in the charter high-level.

--
Mark Nottingham   https://www.mnot.net/





From nobody Tue May 24 15:41:27 2016
Return-Path: 
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 A90FF12B053 for ; Tue, 24 May 2016 15:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.426
X-Spam-Level: 
X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 X2N0dXqCjzfJ for ; Tue, 24 May 2016 15:41:23 -0700 (PDT)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 4CC3812B007 for ; Tue, 24 May 2016 15:41:23 -0700 (PDT)
Received: by mail-it0-x235.google.com with SMTP id e62so61005355ita.1 for ; Tue, 24 May 2016 15:41:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Zgp8ClO8VaiqbgvEG4gv0AuAXFD1wbhvfeyjBt6pmJA=; b=MmfKiXknBtokGiFw8r8qnxD4VO4meqPqhOPNGLU3L/CtL51oP6J9tJ+TOa7GXli4u9 fG77ooDXJsOLvp4Qr37HV+R7l3ydxlwNZHMRhWBbDC5je4l11WbaaFo4kz2YHXoS3+Ud jiWpjCmXnKXBKe5TY/ixBYM3Guyngr+UJt+o21n8naAXQf2WkHn6ezCOQKrURHJs0XTv m/Z0uDh7jZdP7rFc9kIaQZzeGMKp9wLFYan/XyMdBgOmVNwNniQHGxxnrQLkA0vlOKD8 +0VxQKNkYuvyBHCWswIaT3gB1jpCkeNe3tX3uk56HG/Qp4dJdfgM8OY2vXeqy0So85FH ZMGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Zgp8ClO8VaiqbgvEG4gv0AuAXFD1wbhvfeyjBt6pmJA=; b=R4YJsmyD82qX5T2VirY45Qpl+duM+H7XqyML7CiwZfesbY83jc+70Q4yv5Eeu2PND2 jLWcRmtsF6/Qei5T34R2uTM5HY5ZP6mskJpD2B8Znn3lkHsAVUq6UIByaN5FlNr83NGM k9UQ48IDDXDO73LRjhYssVJzzOHjOZYSKbu4pltagD3pMkKUn8Lfr32TgyYv0Q/cQqeJ tcqbUa0lgNfI86gKvkneIIKrX8fE6SCIy2QvR2BvJuD55usGj2aNa5VgDIITYTmtE6PX ar3u7Tx/h4Yd33zeMbkyvrtLyqfyzxNUA5kxHvEri71vf7RYqICkd0Taf0suYSUjA5QK UQZw==
X-Gm-Message-State: ALyK8tJy+Dh13635msTDa0dLrOZzqaDOwlVm4VkcXHZfIrblvd56mJwEJqQiWJ9rjKKc+A03c7m5KgtIenY1D+f8
X-Received: by 10.36.33.196 with SMTP id e187mr13030344ita.30.1464129682494; Tue, 24 May 2016 15:41:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.227.227 with HTTP; Tue, 24 May 2016 15:41:02 -0700 (PDT)
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A2A818487@bgb01xud1012>
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>         <0AE43B24-8B4A-4F9C-AF93-F4222268E072@mnot.net> <7CF7F94CB496BF4FAB1676F375F9666A2A81644B@bgb01xud1012>  <7CF7F94CB496BF4FAB1676F375F9666A2A818487@bgb01xud1012>
From: Ian Swett 
Date: Tue, 24 May 2016 18:41:02 -0400
Message-ID: 
To: Lucas Pardue 
Content-Type: multipart/alternative; boundary=001a1146ee38a1a7a005339e41ee
Archived-At: 
Cc: Ted Hardie , "Julian F. Reschke" , Cory Benfield , Mark Nottingham , Jana Iyengar , Christian Huitema , "quic@ietf.org" , Martin Thomson 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 May 2016 22:41:26 -0000

--001a1146ee38a1a7a005339e41ee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm happy with that addition.

On Tue, May 24, 2016 at 12:36 PM, Lucas Pardue 
wrote:

> I think a simple sentence in the paragraph discussing the third focus are=
a
> would suffice. Something such as:
>
>
>
> =E2=80=9CThis mapping will accommodate the extension mechanisms defined i=
n the
> HTTP/2 specification.=E2=80=9D
>
>
>
> Lucas
>
>
>
> *From:* Ian Swett [mailto:ianswett@google.com]
> *Sent:* 24 May 2016 16:54
> *To:* Lucas Pardue 
> *Cc:* Mark Nottingham ; Martin Thomson <
> martin.thomson@gmail.com>; Ted Hardie ; Julian F.
> Reschke ; Cory Benfield ;
> Christian Huitema ; Jana Iyengar ;
> quic@ietf.org
>
> *Subject:* Re: [QUIC] Choice of area (and scope of work)
>
>
>
> All streams guarantee in order delivery, so HTTP/2 extension frames could
> be sent on a different stream if desired.
>
>
>
> QUIC definitely needs to be able to accommodate extensions to H2,
> otherwise it's not really supporting H2.  That could be stated explicitly
> if it's important to clarify?
>
>
>
> On Tue, May 24, 2016 at 11:37 AM, Lucas Pardue 
> wrote:
>
> Bringing this back to the original topic - the charter - is it worth
> adding text to indicate that the scope of third focus area work includes
> the ability to accommodate extensions to HTTP/2. If it is possible to
> achieve this by specifying simple reusable recipes for the blocking and
> non-blocking cases, then so much the better. Otherwise, each new extensio=
n
> will need to explicitly specify the required mappings to h2c/h2 and h2q.
>
> Ryan has made a suggestion to send HTTP/2 extension frames on the QUIC
> Headers stream (stream 3). It seems sub-optimal to mix such frames, which
> will be dropped if unknown/unsupported, with the HEADERS frames. Could su=
ch
> frames be sent on other streams, and can other streams provide in-order
> guarantees as Martin seems to suggest?
>
> Lucas
>
>
> > -----Original Message-----
> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham
> > Sent: 24 May 2016 02:28
> > To: Martin Thomson 
> > Cc: Ted Hardie ; Julian F. Reschke
> > ; Ian Swett ; Cory Benfield
> > ; Christian Huitema ; Jana
> > Iyengar ; quic@ietf.org
> > Subject: Re: [QUIC] Choice of area (and scope of work)
> >
> >
> > > On 24 May 2016, at 6:27 AM, Martin Thomson
> >  wrote:
> > >
> > > On 23 May 2016 at 16:03, Jana Iyengar  wrote:
> > >> By extension, HTTP/2 extensions will by default extend h2 and not
> > >> h2q, and may rely on TCP underneath. As a rule, I think we have to
> > >> assume that they'll need to explicitly map to QUIC.
> > >
> > > I think that this is the safest assumption.  Extensions for "h2" don'=
t
> > > immediately port to "h2q".
> > >
> > > That said, we do have in order guarantees on both stream 3 and stream
> > > N, so maybe, just maybe, there is a simple set of guidelines we can
> > > produce that will be generally applicable to most, if not all,
> > > extensions.
> >
> > +1. We should be looking at how we can minimise the differences whereve=
r
> > possible.
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
>
> > _______________________________________________
> > QUIC mailing list
> > QUIC@ietf.org
> > https://www.ietf.org/mailman/listinfo/quic
>
>
>

--001a1146ee38a1a7a005339e41ee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I'm happy with that addition.

On Tue, May 24, 2016 at 12:36 PM, Lu=
cas Pardue <Lucas.Pardue@bbc.co.uk> wrote:











I think a simple sente=
nce in the paragraph discussing the third focus area would suffice. Somethi=
ng such as:


=C2=A0


=E2=80=9CThis mapping =
will accommodate the extension mechanisms defined in the HTTP/2 specificati=
on.=E2=80=9D


=C2=A0


Lucas


=C2=A0








From: Ian Swett [mailto:ianswett@google.com]


Sent: 24 May 2016 16:54

To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>

Cc: Mark Nottingham <mnot@mnot.net>; Martin Thomson <martin.thomson@gmail.com>; Ted H=
ardie <ted.ietf@=
gmail.com>; Julian F. Reschke <julian.reschke@gmx.de>; Cory Benfield <<=
a href=3D"mailto:cory@lukasa.co.uk" target=3D"_blank">cory@lukasa.co.uk=
>; Christian Huitema <huitema@microsoft.com>; Jana Iyengar <jri@google.com>;
 quic@ietf.org


Subject: Re: [QUIC] Choice of area (and scope of work)=







=C2=A0




All streams guarantee in order delivery, so HTTP/2 e=
xtension frames could be sent on a different stream if desired. =C2=A0




=C2=A0






QUIC definitely needs to be able to accommodate exte=
nsions to H2, otherwise it's not really supporting H2.=C2=A0 That could=
 be stated explicitly if it's important to clarify?








=C2=A0




On Tue, May 24, 2016 at 11:37 AM, Lucas Pardue <<=
a href=3D"mailto:Lucas.Pardue@bbc.co.uk" target=3D"_blank">Lucas.Pardue@bbc=
.co.uk> wrote:




Bringing this back to the original topic - the chart=
er - is it worth adding text to indicate that the scope of third focus area=
 work includes the ability to accommodate extensions to HTTP/2. If it is po=
ssible to achieve this by specifying
 simple reusable recipes for the blocking and non-blocking cases, then so m=
uch the better. Otherwise, each new extension will need to explicitly speci=
fy the required mappings to h2c/h2 and h2q.



Ryan has made a suggestion to send HTTP/2 extension frames on the QUIC Head=
ers stream (stream 3). It seems sub-optimal to mix such frames, which will =
be dropped if unknown/unsupported, with the HEADERS frames. Could such fram=
es be sent on other streams, and
 can other streams provide in-order guarantees as Martin seems to suggest?<=
br>


Lucas








> -----Original Message-----

> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham

> Sent: 24 May 2016 02:28

> To: Martin Thomson <martin.thomson@gmail.com>

> Cc: Ted Hardie <ted.ietf@gmail.com>; Julian F. Reschke

> <julian.=
reschke@gmx.de>; Ian Swett <ianswett@google.com>; Cory Benfield

> <cory@lukasa=
.co.uk>; Christian Huitema <huitema@microsoft.com>; Jana

> Iyengar <jri@go=
ogle.com>; 
quic@ietf.org

> Subject: Re: [QUIC] Choice of area (and scope of work)

>

>

> > On 24 May 2016, at 6:27 AM, Martin Thomson

> <mart=
in.thomson@gmail.com> wrote:

> >

> > On 23 May 2016 at 16:03, Jana Iyengar <jri@google.com> wrote:

> >> By extension, HTTP/2 extensions will by default extend h2 and=
 not

> >> h2q, and may rely on TCP underneath. As a rule, I think we ha=
ve to

> >> assume that they'll need to explicitly map to QUIC.

> >

> > I think that this is the safest assumption.=C2=A0 Extensions for =
"h2" don't

> > immediately port to "h2q".

> >

> > That said, we do have in order guarantees on both stream 3 and st=
ream

> > N, so maybe, just maybe, there is a simple set of guidelines we c=
an

> > produce that will be generally applicable to most, if not all,
> > extensions.

>

> +1. We should be looking at how we can minimise the differences wherev=
er

> possible.

>

> --

> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

>










> _______________________________________________=


> QUIC mailing list

> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic










=C2=A0














--001a1146ee38a1a7a005339e41ee--


From nobody Tue May 24 18:03:47 2016
Return-Path: 
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 4401712D5D7 for ; Tue, 24 May 2016 18:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 7euTthvzrEex for ; Tue, 24 May 2016 18:03:43 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5622112B028 for ; Tue, 24 May 2016 18:03:43 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2A0EF22E255; Tue, 24 May 2016 21:03:33 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 25 May 2016 11:03:31 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <66773225-32D8-4AB5-A54D-FB35E84EB79A@mnot.net>   <77c1916b-32b0-aa38-ff29-b1bece17c573@gmx.de>         <0AE43B24-8B4A-4F9C-AF93-F4222268E072@mnot.net> <7CF7F94CB496BF4FAB1676F375F9666A2A81644B@bgb01xud1012>  <7 CF7F94CB496BF4FAB1676F375F9666A2A818487@bgb01xud1012> 
To: Ian Swett 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Ted Hardie , "Julian F. Reschke" , Lucas Pardue , Cory Benfield , Jana Iyengar , Christian Huitema , "quic@ietf.org" , Martin Thomson 
Subject: Re: [QUIC] Choice of area (and scope of work)
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 01:03:46 -0000

+1.=20


> On 25 May 2016, at 8:41 AM, Ian Swett  wrote:
>=20
> I'm happy with that addition.
>=20
> On Tue, May 24, 2016 at 12:36 PM, Lucas Pardue =
 wrote:
> I think a simple sentence in the paragraph discussing the third focus =
area would suffice. Something such as:
>=20
> =20
>=20
> =E2=80=9CThis mapping will accommodate the extension mechanisms =
defined in the HTTP/2 specification.=E2=80=9D
>=20
> =20
>=20
> Lucas
>=20
> =20
>=20
> From: Ian Swett [mailto:ianswett@google.com]=20
> Sent: 24 May 2016 16:54
> To: Lucas Pardue 
> Cc: Mark Nottingham ; Martin Thomson =
; Ted Hardie ; Julian F. =
Reschke ; Cory Benfield ; =
Christian Huitema ; Jana Iyengar =
; quic@ietf.org
>=20
>=20
> Subject: Re: [QUIC] Choice of area (and scope of work)
>=20
> =20
>=20
> All streams guarantee in order delivery, so HTTP/2 extension frames =
could be sent on a different stream if desired. =20
>=20
> =20
>=20
> QUIC definitely needs to be able to accommodate extensions to H2, =
otherwise it's not really supporting H2.  That could be stated =
explicitly if it's important to clarify?
>=20
> =20
>=20
> On Tue, May 24, 2016 at 11:37 AM, Lucas Pardue =
 wrote:
>=20
> Bringing this back to the original topic - the charter - is it worth =
adding text to indicate that the scope of third focus area work includes =
the ability to accommodate extensions to HTTP/2. If it is possible to =
achieve this by specifying simple reusable recipes for the blocking and =
non-blocking cases, then so much the better. Otherwise, each new =
extension will need to explicitly specify the required mappings to =
h2c/h2 and h2q.
>=20
> Ryan has made a suggestion to send HTTP/2 extension frames on the QUIC =
Headers stream (stream 3). It seems sub-optimal to mix such frames, =
which will be dropped if unknown/unsupported, with the HEADERS frames. =
Could such frames be sent on other streams, and can other streams =
provide in-order guarantees as Martin seems to suggest?
>=20
> Lucas
>=20
>=20
> > -----Original Message-----
> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark =
Nottingham
> > Sent: 24 May 2016 02:28
> > To: Martin Thomson 
> > Cc: Ted Hardie ; Julian F. Reschke
> > ; Ian Swett ; Cory =
Benfield
> > ; Christian Huitema ; Jana
> > Iyengar ; quic@ietf.org
> > Subject: Re: [QUIC] Choice of area (and scope of work)
> >
> >
> > > On 24 May 2016, at 6:27 AM, Martin Thomson
> >  wrote:
> > >
> > > On 23 May 2016 at 16:03, Jana Iyengar  wrote:
> > >> By extension, HTTP/2 extensions will by default extend h2 and not
> > >> h2q, and may rely on TCP underneath. As a rule, I think we have =
to
> > >> assume that they'll need to explicitly map to QUIC.
> > >
> > > I think that this is the safest assumption.  Extensions for "h2" =
don't
> > > immediately port to "h2q".
> > >
> > > That said, we do have in order guarantees on both stream 3 and =
stream
> > > N, so maybe, just maybe, there is a simple set of guidelines we =
can
> > > produce that will be generally applicable to most, if not all,
> > > extensions.
> >
> > +1. We should be looking at how we can minimise the differences =
wherever
> > possible.
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
>=20
> > _______________________________________________
> > QUIC mailing list
> > QUIC@ietf.org
> > https://www.ietf.org/mailman/listinfo/quic
>=20
> =20
>=20
>=20

--
Mark Nottingham   https://www.mnot.net/


From nobody Tue May 24 18:09:42 2016
Return-Path: 
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 9846B12B028 for ; Tue, 24 May 2016 18:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Q303diDOKeQk for ; Tue, 24 May 2016 18:09:39 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEA112D100 for ; Tue, 24 May 2016 18:09:39 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9D82322E253; Tue, 24 May 2016 21:09:37 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 25 May 2016 11:09:35 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <8527CD85-3BD9-4D53-ACCC-8807813B69E9@mnot.net>
References:     
To: Ian Swett 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , "quic@ietf.org" , =?utf-8?Q?G=C3=B6ran_Eriksson_AP?= 
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 01:09:41 -0000

That's a good list, but I was thinking more about the specific word =
"negotiation" -- to many people, it implies that one peer will offer =
zero to many options, the other peer will select zero or more of them, =
and communicate that choice back to the first peer (or a roughly similar =
process).

We consciously didn't call it "negotiation" in HTTP/2 because we didn't =
want the RT; instead, a peer advertises its configuration and the other =
side accommodates it, or they fail to communicate. It's true that you =
can hammer SETTINGS into a negotiation mechanism, but it's designed not =
to require that style of interaction.

I'm probably focusing too much on one word :) -- just wanted to make =
sure that people didn't assume a particular style of interaction here.

Cheers,


> On 25 May 2016, at 1:46 AM, Ian Swett  wrote:
>=20
> Mark, I think I understand the confusion.  You're thinking of a third =
feature advertisement that's separate from version negotiation and =
options negotiation.
>=20
> To provide some examples:
> 1) Version negotiation: Allows changing critical protocol elements, =
such as what the encoding of the public flags mean.  For example, one =
could imagine we decide QUIC needs 0, 8 or 16 byte connection ids.  That =
would require protocol version negotiation.
> 2) Option negotiation:  Allows adding new functionality, likely within =
the encrypted envelope.  For example, the ability to do multipath or FEC =
or any transport level feature.  This allows different organizations to =
experiment with different features, similar to how TCP does with =
options, but without the deployment challenges of unencrypted TCP =
options.
> 3) Application level negotiation: This would be specific to the =
application running on top of QUIC, and hopefully as Ryan said, would be =
in the scope of any mapping document.
>=20
> On Tue, May 24, 2016 at 1:51 AM, G=C3=B6ran Eriksson AP =
 wrote:
>=20
> >I can see multipath as "configurable" protocol behavior; if folks =
think
> >thats reasonable, I'm fine with using "configuration" instead of =
"options
> >negotiation".
>=20
> I understand that to mean QUIC can be =E2=80=9Cconfigured=E2=80=9D to =
be turned on or off
> multi path at least, or more advanced, detailed configuration of it =
multi
> path selection?
>=20
> Regards
> G=C3=B6ran
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>=20

--
Mark Nottingham   https://www.mnot.net/


From nobody Tue May 24 18:17:40 2016
Return-Path: 
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 EAAF312D100 for ; Tue, 24 May 2016 18:17:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 P23RSijk5Ytn for ; Tue, 24 May 2016 18:17:36 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 8259F12D521 for ; Tue, 24 May 2016 18:17:35 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id z87so16136898wmh.1 for ; Tue, 24 May 2016 18:17:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VPGO3WuvQgk3aXReMUuQIPBZA/Y4lzi9wQlYA+2psJ8=; b=nG+8oTZtly8Hq1A5batZTyWLkQhc4A8aCxnafReceXE+TqV/RyeVsbXfI/MhPOqMVp fIxotOx+1vyPBZfuF/UlOLvgJFuX1N/lSf8rfmrmV8I2pboYXvOIFi+NVk2nhF3HO9Q2 MCDiEahOz/JNRjMlXTUrCrnZVngYqvjMKNPHFuAPgR5F34O0t3gURJMOCOdn/GOTVZfg qk5JlQTOZ8hAib9/WeYip5csekiqN+xaJQyebxJvtZBvGqi9kjYnahMvooXC1zrGYsrG doLL1gKelbZdpziV7C33XsclZwAIA9oqmMo7CGnL5bDBfyLWDPHrOQYi02TlZ1D8D9NL zk6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VPGO3WuvQgk3aXReMUuQIPBZA/Y4lzi9wQlYA+2psJ8=; b=NiKLdEH21fmmxLS8hbjhQvaTiPb3NR5wcQvnmSk305e6LYlwzj2F+K7z6EXqAvO/eF AcxN8XEXhhVU+2L8I8+V0NFsLecA8vgAMfzo/MoZL/cHs6s/cWXqXXPbhUnamrCkQ/gp 7iGHzTCp3f+RgJ/QKa0/QH1CCsW+oeUZy2sH7CQ1947yJOM5+Ioo+OT17v+4Yubp9rg0 rDuOkpa54wZHIJ2e7JKMURs7uNzzfoTEW4WyaYu7k4aEnNr7U80ssjy5XPNGrjrJkeTt c0nWotOTC6WAAGueHA1L+aJm2k5kJbwL/frqXmbgzKHBYPs4k3LlnKhYpsTs/s3vJAwU zADg==
X-Gm-Message-State: ALyK8tKEtudvehNVC9DX9noT3KMr+b7hv/5JyyjUIBPnnZj2WDhpy7E9ct2m+v4gBRJ2G/KOIEzE1q9N7MILqlul
X-Received: by 10.194.173.161 with SMTP id bl1mr860334wjc.11.1464139053853; Tue, 24 May 2016 18:17:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.31.85 with HTTP; Tue, 24 May 2016 18:17:33 -0700 (PDT)
In-Reply-To: <8527CD85-3BD9-4D53-ACCC-8807813B69E9@mnot.net>
References:      <8527CD85-3BD9-4D53-ACCC-8807813B69E9@mnot.net>
From: Ryan Hamilton 
Date: Tue, 24 May 2016 18:17:33 -0700
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=089e013c63363530700533a0701f
Archived-At: 
Cc: Jana Iyengar , Ian Swett , "quic@ietf.org" , =?UTF-8?Q?G=C3=B6ran_Eriksson_AP?= 
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 01:17:39 -0000

--089e013c63363530700533a0701f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This is a totally fair point, Mark. The way QUIC works today, the handshake
"negotiates" (in the way you're using the word) things like the cipher
suite and key exchange methods. But the handshake also "negotiates" (in the
way HTTP/2 SETTINGS work) a number of other features.

So if "configuration" is perhaps problematic because it seems too static
(to Ian) and "negotiation is perhaps problematic because it seems too
dynamic (to you) we could say "protocol feature negotiation and
configuration".

Perhaps that's too verbose and clunky though?

On Tue, May 24, 2016 at 6:09 PM, Mark Nottingham  wrote:

> That's a good list, but I was thinking more about the specific word
> "negotiation" -- to many people, it implies that one peer will offer zero
> to many options, the other peer will select zero or more of them, and
> communicate that choice back to the first peer (or a roughly similar
> process).
>
> We consciously didn't call it "negotiation" in HTTP/2 because we didn't
> want the RT; instead, a peer advertises its configuration and the other
> side accommodates it, or they fail to communicate. It's true that you can
> hammer SETTINGS into a negotiation mechanism, but it's designed not to
> require that style of interaction.
>
> I'm probably focusing too much on one word :) -- just wanted to make sure
> that people didn't assume a particular style of interaction here.
>
> Cheers,
>
>
> > On 25 May 2016, at 1:46 AM, Ian Swett  wrote:
> >
> > Mark, I think I understand the confusion.  You're thinking of a third
> feature advertisement that's separate from version negotiation and option=
s
> negotiation.
> >
> > To provide some examples:
> > 1) Version negotiation: Allows changing critical protocol elements, suc=
h
> as what the encoding of the public flags mean.  For example, one could
> imagine we decide QUIC needs 0, 8 or 16 byte connection ids.  That would
> require protocol version negotiation.
> > 2) Option negotiation:  Allows adding new functionality, likely within
> the encrypted envelope.  For example, the ability to do multipath or FEC =
or
> any transport level feature.  This allows different organizations to
> experiment with different features, similar to how TCP does with options,
> but without the deployment challenges of unencrypted TCP options.
> > 3) Application level negotiation: This would be specific to the
> application running on top of QUIC, and hopefully as Ryan said, would be =
in
> the scope of any mapping document.
> >
> > On Tue, May 24, 2016 at 1:51 AM, G=C3=B6ran Eriksson AP <
> goran.ap.eriksson@ericsson.com> wrote:
> >
> > >I can see multipath as "configurable" protocol behavior; if folks thin=
k
> > >thats reasonable, I'm fine with using "configuration" instead of
> "options
> > >negotiation".
> >
> > I understand that to mean QUIC can be =E2=80=9Cconfigured=E2=80=9D to b=
e turned on or off
> > multi path at least, or more advanced, detailed configuration of it mul=
ti
> > path selection?
> >
> > Regards
> > G=C3=B6ran
> >
> > _______________________________________________
> > QUIC mailing list
> > QUIC@ietf.org
> > https://www.ietf.org/mailman/listinfo/quic
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>

--089e013c63363530700533a0701f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


This is a totally fair point, Mark. The way QUIC works tod=
ay, the handshake "negotiates" (in the way you're using the w=
ord) things like the cipher suite and key exchange methods. But the handsha=
ke also "negotiates" (in the way HTTP/2 SETTINGS work) a number o=
f other features.

So if "configuration" is perhaps=
 problematic because it seems too static (to Ian) and "negotiation is =
perhaps problematic because it seems too dynamic (to you) we could say &quo=
t;protocol feature negotiation and configuration".=C2=A0


On Tue, May 24, 2016 at 6:0=
9 PM, Mark Nottingham <mnot@mnot.net> wrote:
That's a good list, but I was thinking more about the sp=
ecific word "negotiation" -- to many people, it implies that one =
peer will offer zero to many options, the other peer will select zero or mo=
re of them, and communicate that choice back to the first peer (or a roughl=
y similar process).



We consciously didn't call it "negotiation" in HTTP/2 because=
 we didn't want the RT; instead, a peer advertises its configuration an=
d the other side accommodates it, or they fail to communicate. It's tru=
e that you can hammer SETTINGS into a negotiation mechanism, but it's d=
esigned not to require that style of interaction.



I'm probably focusing too much on one word :) -- just wanted to make su=
re that people didn't assume a particular style of interaction here.


Cheers,






> On 25 May 2016, at 1:46 AM, Ian Swett <ianswett@google.com> wrote:

>

> Mark, I think I understand the confusion.=C2=A0 You're thinking of=
 a third feature advertisement that's separate from version negotiation=
 and options negotiation.

>

> To provide some examples:

> 1) Version negotiation: Allows changing critical protocol elements, su=
ch as what the encoding of the public flags mean.=C2=A0 For example, one co=
uld imagine we decide QUIC needs 0, 8 or 16 byte connection ids.=C2=A0 That=
 would require protocol version negotiation.

> 2) Option negotiation:=C2=A0 Allows adding new functionality, likely w=
ithin the encrypted envelope.=C2=A0 For example, the ability to do multipat=
h or FEC or any transport level feature.=C2=A0 This allows different organi=
zations to experiment with different features, similar to how TCP does with=
 options, but without the deployment challenges of unencrypted TCP options.=


> 3) Application level negotiation: This would be specific to the applic=
ation running on top of QUIC, and hopefully as Ryan said, would be in the s=
cope of any mapping document.

>

> On Tue, May 24, 2016 at 1:51 AM, G=C3=B6ran Eriksson AP <goran.ap.eriksson@ericsson.com&=
gt; wrote:

>

> >I can see multipath as "configurable" protocol behavior;=
 if folks think

> >thats reasonable, I'm fine with using "configuration"=
; instead of "options

> >negotiation".

>

> I understand that to mean QUIC can be =E2=80=9Cconfigured=E2=80=9D to =
be turned on or off

> multi path at least, or more advanced, detailed configuration of it mu=
lti

> path selection?

>

> Regards

> G=C3=B6ran

>

> _______________________________________________

> QUIC mailing list

> QUIC@ietf.org

> https://www.ietf.org/mailman/listinfo/quic

>




--

Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/




____________________________=
___________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--089e013c63363530700533a0701f--


From nobody Tue May 24 18:20:34 2016
Return-Path: 
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 0423712D5E2 for ; Tue, 24 May 2016 18:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 wKDXgvWLMd5K for ; Tue, 24 May 2016 18:20:27 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B09812D520 for ; Tue, 24 May 2016 18:20:27 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CBE8222E255; Tue, 24 May 2016 21:20:24 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 25 May 2016 11:20:22 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:      <8527CD85-3BD9-4D53-ACCC-8807813B69E9@mnot.net> 
To: Ryan Hamilton 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jana Iyengar , Ian Swett , "quic@ietf.org" , =?utf-8?Q?G=C3=B6ran_Eriksson_AP?= 
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 01:20:31 -0000

Honestly, as long as people don't read too much into that word I'm =
happy. Having this discussion serves the purpose enough for me, we don't =
need to wordsmith too much.

Cheers,


> On 25 May 2016, at 11:17 AM, Ryan Hamilton  wrote:
>=20
> This is a totally fair point, Mark. The way QUIC works today, the =
handshake "negotiates" (in the way you're using the word) things like =
the cipher suite and key exchange methods. But the handshake also =
"negotiates" (in the way HTTP/2 SETTINGS work) a number of other =
features.
>=20
> So if "configuration" is perhaps problematic because it seems too =
static (to Ian) and "negotiation is perhaps problematic because it seems =
too dynamic (to you) we could say "protocol feature negotiation and =
configuration".=20
>=20
> Perhaps that's too verbose and clunky though?
>=20
> On Tue, May 24, 2016 at 6:09 PM, Mark Nottingham  =
wrote:
> That's a good list, but I was thinking more about the specific word =
"negotiation" -- to many people, it implies that one peer will offer =
zero to many options, the other peer will select zero or more of them, =
and communicate that choice back to the first peer (or a roughly similar =
process).
>=20
> We consciously didn't call it "negotiation" in HTTP/2 because we =
didn't want the RT; instead, a peer advertises its configuration and the =
other side accommodates it, or they fail to communicate. It's true that =
you can hammer SETTINGS into a negotiation mechanism, but it's designed =
not to require that style of interaction.
>=20
> I'm probably focusing too much on one word :) -- just wanted to make =
sure that people didn't assume a particular style of interaction here.
>=20
> Cheers,
>=20
>=20
> > On 25 May 2016, at 1:46 AM, Ian Swett  wrote:
> >
> > Mark, I think I understand the confusion.  You're thinking of a =
third feature advertisement that's separate from version negotiation and =
options negotiation.
> >
> > To provide some examples:
> > 1) Version negotiation: Allows changing critical protocol elements, =
such as what the encoding of the public flags mean.  For example, one =
could imagine we decide QUIC needs 0, 8 or 16 byte connection ids.  That =
would require protocol version negotiation.
> > 2) Option negotiation:  Allows adding new functionality, likely =
within the encrypted envelope.  For example, the ability to do multipath =
or FEC or any transport level feature.  This allows different =
organizations to experiment with different features, similar to how TCP =
does with options, but without the deployment challenges of unencrypted =
TCP options.
> > 3) Application level negotiation: This would be specific to the =
application running on top of QUIC, and hopefully as Ryan said, would be =
in the scope of any mapping document.
> >
> > On Tue, May 24, 2016 at 1:51 AM, G=C3=B6ran Eriksson AP =
 wrote:
> >
> > >I can see multipath as "configurable" protocol behavior; if folks =
think
> > >thats reasonable, I'm fine with using "configuration" instead of =
"options
> > >negotiation".
> >
> > I understand that to mean QUIC can be =E2=80=9Cconfigured=E2=80=9D =
to be turned on or off
> > multi path at least, or more advanced, detailed configuration of it =
multi
> > path selection?
> >
> > Regards
> > G=C3=B6ran
> >
> > _______________________________________________
> > QUIC mailing list
> > QUIC@ietf.org
> > https://www.ietf.org/mailman/listinfo/quic
> >
>=20
> --
> Mark Nottingham   https://www.mnot.net/
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>=20

--
Mark Nottingham   https://www.mnot.net/


From nobody Tue May 24 21:23:40 2016
Return-Path: 
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 3BE4812D603 for ; Tue, 24 May 2016 21:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 3p-0g7UCSNxl for ; Tue, 24 May 2016 21:23:38 -0700 (PDT)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 E19BD12D602 for ; Tue, 24 May 2016 21:23:37 -0700 (PDT)
Received: by mail-qg0-x22f.google.com with SMTP id f92so16981813qgf.0 for ; Tue, 24 May 2016 21:23:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=o0xtRv6ir+O9BGuEZjgNZleHCv0McJ/hxRByNlRsoaU=; b=kbCUvzg9xV3NFYx3JhM5ukSZ+MQUXYfbiyQCM10n8RC3EfzcDi4ufLwukNB7OOcra6 Hb2n63yIYe9MCOMzdj/I5DmrPoomxhbEzeUW6I6z5trsmJ1KROJ5Kma4QqPBLXkkPhpS FgEEsLYuxvf2Yl6h5JgGyQnkD4oOqvpD1m3gcZIgcebbs/QFLLISK0e40Hxd6CDJfdT7 jTxa1PK4b/gNmdB/QKbB8bbIEaViXBcridijh9va7ZtKHbmRAzNNBNAftnUiLuyJ8y9Q 3Z/+UJrHdrLdBconmTS94w6fgSSK8egX9Sc4pWWEaO7Bt51jX4bo4VuPWsxFApQnWIy1 KAhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=o0xtRv6ir+O9BGuEZjgNZleHCv0McJ/hxRByNlRsoaU=; b=CoTaYcQeWTuwwewBx08Cb/6jYGbyGkuccgGJZf8B3um1jHSQA61VVLKkJq23d25rcR 5li4WUcU6VhwY6C2k+PxQH4LJ6nh/M1BVADyvrPO3YcKmd4BZD+IeyT+z/mlNYQt0gSn MguUVlMuP2XXdR/6RSBGjH+cQe1bnSkICauzCQo88huTrnl227smyHhNOvSmnW3iX3JN +g/32+FOKOsgCGfDYolXyuT4WbAz0KpmfzisArbkZOHS+yv5cll9MbihU0jX6i5XkeaY qg341AUhLMA/3RBO45XAdkPkyKUd03BtARPbSnDyKKiR5G/Y5hqYUb4ZI5++/E7pLzYo SEwA==
X-Gm-Message-State: ALyK8tI2x/4xp3GoHEWdb2Lhs7mSIxv5sYFueQfxOKQl6xlxeqiKujZ8e155VhKEbbgfM25uY4HXLhHrliUErQ==
MIME-Version: 1.0
X-Received: by 10.140.101.240 with SMTP id u103mr1520961qge.61.1464150217046;  Tue, 24 May 2016 21:23:37 -0700 (PDT)
Received: by 10.140.104.70 with HTTP; Tue, 24 May 2016 21:23:36 -0700 (PDT)
In-Reply-To: 
References:      <8527CD85-3BD9-4D53-ACCC-8807813B69E9@mnot.net>  
Date: Tue, 24 May 2016 21:23:36 -0700
Message-ID: 
From: Martin Thomson 
To: Mark Nottingham 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: =?UTF-8?Q?G=C3=B6ran_Eriksson_AP?= , Jana Iyengar , Ian Swett , "quic@ietf.org" , Ryan Hamilton 
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 04:23:39 -0000

On 24 May 2016 at 18:20, Mark Nottingham  wrote:
> Honestly, as long as people don't read too much into that word I'm happy. Having this discussion serves the purpose enough for me, we don't need to wordsmith too much.


I see the following things being "negotiated" in the loosest sense of the word:

QUIC protocol version
Application protocol version
QUIC options/extensions/experiments
Application protocol settings (i.e., SETTINGS)
TLS version, cipher suite, etc...

Pretty much all of these things might be in scope, but the order of my
list is the order of importance.  I would like to see the last two
unchanged, but realize that we might discover a need to tweak those.
Versions and options do seem to be important, particularly if we
intend to maintain the spirit of the never-ending experiment.


From nobody Wed May 25 05:15:11 2016
Return-Path: 
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 9C74A12B022 for ; Wed, 25 May 2016 05:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 n07D9zMfCqwi for ; Wed, 25 May 2016 05:15:08 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1431012B00F for ; Wed, 25 May 2016 05:15:07 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-4f-5745974a20b2
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 02.14.12926.A4795475; Wed, 25 May 2016 14:15:06 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0294.000; Wed, 25 May 2016 14:15:05 +0200
From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= 
To: Ian Swett 
Thread-Topic: [QUIC] Version Negotiation vs. Option Negotiation
Thread-Index: AQHRsJ1wfont+Zxz+keecrKTcpwjSZ/F1BkAgAFzMgCAAFglgIAAhNGAgAF4pgA=
Date: Wed, 25 May 2016 12:15:05 +0000
Message-ID: 
References:     
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.4.160422
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="utf-8"
Content-ID: <08EA1E47E3BACE4D8AA08F57A0AC378E@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyM2K7iq7XdNdwg86DghY/7+1ktZh0dCGL xfpPjxktehZwO7B4LNhU6rFkyU8mj42Lv7MGMEdx2aSk5mSWpRbp2yVwZZx/+o294BR3xZMr B9kbGJdwdzFyckgImEhM/LCeBcIWk7hwbz1bFyMXh5DAEUaJjc0PoZwljBI3thxgA6liE/CW aGs5DNYhIqAscfTOJEYQm1kgVeLy3F+sILawgJ3Er2Vn2SBq7CUe37nIDmH7SdxYewWsnkVA VeLNhFawel4Ba4n2g7/ZIZYdYpL4vLEdrIhTIFDizMTbYDajgKzE/e/3WCCWiUvcejKfCeJs AYkle84zQ9iiEi8f/wMbKiqgJ/Hl3jxGiLiiRPvTBiCbA6hXU2L9Ln2IMdYSe9bvYIKwFSWm dD9kh7hHUOLkzCcsExglZiHZNguhexaS7llIumch6V7AyLqKUbQ4tTgpN93IWC+1KDO5uDg/ Ty8vtWQTIzBCD275rbqD8fIbx0OMAhyMSjy8D865hAuxJpYVV+YeYpTgYFYS4T0x1TVciDcl sbIqtSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0xJLU7NTUgtQimCwTB6dUA2OuP1vRzZJuqTVX 7707lcDRyJ9REXDV1N+aU++RwuxjrO0Z/r/0b6qlXOFW8/1ktsjLwz3OI+b1RP9FhTrbHsaa Suuatkwz+7VzhnPDvtJnjIYbRSKjZPmOfxbp+Wl8WWHf+njFHOPU3nI1XplzMdUn28SXVLbv lTq++VrBlvh1VXoHGyawKbEUZyQaajEXFScCACDyYvPMAgAA
Archived-At: 
Cc: Jana Iyengar , Mark Nottingham , "quic@ietf.org" 
Subject: Re: [QUIC] Version Negotiation vs. Option Negotiation
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 12:15:09 -0000

DQoNCj4xKSBWZXJzaW9uIG5lZ290aWF0aW9uOiBBbGxvd3MgY2hhbmdpbmcgY3JpdGljYWwgcHJv
dG9jb2wgZWxlbWVudHMsIHN1Y2gNCj5hcyB3aGF0IHRoZSBlbmNvZGluZyBvZiB0aGUgcHVibGlj
IGZsYWdzIG1lYW4uICBGb3IgZXhhbXBsZSwgb25lIGNvdWxkDQo+aW1hZ2luZSB3ZSBkZWNpZGUg
UVVJQyBuZWVkcyAwLCA4IG9yIDE2IGJ5dGUgY29ubmVjdGlvbiBpZHMuICBUaGF0IHdvdWxkDQo+
cmVxdWlyZSBwcm90b2NvbCB2ZXJzaW9uIG5lZ290aWF0aW9uLg0KPjIpIE9wdGlvbiBuZWdvdGlh
dGlvbjogIEFsbG93cyBhZGRpbmcgbmV3IGZ1bmN0aW9uYWxpdHksIGxpa2VseSB3aXRoaW4NCj50
aGUgZW5jcnlwdGVkIGVudmVsb3BlLiAgRm9yIGV4YW1wbGUsIHRoZSBhYmlsaXR5IHRvIGRvIG11
bHRpcGF0aCBvciBGRUMNCj5vciBhbnkgdHJhbnNwb3J0IGxldmVsIGZlYXR1cmUuICBUaGlzIGFs
bG93cyBkaWZmZXJlbnQgb3JnYW5pemF0aW9ucyB0bw0KPmV4cGVyaW1lbnQgd2l0aCBkaWZmZXJl
bnQgZmVhdHVyZXMsIHNpbWlsYXIgdG8gaG93IFRDUCBkb2VzIHdpdGggb3B0aW9ucywNCj5idXQg
d2l0aG91dCB0aGUgZGVwbG95bWVudCBjaGFsbGVuZ2VzIG9mIHVuZW5jcnlwdGVkIFRDUCBvcHRp
b25zLg0KDQorMQ0KDQo+MykgQXBwbGljYXRpb24gbGV2ZWwgbmVnb3RpYXRpb246IFRoaXMgd291
bGQgYmUgc3BlY2lmaWMgdG8gdGhlDQo+YXBwbGljYXRpb24gcnVubmluZyBvbiB0b3Agb2YgUVVJ
QywgYW5kIGhvcGVmdWxseSBhcyBSeWFuIHNhaWQsIHdvdWxkIGJlDQo+aW4gdGhlIHNjb3BlIG9m
IGFueSBtYXBwaW5nIGRvY3VtZW50Lg0KDQorMQ0KDQpJIGxpa2UgdGhlIGxpc3QuIEVzcGVjaWFs
bHkgdGhlIOKAnG9wdGlvbuKAnSBuZWdvdGlhdGlvbiBwYXJ0LiBDb3ZlcnMgbXVjaCBvZg0KdGhl
IGNvbmNlcm5zIEkgaGF2ZSBhYm91dCByZWxhdGlvbiBodHRwIGxheWVyIGFuZCBtdWx0aXBhdGgu
DQoNClRueCBmb3IgdGFraW5nIHRoaXMgZGlzY3Vzc2lvbiBhIHN0ZXAgZnVydGhlciAoTWFydGlu
4oCZcyBlbmhhbmNlZCBpdCBldmVuDQptb3JlLCB3aGljaCBpcyBncmVhdC4pDQoNCg0KDQoNCg==


From nobody Wed May 25 14:29:43 2016
Return-Path: 
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 D62EC12DDC0 for ; Wed, 25 May 2016 14:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 CPZpIm3EfOpC for ; Wed, 25 May 2016 14:29:40 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 79DD512DDCE for ; Wed, 25 May 2016 14:29:34 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id w184so90907970oiw.2 for ; Wed, 25 May 2016 14:29:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q0maRY9M7xBF7G9fY5QxAoDyigrdWAjvrADxUi5l/3A=; b=hdXn6zQPLjd9HZ5gWSbuc523nGFdIoSCh+JaX0Z+8S0STqhQsueRbZGDq7POri6mMC G25Jrhu7Gwgt/WUZ+P7zA1OQT/UvO7txWCbdHHsH+9ddaOQNZxVlzBQ9hI2mp3KK5/wj JLzI246VLBp8L1HvPVd+NmrBWzmjBIOXuoUYtii/pKmb1WwizI+dU/e2ZHQ/YIV9ONCu L8wWe+81wd0PKTrxKyXrqWzv/g0RiebynRZwzMYALgdPm9K910I0TC8fT+H2M6cIsI2s qirINoyDfKGn55U+TkbZMePSjrqARrN0g3b6LgI0WsXdG1tFUMR+QuIco3kiaFbMDUS8 qbKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q0maRY9M7xBF7G9fY5QxAoDyigrdWAjvrADxUi5l/3A=; b=jVgy5/suBnwr0+kFcqmcUMnjoIKqcR8LZfc5VEqiwNVk50aR5t6Ys4vJ7YUDf8qlHH CP1ecgpQ3tu6TtMwGknHlFRFWNYPBUByGr9QWOQUyxk5YE7FWRTGhSSp6phNbPjn23Fl kZGUERCgLBIMSkxLS5VqrFznZyoMZafyjLvfeEqlZXHDqEsUNoSjLYM9kgab3sHc1aNb /OJoESlMWoD7bN1KQMmEiGk1NL+L5GO0/J0SwOQEiVFS1Y2nWRG+AhptJYjRI6gdMBI6 JoBrqIOnOW8CDJmjhkiJnCqdDo5JHnc6p/Zvkk1qJ8Ey5A9sMjnPp5ogIglHFkspTMId dGDQ==
X-Gm-Message-State: ALyK8tKMC8K232i/IS1M0P0VITBYscFGMkkVDBDdT7HGuqvC7Sm3eq6Yu1QbIfTGUjrE8VtvhmJX8Om9WNOU8A==
X-Received: by 10.202.240.68 with SMTP id o65mr3898203oih.0.1464211773899; Wed, 25 May 2016 14:29:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.195.137 with HTTP; Wed, 25 May 2016 14:29:14 -0700 (PDT)
In-Reply-To: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>
From: Ted Hardie 
Date: Wed, 25 May 2016 14:29:14 -0700
Message-ID: 
To: Michael Tuexen 
Content-Type: multipart/alternative; boundary=94eb2c08fa66a8cb5a0533b15e14
Archived-At: 
Cc: quic@ietf.org
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2016 21:29:42 -0000

--94eb2c08fa66a8cb5a0533b15e14
Content-Type: text/plain; charset=UTF-8

On Tue, May 24, 2016 at 11:27 AM, Michael Tuexen <
Michael.Tuexen@lurchi.franken.de> wrote:

>
> But here is the question:
>
> Are there any plans to analyse the requirements in a protocol independent
> way and try to figure out if these requirements can also be met by evolving
> one or more of the existing transport protocols (in combination with the
> appropriate
> (D)TLS)? And then making a decision whether it is appropriate to
> evolve existing protocols in addition to or instead of developing a new
> one...
>
>
Being a yes-and kind of guy, I have to say I don't  see why evolving
existing protocols and developing news should be seen as in opposition.
The two can proceed in parallel and learn from each other (as QUIC has
certainly learned a lot on the congestion control front).

To put this another way, I think it is good for the Internet if new
protocols may be deployed; ossification is bad.  We can learn from the
deployments in a variety of ways.

Just my thinking,

regards,

Ted

--94eb2c08fa66a8cb5a0533b15e14
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Tue, May 24, 2016 at 11:27 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:


But here is the question:



Are there any plans to analyse the requirements in a protocol independent
way and try to figure out if these requirements can also be met by evolving=


one or more of the existing transport protocols (in combination with the ap=
propriate

(D)TLS)? And then making a decision whether it is appropriate to

evolve existing protocols in addition to or instead of developing a new one=
...



Being a yes-and kind of guy, I have to=
 say I don't=C2=A0 see why evolving existing protocols and developing n=
ews should be seen as in opposition.=C2=A0 The two can proceed in parallel =
and learn from each other (as QUIC has certainly learned a lot on the conge=
stion control front).

To put this another way, I think it=
 is good for the Internet if new protocols may be deployed; ossification is=
 bad.=C2=A0 We can learn from the deployments in a variety of ways.

=

Just my thinking,

regards,

T=
ed 



--94eb2c08fa66a8cb5a0533b15e14--


From nobody Thu May 26 00:50:53 2016
Return-Path: 
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 DE50B12D62D for ; Thu, 26 May 2016 00:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 KHhuvsK-27lL for ; Thu, 26 May 2016 00:50:50 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974ED12D501 for ; Thu, 26 May 2016 00:50:49 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-73-5746aad61158
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 35.24.12516.6DAA6475; Thu, 26 May 2016 09:50:46 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.166]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0294.000; Thu, 26 May 2016 09:50:46 +0200
From: Salvatore Loreto 
To: Ted Hardie , Michael Tuexen 
Thread-Topic: [QUIC] Requirements
Thread-Index: AQHRteupVC037JJ+CUSD4QPnrPZiOZ/KC5kAgADNCZA=
Date: Thu, 26 May 2016 07:50:45 +0000
Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A60DCC83A@ESESSMB109.ericsson.se>
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_2B9B48179856DC4FA00C93C79EB7E64A60DCC83AESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7n+61VW7hBgfnyllcbFrCaNGzgNui ca6dA7PHzll32T2WLPnJ5LGhZQdTAHMUl01Kak5mWWqRvl0CV8bMjtdsBa+8KrZMOsLYwPjA o4uRg0NCwETi0IfkLkZOIFNM4sK99WxdjFwcQgJHGCX+r37HAuEsYZRYtbyLBaSKTcBM4vnD LcwgtohAhMSGF+eYQGxmAWWJKacbWEFsYQEFiRdv5zFC1ChKrJq1Csq2kpjWPhesnkVAVWLr 7tdgcV4BX4mdt7dAbe5mlOifuJsdJMEpECixaHMP2DJGoPO+n1oDtUxc4taT+UwQZwtILNlz nhnCFpV4+fgfK4StKHF1+nKo+nyJmadb2SCWCUqcnPmEZQKj6Cwko2YhKZuFpGwWMJCYBTQl 1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwPg7 uOW37g7G1a8dDzEKcDAq8fAmKLiFC7EmlhVX5h5ilOBgVhLhVZkBFOJNSaysSi3Kjy8qzUkt PsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbLxMEp1cBYuUlB4VxWnO51bplr63Y2vXf+tDtN U/bh1ptNxt36S45UvrIs+OG16+2zIN4nrULbn+Zndr6NfrXS9qKH2wGJuadP8B/TLt4xcUI2 16WmrsTczOxOVXH7gy1OKy/O3LnJyCXjj9rMBPFvSes73qYkdfWwCojd/RF0ueMRi3Kw19Q/ IqfbyncqsRRnJBpqMRcVJwIAxDX3a7sCAAA=
Archived-At: 
Cc: "quic@ietf.org" 
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 07:50:52 -0000

--_000_2B9B48179856DC4FA00C93C79EB7E64A60DCC83AESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhZ3JlZSB3aXRoIFRlZA0KSSBkbyBub3Qgc2VlIG1vdmluZyBleGlzdGluZyBwcm90b2NvbHMg
b3ZlciBVRFAgYW5kIHRoZSBkZXZlbG9wbWVudCBvZiBuZXcgcHJvdG9jb2xzIG5hdGl2ZWx5IGRl
c2lnbmVkIHRvIHJ1biBvdmVyIFVEUCBsaWtlIHR3byB0aGluZ3MgaW4gb3Bwb3NpdGlvbg0KQWN0
dWFsbHkgSSBzZWUgYXMgYW4gb3Bwb3J0dW5pdHkgdG8gbGVhcm4gbW9yZSBhbmQgZG8gYSBiZXR0
ZXIgam9iIG9uIGJvdGggdGhlIHNpZGVzDQoNCi9TYWwNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1
aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBIYXJkaWUNClNlbnQ6IGRlbiAy
NSBtYWogMjAxNiAyMzoyOQ0KVG86IE1pY2hhZWwgVHVleGVuIDxNaWNoYWVsLlR1ZXhlbkBsdXJj
aGkuZnJhbmtlbi5kZT4NCkNjOiBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1FVSUNdIFJl
cXVpcmVtZW50cw0KDQpPbiBUdWUsIE1heSAyNCwgMjAxNiBhdCAxMToyNyBBTSwgTWljaGFlbCBU
dWV4ZW4gPE1pY2hhZWwuVHVleGVuQGx1cmNoaS5mcmFua2VuLmRlPG1haWx0bzpNaWNoYWVsLlR1
ZXhlbkBsdXJjaGkuZnJhbmtlbi5kZT4+IHdyb3RlOg0KDQpCdXQgaGVyZSBpcyB0aGUgcXVlc3Rp
b246DQoNCkFyZSB0aGVyZSBhbnkgcGxhbnMgdG8gYW5hbHlzZSB0aGUgcmVxdWlyZW1lbnRzIGlu
IGEgcHJvdG9jb2wgaW5kZXBlbmRlbnQNCndheSBhbmQgdHJ5IHRvIGZpZ3VyZSBvdXQgaWYgdGhl
c2UgcmVxdWlyZW1lbnRzIGNhbiBhbHNvIGJlIG1ldCBieSBldm9sdmluZw0Kb25lIG9yIG1vcmUg
b2YgdGhlIGV4aXN0aW5nIHRyYW5zcG9ydCBwcm90b2NvbHMgKGluIGNvbWJpbmF0aW9uIHdpdGgg
dGhlIGFwcHJvcHJpYXRlDQooRClUTFMpPyBBbmQgdGhlbiBtYWtpbmcgYSBkZWNpc2lvbiB3aGV0
aGVyIGl0IGlzIGFwcHJvcHJpYXRlIHRvDQpldm9sdmUgZXhpc3RpbmcgcHJvdG9jb2xzIGluIGFk
ZGl0aW9uIHRvIG9yIGluc3RlYWQgb2YgZGV2ZWxvcGluZyBhIG5ldyBvbmUuLi4NCg0KQmVpbmcg
YSB5ZXMtYW5kIGtpbmQgb2YgZ3V5LCBJIGhhdmUgdG8gc2F5IEkgZG9uJ3QgIHNlZSB3aHkgZXZv
bHZpbmcgZXhpc3RpbmcgcHJvdG9jb2xzIGFuZCBkZXZlbG9waW5nIG5ld3Mgc2hvdWxkIGJlIHNl
ZW4gYXMgaW4gb3Bwb3NpdGlvbi4gIFRoZSB0d28gY2FuIHByb2NlZWQgaW4gcGFyYWxsZWwgYW5k
IGxlYXJuIGZyb20gZWFjaCBvdGhlciAoYXMgUVVJQyBoYXMgY2VydGFpbmx5IGxlYXJuZWQgYSBs
b3Qgb24gdGhlIGNvbmdlc3Rpb24gY29udHJvbCBmcm9udCkuDQpUbyBwdXQgdGhpcyBhbm90aGVy
IHdheSwgSSB0aGluayBpdCBpcyBnb29kIGZvciB0aGUgSW50ZXJuZXQgaWYgbmV3IHByb3RvY29s
cyBtYXkgYmUgZGVwbG95ZWQ7IG9zc2lmaWNhdGlvbiBpcyBiYWQuICBXZSBjYW4gbGVhcm4gZnJv
bSB0aGUgZGVwbG95bWVudHMgaW4gYSB2YXJpZXR5IG9mIHdheXMuDQpKdXN0IG15IHRoaW5raW5n
LA0KcmVnYXJkcywNClRlZA0KDQo=

--_000_2B9B48179856DC4FA00C93C79EB7E64A60DCC83AESESSMB109erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp
bjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7
cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48
IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0
PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5
b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9
ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj5JIGFncmVlIHdpdGggVGVkPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4i
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMy
MjIyMjIiPkkgZG8gbm90IHNlZSBtb3ZpbmcgZXhpc3RpbmcgcHJvdG9jb2xzIG92ZXIgVURQIGFu
ZCB0aGUgZGV2ZWxvcG1lbnQgb2YgbmV3IHByb3RvY29scyBuYXRpdmVseSBkZXNpZ25lZCB0byBy
dW4gb3ZlciBVRFAgbGlrZSB0d28gdGhpbmdzIGluIG9wcG9zaXRpb248bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+QWN0dWFs
bHkgSSBzZWUgYXMgYW4gb3Bwb3J0dW5pdHkgdG8gbGVhcm4gbW9yZSBhbmQgZG8gYSBiZXR0ZXIg
am9iIG9uIGJvdGggdGhlIHNpZGVzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPi9TYWw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFFVSUMgW21h
aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlZCBIYXJk
aWU8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDI1IG1haiAyMDE2IDIzOjI5PGJyPg0KPGI+VG86PC9i
PiBNaWNoYWVsIFR1ZXhlbiAmbHQ7TWljaGFlbC5UdWV4ZW5AbHVyY2hpLmZyYW5rZW4uZGUmZ3Q7
PGJyPg0KPGI+Q2M6PC9iPiBxdWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb
UVVJQ10gUmVxdWlyZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUs
IE1heSAyNCwgMjAxNiBhdCAxMToyNyBBTSwgTWljaGFlbCBUdWV4ZW4gJmx0OzxhIGhyZWY9Im1h
aWx0bzpNaWNoYWVsLlR1ZXhlbkBsdXJjaGkuZnJhbmtlbi5kZSIgdGFyZ2V0PSJfYmxhbmsiPk1p
Y2hhZWwuVHVleGVuQGx1cmNoaS5mcmFua2VuLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KQnV0IGhlcmUgaXMgdGhlIHF1ZXN0aW9uOjxicj4NCjxi
cj4NCkFyZSB0aGVyZSBhbnkgcGxhbnMgdG8gYW5hbHlzZSB0aGUgcmVxdWlyZW1lbnRzIGluIGEg
cHJvdG9jb2wgaW5kZXBlbmRlbnQ8YnI+DQp3YXkgYW5kIHRyeSB0byBmaWd1cmUgb3V0IGlmIHRo
ZXNlIHJlcXVpcmVtZW50cyBjYW4gYWxzbyBiZSBtZXQgYnkgZXZvbHZpbmc8YnI+DQpvbmUgb3Ig
bW9yZSBvZiB0aGUgZXhpc3RpbmcgdHJhbnNwb3J0IHByb3RvY29scyAoaW4gY29tYmluYXRpb24g
d2l0aCB0aGUgYXBwcm9wcmlhdGU8YnI+DQooRClUTFMpPyBBbmQgdGhlbiBtYWtpbmcgYSBkZWNp
c2lvbiB3aGV0aGVyIGl0IGlzIGFwcHJvcHJpYXRlIHRvPGJyPg0KZXZvbHZlIGV4aXN0aW5nIHBy
b3RvY29scyBpbiBhZGRpdGlvbiB0byBvciBpbnN0ZWFkIG9mIGRldmVsb3BpbmcgYSBuZXcgb25l
Li4uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkJlaW5nIGEgeWVzLWFuZCBraW5k
IG9mIGd1eSwgSSBoYXZlIHRvIHNheSBJIGRvbid0Jm5ic3A7IHNlZSB3aHkgZXZvbHZpbmcgZXhp
c3RpbmcgcHJvdG9jb2xzIGFuZCBkZXZlbG9waW5nIG5ld3Mgc2hvdWxkIGJlIHNlZW4gYXMgaW4g
b3Bwb3NpdGlvbi4mbmJzcDsgVGhlIHR3byBjYW4gcHJvY2VlZCBpbiBwYXJhbGxlbCBhbmQgbGVh
cm4gZnJvbSBlYWNoIG90aGVyIChhcyBRVUlDDQogaGFzIGNlcnRhaW5seSBsZWFybmVkIGEgbG90
IG9uIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgZnJvbnQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij5UbyBwdXQgdGhpcyBhbm90aGVyIHdheSwgSSB0aGluayBpdCBpcyBnb29kIGZvciB0aGUgSW50
ZXJuZXQgaWYgbmV3IHByb3RvY29scyBtYXkgYmUgZGVwbG95ZWQ7IG9zc2lmaWNhdGlvbiBpcyBi
YWQuJm5ic3A7IFdlIGNhbiBsZWFybiBmcm9tIHRoZSBkZXBsb3ltZW50cyBpbiBhIHZhcmlldHkg
b2Ygd2F5cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SnVzdCBteSB0aGlua2luZyw8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tYm90dG9tOjEyLjBwdCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlZCA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_2B9B48179856DC4FA00C93C79EB7E64A60DCC83AESESSMB109erics_--


From nobody Thu May 26 02:23:00 2016
Return-Path: 
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 4183212D5F7 for ; Thu, 26 May 2016 02:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 sxeJVmRlW9KA for ; Thu, 26 May 2016 02:22:56 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D5712B026 for ; Thu, 26 May 2016 02:22:53 -0700 (PDT)
X-AuditID: c1b4fb3a-f79386d00000467b-2b-5746c06a818c
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E6.4F.18043.A60C6475; Thu, 26 May 2016 11:22:51 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.166]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0294.000; Thu, 26 May 2016 11:22:50 +0200
From: Salvatore Loreto 
To: Jana Iyengar , =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= 
Thread-Topic: [QUIC] Scope of multi-path WAS: Re: Draft charter
Thread-Index: AQHRsuqYHHVxqn7B/Ee0fdlRSyTjlJ/CWN+AgASe+ACAAv74MA==
Date: Thu, 26 May 2016 09:22:49 +0000
Message-ID: <2B9B48179856DC4FA00C93C79EB7E64A60DCCD5F@ESESSMB109.ericsson.se>
References:    <59f8ddb3-8cd3-6cbe-19c1-07c88264a8c8@tessares.net>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.146]
Content-Type: multipart/alternative; boundary="_000_2B9B48179856DC4FA00C93C79EB7E64A60DCCD5FESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM2K7vW72AbdwgxmPmC2aPvcxWkw6upDF YnbjcRaLngXcFo1z7RxYPXbOusvusWBTqceSJT+ZPFp3/GX3uNM0nTmANYrLJiU1J7MstUjf LoErY97q9cwF06IqZrzzb2C8Ed7FyMEhIWAiseZVYRcjJ5ApJnHh3nq2LkYuDiGBI4wS3Wen MkI4SxglNuz9xwJSxSZgJvH84RZmkGYRgSyJl5+jQWqYBdYySsxbuAesRljATuLus6tMEDX2 ElNX+YGERQScJP49uc8OYrMIqEpcvXoArJxXwFei43QfM8SuVcwSa9Y/BJvPKRAoseymPkgN I9Bx30+tYQKxmQXEJW49mc8EcbSAxJI955khbFGJl4//sULYShI/NlxigajPl7i69gkTxC5B iZMzn7BMYBSdhWTULCRls5CUzQK6gllAU2L9Ln2IEkWJKd0P2SFsDYnWOXPZkcUXMLKvYhQt Ti0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMz4NbflvtYDz43PEQowAHoxIPb4KCW7gQa2JZcWXu IUYJDmYlEd7De4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4 OKUaGCPnN1Wo2E698+u+R83qfw2P/SUzdv6Yfenby/c7XS8+Ebz6TG/Wpnl2B10fdYm9ibXJ My+cs8NC6fy26XaML8SiFUISo9i3f5Dac/Tdy8Jn+VPm1V1duH0Ls6zuti0XDi7jqpX9cuNE xrQF75rfWjRoCAfsPZzimN6Y9vm71roHP79qcZmLH3FTYinOSDTUYi4qTgQA/THALMsCAAA=
Archived-At: 
Cc: Christian Huitema , Olivier Bonaventure , "quic@ietf.org" , Ted Hardie 
Subject: Re: [QUIC] Scope of multi-path WAS: Re: Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2016 09:22:58 -0000

--_000_2B9B48179856DC4FA00C93C79EB7E64A60DCCD5FESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSmFuYSwNCg0KSSB0aGluayBJIGFncmVlIHdpdGggeW91IG9uIHdoYXQgdGhlIGNoYXJ0ZXIg
c2hvdWxkIHNheSBvbiB0aGlzIHRvcGljLg0KDQpKdXN0IGEgY2xhcmlmaWNhdGlvbiBhYm91dCB3
aHkgeW91IHB1dCBtb2JpbGl0eSBpbiBicmFja2V0cyBpbiB5b3VyIGFuc3dlciBiZWxvdy4NCkRv
IHlvdSBzZWUgcmVsaWFiaWxpdHkgaW4gUXVpYyBhcyBzb21ldGhpbmcgb25seSBmb3IgbW9iaWxp
dHkNCndoaWxlIHRoZSBkZWZhdWx0IHVzYWdlIG9mIG11bHRpcGF0aCB3b3VsZCBiZSBsb2FkIHNo
YXJpbmc/DQoNCkFib3V0IFBhdGggc2VsZWN0aW9uIHdoaWxlIEkgdGVuZCB0byBhZ3JlZSB0aGF0
IG1vc3QgbGlrZWx5IGl0IGlzIGJldHRlciB0byBsZWF2ZSBpdCB0byBpbXBsZW1lbnRhdGlvbiwN
CkkgdGhpbmsgdGhhdCB0aGVyZSBzaG91bGQgYmUgYXQgbGVhc3Qgc29tZSBjb25zaWRlcmF0aW9u
IGFuZCBzdWdnZXN0aW9uIG9uIHBhdGggbWFuYWdlbWVudA0KSGF2aW5nIHNhaWQgdGhhdCBJIGRv
buKAmXQgdGhpbmsgdGhlIENoYXJ0ZXIgc2hvdWxkIGdvIGludG8gdGhlIGRldGFpbCBvZiBQYXRo
IHNlbGVjdGlvbg0KDQovU2FsDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBKYW5hIEl5ZW5nYXINClNlbnQ6IGRlbiAyNCBtYWogMjAxNiAw
MDowOA0KVG86IEfDtnJhbiBFcmlrc3NvbiBBUCA8Z29yYW4uYXAuZXJpa3Nzb25AZXJpY3Nzb24u
Y29tPg0KQ2M6IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQG1pY3Jvc29mdC5jb20+OyBPbGl2
aWVyIEJvbmF2ZW50dXJlIDxvbGl2aWVyLmJvbmF2ZW50dXJlQHRlc3NhcmVzLm5ldD47IHF1aWNA
aWV0Zi5vcmc7IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiBb
UVVJQ10gU2NvcGUgb2YgbXVsdGktcGF0aCBXQVM6IFJlOiBEcmFmdCBjaGFydGVyDQoNCkfDtnJh
biwNCg0KSSBhbSBhZGRpbmcgdGV4dCB0byB0aGUgY2hhcnRlciB0byBzYXkgdGhhdCBib3RoIHJl
bGlhYmlsaXR5IChtb2JpbGl0eSkgYW5kIGxvYWQgc2hhcmluZyB3aWxsIGJlIGluIHNjb3BlIGZv
ciBtdWx0aXBhdGguIFBhdGggc2VsZWN0aW9uIHdpbGwgcHJvYmFibHkgYmUgbGVmdCB0byBpbXBs
ZW1lbnRhdGlvbnMsIGp1c3QgYXMgaXQgaXMgaW4gU0NUUCBhbmQgTVBUQ1AuDQoNCi0gamFuYQ0K
DQpPbiBGcmksIE1heSAyMCwgMjAxNiBhdCA0OjM0IFBNLCBHw7ZyYW4gRXJpa3Nzb24gQVAgPGdv
cmFuLmFwLmVyaWtzc29uQGVyaWNzc29uLmNvbTxtYWlsdG86Z29yYW4uYXAuZXJpa3Nzb25AZXJp
Y3Nzb24uY29tPj4gd3JvdGU6DQoNCg0KPkkgYWdyZWUuIEF0IHRoaXMgcG9pbnQsIGl0J3Mgbm90
IGNsZWFyIHRvIG1lIGhvdyB1c2VmdWwgYSBRVUlDIEFQSSBkb2MNCj53aWxsIGJlLiBXZSBjYW4g
Y2VydGFpbmx5IGNvbnNpZGVyIGl0IGxhdGVyIGFzIG1vcmUgaW1wbGVtZW50YXRpb25zDQo+ZW1l
cmdlLg0KDQorMQ0KDQpCdXQgcGVyaGFwcyB5b3UgY291bGQgZWxhYm9yYXRlIGEgYml0IG9uIHRo
ZSB1c2Ugb2YgTVBRVUlDIGNhc2UvdXNhZ2VzIHlvdQ0KYXJlIGNvbnNpZGVyaW5nPw0KDQpNb2Jp
bGl0eT8gQW5kIGlmIHlvdSBmb3Jlc2VlIGFueSBjYXNlIHdoZXJlIHRoZSBwYXRoIHNlbGVjdGlv
biB3aWxsIGJlDQpkb25lIGJhc2VkIG9uIGh0dHAgbGF5ZXIgaW5wdXQ/DQoNClJlZ2FyZHMNCkfD
tnJhbg0KDQo=

--_000_2B9B48179856DC4FA00C93C79EB7E64A60DCCD5FESESSMB109erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z
by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj
b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y
dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h
cmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgSmFuYSw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+SSB0aGluayBJIGFncmVlIHdpdGggeW91IG9uIHdoYXQgdGhlIGNoYXJ0ZXIgc2hvdWxkIHNh
eSBvbiB0aGlzIHRvcGljLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkp1c3QgYSBjbGFyaWZpY2F0aW9uIGFi
b3V0IHdoeSB5b3UgcHV0IG1vYmlsaXR5IGluIGJyYWNrZXRzIGluIHlvdXIgYW5zd2VyIGJlbG93
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+RG8geW91IHNlZSByZWxpYWJpbGl0eSBpbiBRdWljIGFzIHNvbWV0aGluZyBvbmx5IGZv
ciBtb2JpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+d2hpbGUgdGhlIGRlZmF1bHQgdXNhZ2Ugb2YgbXVsdGlwYXRoIHdvdWxk
IGJlIGxvYWQgc2hhcmluZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QWJvdXQgUGF0aCBzZWxlY3Rpb24gd2hp
bGUgSSB0ZW5kIHRvIGFncmVlIHRoYXQgbW9zdCBsaWtlbHkgaXQgaXMgYmV0dGVyIHRvIGxlYXZl
IGl0IHRvIGltcGxlbWVudGF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGluayB0aGF0IHRoZXJlIHNob3VsZCBiZSBh
dCBsZWFzdCBzb21lIGNvbnNpZGVyYXRpb24gYW5kIHN1Z2dlc3Rpb24gb24gcGF0aCBtYW5hZ2Vt
ZW50DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPkhhdmluZyBzYWlkIHRoYXQgSSBkb27igJl0IHRoaW5rIHRoZSBDaGFydGVyIHNo
b3VsZCBnbyBpbnRvIHRoZSBkZXRhaWwgb2YgUGF0aCBzZWxlY3Rpb248bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
L1NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g
UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+
SmFuYSBJeWVuZ2FyPGJyPg0KPGI+U2VudDo8L2I+IGRlbiAyNCBtYWogMjAxNiAwMDowODxicj4N
CjxiPlRvOjwvYj4gR8O2cmFuIEVyaWtzc29uIEFQICZsdDtnb3Jhbi5hcC5lcmlrc3NvbkBlcmlj
c3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVt
YUBtaWNyb3NvZnQuY29tJmd0OzsgT2xpdmllciBCb25hdmVudHVyZSAmbHQ7b2xpdmllci5ib25h
dmVudHVyZUB0ZXNzYXJlcy5uZXQmZ3Q7OyBxdWljQGlldGYub3JnOyBUZWQgSGFyZGllICZsdDt0
ZWQuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUVVJQ10gU2Nv
cGUgb2YgbXVsdGktcGF0aCBXQVM6IFJlOiBEcmFmdCBjaGFydGVyPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+R8O2cmFuLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBhZGRpbmcgdGV4dCB0byB0aGUgY2hhcnRlciB0byBzYXkg
dGhhdCBib3RoIHJlbGlhYmlsaXR5IChtb2JpbGl0eSkgYW5kIGxvYWQgc2hhcmluZyB3aWxsIGJl
IGluIHNjb3BlIGZvciBtdWx0aXBhdGguIFBhdGggc2VsZWN0aW9uIHdpbGwgcHJvYmFibHkgYmUg
bGVmdCB0byBpbXBsZW1lbnRhdGlvbnMsIGp1c3QgYXMgaXQgaXMgaW4gU0NUUCBhbmQgTVBUQ1Au
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g
amFuYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiBGcmksIE1heSAyMCwgMjAxNiBhdCA0OjM0IFBNLCBHw7ZyYW4gRXJpa3Nzb24gQVAgJmx0
OzxhIGhyZWY9Im1haWx0bzpnb3Jhbi5hcC5lcmlrc3NvbkBlcmljc3Nvbi5jb20iIHRhcmdldD0i
X2JsYW5rIj5nb3Jhbi5hcC5lcmlrc3NvbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6
NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48
YnI+DQo8YnI+DQomZ3Q7SSBhZ3JlZS4gQXQgdGhpcyBwb2ludCwgaXQncyBub3QgY2xlYXIgdG8g
bWUgaG93IHVzZWZ1bCBhIFFVSUMgQVBJIGRvYzxicj4NCiZndDt3aWxsIGJlLiBXZSBjYW4gY2Vy
dGFpbmx5IGNvbnNpZGVyIGl0IGxhdGVyIGFzIG1vcmUgaW1wbGVtZW50YXRpb25zPGJyPg0KJmd0
O2VtZXJnZS48YnI+DQo8YnI+DQomIzQzOzE8YnI+DQo8YnI+DQpCdXQgcGVyaGFwcyB5b3UgY291
bGQgZWxhYm9yYXRlIGEgYml0IG9uIHRoZSB1c2Ugb2YgTVBRVUlDIGNhc2UvdXNhZ2VzIHlvdTxi
cj4NCmFyZSBjb25zaWRlcmluZz88YnI+DQo8YnI+DQpNb2JpbGl0eT8gQW5kIGlmIHlvdSBmb3Jl
c2VlIGFueSBjYXNlIHdoZXJlIHRoZSBwYXRoIHNlbGVjdGlvbiB3aWxsIGJlPGJyPg0KZG9uZSBi
YXNlZCBvbiBodHRwIGxheWVyIGlucHV0Pzxicj4NCjxicj4NClJlZ2FyZHM8YnI+DQo8c3BhbiBj
bGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+R8O2cmFuPC9zcGFuPjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_2B9B48179856DC4FA00C93C79EB7E64A60DCCD5FESESSMB109erics_--


From nobody Fri May 27 18:10:39 2016
Return-Path: 
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 1748612D1DB for ; Fri, 27 May 2016 18:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 dBHcgnZlmAo6 for ; Fri, 27 May 2016 18:10:36 -0700 (PDT)
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 17BB012D108 for ; Fri, 27 May 2016 18:10:36 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id o16so120867322ywd.2 for ; Fri, 27 May 2016 18:10:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wRi1YFG5aCB4V3RYOLPKVOcpYmz1ONFUdiTrz5z09pg=; b=fgvndgLy/GLYuezYwQRUVcnuhrH0oP4NaWzSBdagi9xewBqo5wSsyjGIxO0gAdpeHR Cl5S551f/vduskCxAbId72zeCcV+QHAVQGbg0zv1D1+x0hC3Sim8KTwOsZkDZhRIq3T2 RJmaEEkBUuF1J07k6eh0PXzRZUmm9Roa84eHy96gjhzwYzIL8+iCB/tdx68cc5KM2DId cI5zTkN2v2ITtXomPhGrzwotuRI2MTPcYlCqWENWynyLuRmOPSF/9jl+nlRBWctVB8Nx Rk9pgWo8QxWqzofHqWryK1Uwr+k+DJIVuPkkUPM0DzK7I7xWWQdJpfdP0HHVsuH7Qltb yIYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wRi1YFG5aCB4V3RYOLPKVOcpYmz1ONFUdiTrz5z09pg=; b=V4te3CJGz5M3pA31+Sbdk2dp757XLxw9CebIMz89sCN8/Fz9ctTXG9MWJnGQ/53nYY /F/vywRPDRgRnGi4dNvjKx6mw28pdXQ/emBbpWppuF9eF8tl5vXmH3Ibnd9KwR4D290w kKXNtbpTZdM+b/YoJuQxI3apjNP4SiW5/Jd7ZoBJmKdVgA58ziBd20TgzLzAh68L2LAy ekzRwzgAKxTzIfDaH4d/1oLFFy5K9vP0yd90VKSHZsQbLj6ZxjseTt3IEBMdvDd3jUIY A+Lm9Ktz2VRLhOWIibaHRb7ncR2MmPHMmcdU/Wmb1ZUxdrFFCqTmUYIT6aG725p2lPBi qiQg==
X-Gm-Message-State: ALyK8tIN3q+5kPmQALd7OklxpOJbJyoSrgk0t1TB+5LXuZxhGyyFuKh3R9sK+FOLhtGicMEZbPgBtNWeEYuASqNR
X-Received: by 10.129.165.135 with SMTP id c129mr11178520ywh.67.1464397835208;  Fri, 27 May 2016 18:10:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Fri, 27 May 2016 18:10:33 -0700 (PDT)
In-Reply-To: 
References:    <655C07320163294895BBADA28372AF5D48862030@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9721AD10-0511-4FC4-90F4-7B05E7BA8907@trammell.ch>  <8F7EA7F2-0078-411A-BAB8-445D1594DB41@mnot.net>   <7DB6A895-A302-43A0-AADF-D3A3DAC79CC0@mnot.net>       
From: Jana Iyengar 
Date: Fri, 27 May 2016 18:10:33 -0700
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=94eb2c12a062c776bb0533dcb06e
Archived-At: 
Cc: Olivier Bonaventure , "Scharf, Michael \(Nokia - DE\)" , Kyle Rose , Ryan Hamilton , Christian Huitema , Brian Trammell , "quic@ietf.org" , Martin Thomson 
Subject: Re: [QUIC] QUIC privacy impact
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 May 2016 01:10:38 -0000

--94eb2c12a062c776bb0533dcb06e
Content-Type: text/plain; charset=UTF-8

I agree with Mark's point about the charter being a contract between the WG
and the rest of the community. It's reasonable to say that the current
state of what the IETF has produced so far is the floor from where we start
in this WG.

On Tue, May 24, 2016 at 2:49 PM, Mark Nottingham  wrote:

> The point of including something like this in a charter is to serve as a
> contract between the WG and the rest of the community; it states the
> expectations upon the work, so everyone's on the same page.
>
> It also gives the chair(s) a way to short-circuit unproductive
> discussions, if they stray past the expressed limits. Given the scope of
> this work, I think any and all such advice we can get into the charter will
> be helpful.
>
> That doesn't mean it has to be design-in-charter; it only needs to define
> a floor. I think the text Jana came up with served that purpose well. We
> can always exceed it, based upon justifications other than the charter.
>
> Cheers,
>
>
> > On 25 May 2016, at 7:19 AM, Kyle Rose  wrote:
> >
> >>> I propose: "This work will address security and privacy issues arising
> >>> from the protocol design." and leave it at that.
> >>
> >> I think that it is useful to specify a reasonable expectation that is
> not
> >> unrealistic. Otherwise, we might end up in never ending discussions
> within
> >> the working group.
> >
> > But right now it's ok?
> >
> > Charter formation doesn't seem like the right place to constrain the
> > space of security and privacy properties with references to existing
> > protocols, the relationships to QUIC of which aren't yet fully
> > understood and the precise meanings of which are not clear. (E.g., is
> > "as good as a stack composed of TLS1.3 using TCP" even well defined?)
> >
> > OTOH, I think we can all agree that QUIC needs to "address security
> > and privacy issues", and can pursue clarification of the implications
> > of that statement within the WG via rough consensus.
> >
> > +1 to Martin's proposal to keep the wording in the charter high-level.
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>

--94eb2c12a062c776bb0533dcb06e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I agree with Mark's point about the charter being a co=
ntract between the WG and the rest of the community. It's reasonable to=
 say that the current state of what the IETF has produced so far is the flo=
or from where we start in this WG.

On Tue, May 24, 2016 at 2:49 PM, Mark Not=
tingham <mnot@mnot.net> wrote:
The point of including something like this in a charter is to serve as a c=
ontract between the WG and the rest of the community; it states the expecta=
tions upon the work, so everyone's on the same page.



It also gives the chair(s) a way to short-circuit unproductive discussions,=
 if they stray past the expressed limits. Given the scope of this work, I t=
hink any and all such advice we can get into the charter will be helpful.


That doesn't mean it has to be design-in-charter; it only needs to defi=
ne a floor. I think the text Jana came up with served that purpose well. We=
 can always exceed it, based upon justifications other than the charter.


Cheers,






> On 25 May 2016, at 7:19 AM, Kyle Rose <krose@krose.org> wrote:

>

>>> I propose: "This work will address security and privacy i=
ssues arising

>>> from the protocol design." and leave it at that.

>>

>> I think that it is useful to specify a reasonable expectation that=
 is not

>> unrealistic. Otherwise, we might end up in never ending discussion=
s within

>> the working group.

>

> But right now it's ok?

>

> Charter formation doesn't seem like the right place to constrain t=
he

> space of security and privacy properties with references to existing
> protocols, the relationships to QUIC of which aren't yet fully

> understood and the precise meanings of which are not clear. (E.g., is<=
br>
> "as good as a stack composed of TLS1.3 using TCP" even well =
defined?)

>

> OTOH, I think we can all agree that QUIC needs to "address securi=
ty

> and privacy issues", and can pursue clarification of the implicat=
ions

> of that statement within the WG via rough consensus.

>

> +1 to Martin's proposal to keep the wording in the charter high-le=
vel.




--

Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/













--94eb2c12a062c776bb0533dcb06e--


From nobody Fri May 27 18:26:18 2016
Return-Path: 
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 8C90112D534 for ; Fri, 27 May 2016 18:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 uQZdqVrpw-GO for ; Fri, 27 May 2016 18:26:14 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 A3D7812D139 for ; Fri, 27 May 2016 18:26:14 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id x189so120917102ywe.3 for ; Fri, 27 May 2016 18:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/VzvCzadX9EpVFr0Fbxwb7xVjoBl2HRknEu/1bMRhzc=; b=eVUEKqexZ/L630jInqym6FLmjL9bYbgfkzzT4aCJ6R3b2lJS0/ySz7ZHDxJPEEvJjJ L9EqHGb9jqJp0utBAXPecBLVr7kSAj4EK9nyEDuoQejqp593MoTY5Rgi+wfrnVlK5Jzl VQvO4emmGqvTMBTjam0pNxXxx4Ol+p3+29pigKs0/H/U/ukG9/cA6XRd8qL6JVf6poAc ln5KKqEl9GSZxO+HPSQbY422OSC6Jk2q8dG8ipYINPRN7UaRt7YiPBfpaOrDlRtNZ2jA mI/ATBRN02TU68ZoVz12s7k81p+ToG0N7HEtzdhiXXFVE3iWWhHoO56mM8tQI2bN0ysF WIwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/VzvCzadX9EpVFr0Fbxwb7xVjoBl2HRknEu/1bMRhzc=; b=gkGi4ssRPv2o0TPWPAe2BLCQOmPJzWfgNl3+2XlTQg7QF5GAWVivjY65YMVX7HMeTk ScmKccYwqu21iyjYG2rfqApf7csEaN1FY0pT/HiMjrTwyQx6L5Cvy6Ead/Sv4JdLrPFi 0AiS+t0f9/J2ihb2eyoQDmwZOTigfkjhoNYzmWxtOtIXbzCWIVB7hEjMJi9KFdohpN1J hKG1UKGllakjfyfoQdJkemz7UiUClAh5aYo6ygeHaban2VHAmueuJsyZAXAC1keqI0k4 NKqmbPAYuUpWfa6to1bIg7Lzb9eXBi57fJtiIdsDZn4OI7+ujRxfWPStOWf5acUOKO8f XI0Q==
X-Gm-Message-State: ALyK8tKsdacWn/AxZaqvuu9teQIZXwOlCtf9Va/iXq7AFkIybT9QeCPjNi5QtQKfmZ2wj6NBAatwUulRgObG7bHw
X-Received: by 10.37.82.131 with SMTP id g125mr9840095ybb.104.1464398773784; Fri, 27 May 2016 18:26:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Fri, 27 May 2016 18:26:13 -0700 (PDT)
In-Reply-To: <2B9B48179856DC4FA00C93C79EB7E64A60DCCD5F@ESESSMB109.ericsson.se>
References:    <59f8ddb3-8cd3-6cbe-19c1-07c88264a8c8@tessares.net>    <2B9B48179856DC4FA00C93C79EB7E64A60DCCD5F@ESESSMB109.ericsson.se>
From: Jana Iyengar 
Date: Fri, 27 May 2016 18:26:13 -0700
Message-ID: 
To: Salvatore Loreto 
Content-Type: multipart/alternative; boundary=001a11422de4b914fa0533dce803
Archived-At: 
Cc: Christian Huitema , Olivier Bonaventure , "quic@ietf.org" , Ted Hardie , =?UTF-8?Q?G=C3=B6ran_Eriksson_AP?= 
Subject: Re: [QUIC] Scope of multi-path WAS: Re: Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 May 2016 01:26:16 -0000

--001a11422de4b914fa0533dce803
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks Sal. To clarify, I meant to say use the term reliability to mean
mobility, but it's definitely unnecessarily confusing. I'll use just
"mobility" instead.

- jana

On Thu, May 26, 2016 at 2:22 AM, Salvatore Loreto <
salvatore.loreto@ericsson.com> wrote:

> Hi Jana,
>
>
>
> I think I agree with you on what the charter should say on this topic.
>
>
>
> Just a clarification about why you put mobility in brackets in your answe=
r
> below.
>
> Do you see reliability in Quic as something only for mobility
>
> while the default usage of multipath would be load sharing?
>
>
>
> About Path selection while I tend to agree that most likely it is better
> to leave it to implementation,
>
> I think that there should be at least some consideration and suggestion o=
n
> path management
>
> Having said that I don=E2=80=99t think the Charter should go into the det=
ail of
> Path selection
>
>
>
> /Sal
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar
> *Sent:* den 24 maj 2016 00:08
> *To:* G=C3=B6ran Eriksson AP 
> *Cc:* Christian Huitema ; Olivier Bonaventure <
> olivier.bonaventure@tessares.net>; quic@ietf.org; Ted Hardie <
> ted.ietf@gmail.com>
> *Subject:* Re: [QUIC] Scope of multi-path WAS: Re: Draft charter
>
>
>
> G=C3=B6ran,
>
>
>
> I am adding text to the charter to say that both reliability (mobility)
> and load sharing will be in scope for multipath. Path selection will
> probably be left to implementations, just as it is in SCTP and MPTCP.
>
>
>
> - jana
>
>
>
> On Fri, May 20, 2016 at 4:34 PM, G=C3=B6ran Eriksson AP <
> goran.ap.eriksson@ericsson.com> wrote:
>
>
>
> >I agree. At this point, it's not clear to me how useful a QUIC API doc
> >will be. We can certainly consider it later as more implementations
> >emerge.
>
> +1
>
> But perhaps you could elaborate a bit on the use of MPQUIC case/usages yo=
u
> are considering?
>
> Mobility? And if you foresee any case where the path selection will be
> done based on http layer input?
>
> Regards
> G=C3=B6ran
>
>
>

--001a11422de4b914fa0533dce803
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks Sal. To clarify, I meant to say use the term reliab=
ility to mean mobility, but it's definitely unnecessarily confusing. I&=
#39;ll use just "mobility" instead.
- jana
On Thu, May 26, 2016 at 2:22 AM, Salvatore Lor=
eto <salvatore.loreto@ericsson.com> wrote:











Hi Jana,


=C2=A0


I think I agree with you on what the charter should=
 say on this topic.



=C2=A0


Just a clarification about why you put mobility in =
brackets in your answer below.


Do you see reliability in Quic as something only fo=
r mobility


while the default usage of multipath would be load =
sharing?


=C2=A0


About Path selection while I tend to agree that mos=
t likely it is better to leave it to implementation,

I think that there should be at least some consider=
ation and suggestion on path management



Having said that I don=E2=80=99t think the Charter =
should go into the detail of Path selection


=C2=A0


/Sal


=C2=A0


From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Jana Iyengar

Sent: den 24 maj 2016 00:08

To: G=C3=B6ran Eriksson AP <goran.ap.eriksson@ericsson.com>

Cc: Christian Huitema <huitema@microsoft.com>; Olivier Bonaventure <olivier.=
bonaventure@tessares.net>; quic@ietf.org; Ted Hardie <ted.ietf@gmail.com>

Subject: Re: [QUIC] Scope of multi-path WAS: Re: Draft charter


=C2=A0




G=C3=B6ran,




=C2=A0






I am adding text to the charter to say that both rel=
iability (mobility) and load sharing will be in scope for multipath. Path s=
election will probably be left to implementations, just as it is in SCTP an=
d MPTCP.






=C2=A0






- jana








=C2=A0




On Fri, May 20, 2016 at 4:34 PM, G=C3=B6ran Eriksson=
 AP <goran.ap.eriksson@ericsson.com> wrote:








>I agree. At this point, it's not clear to me how useful a QUIC API =
doc

>will be. We can certainly consider it later as more implementations

>emerge.



+1



But perhaps you could elaborate a bit on the use of MPQUIC case/usages you<=
br>
are considering?



Mobility? And if you foresee any case where the path selection will be

done based on http layer input?



Regards

G=C3=B6ran<=
/p>





=C2=A0












--001a11422de4b914fa0533dce803--


From nobody Fri May 27 19:30:23 2016
Return-Path: 
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 B08B312B04E for ; Fri, 27 May 2016 19:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 G8zHhJDCtuY5 for ; Fri, 27 May 2016 19:30:20 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 0E2D412B038 for ; Fri, 27 May 2016 19:30:19 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id h19so121870286ywc.0 for ; Fri, 27 May 2016 19:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nx2xk2NVvu+N32CKGkJham1C87KsWjboFHDHAErBDGk=; b=LSVa2J/0RIPg93OsOTRjYLvOn6UxjvM1dnKk5uxBMomU6tOIuU4SZfj4jnlzmHi0ds ub6P76Ec45gmVOPXpDfiNzfxxnuO5ljeInWoSlo08JOTehLziK1pESNg0Aoe1DF7dY74 OVP4S3OOzPnS6KT2mZSdYDTLVgp/y0ItdgfgLWV2VnOaaiblPV5L2eqnewlkzl35Jv27 u2u0k75p3+/bZRfaY5/yRr0w2HatbF3cUobmsVoeewXHzQp1RO/RB4tE1PJUUIW7ecdg XDxW9+cIsqmOnZunmqi1++xPNEbjhUsWUYW55qCX/vOdT45WtlRnXDOE41m62tcv1guG bgtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nx2xk2NVvu+N32CKGkJham1C87KsWjboFHDHAErBDGk=; b=j5s/yeU/n9EgBs1C5i+Aj8pLvZ0pbZQO/O/nOD5UUSExr/G2HHnOXxLQMV9d9Jy8sZ UFkQ17cS9iLJ1jhhkoO78RN7x3fEENhiFd91VDawIhrU6+bi984rpHYN4hXsKvc0cr/t +UqbfnT0BAj//4cqxHGhY7CUI/3tgZUp0oIUGEmG6zehjdf7UHQoNPPn3OPl6WOQ7TNS BC2xthUfjyCgJ4sO69rFWZpqmYH94MlO2wJr60M+zB9KQ5vR3ziMxYWajXOgL19DkDk3 K/vSafAdNksh9ZG5YwLyV4JtaAitJKdr/jnPb/A/X6BB7Jc3/AGPYfd1NQbsmLOjC15p 3+wQ==
X-Gm-Message-State: ALyK8tL6mCNDYoxnxMncFi6EyYVB+K7RVb4KAgjAANs7Q5VncoYgvGcT/TnUSnm5yKv8dVqXKIeE4P3gwfTQlF50
X-Received: by 10.129.121.81 with SMTP id u78mr10218305ywc.239.1464402619099;  Fri, 27 May 2016 19:30:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Fri, 27 May 2016 19:30:18 -0700 (PDT)
In-Reply-To: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>
From: Jana Iyengar 
Date: Fri, 27 May 2016 19:30:18 -0700
Message-ID: 
To: Michael Tuexen 
Content-Type: multipart/alternative; boundary=94eb2c0a7b68ec073b0533ddcdbd
Archived-At: 
Cc: quic@ietf.org
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 May 2016 02:30:22 -0000

--94eb2c0a7b68ec073b0533ddcdbd
Content-Type: text/plain; charset=UTF-8

Hi Michael,

Are there any plans to analyse the requirements in a protocol independent
> way and try to figure out if these requirements can also be met by evolving
> one or more of the existing transport protocols (in combination with the
> appropriate
> (D)TLS)? And then making a decision whether it is appropriate to
> evolve existing protocols in addition to or instead of developing a new
> one...


I agree with you that the requirements of QUIC should be requirements for
new protocols and for evolution of existing ones. The lessons of QUIC are
expected to inform other transport work -- QUIC has provided inputs to TCP
and TLS about the importance of avoiding handshake RTTs, and more recently,
RACK (draft-cheng-tcpm-rack-00) is similar in spirit to QUIC's loss
recovery.

Subsequent protocol work must learn QUIC's lessons, just as QUIC learned
from its predecessors. While there's inevitably functional overlap between
QUIC and any of {TCP, SCTP, MPTCP} (which have overlaps of their own), much
of the work of QUIC has been in refining and tightly integrating mechanisms
that we have learned from previous transports into a modern transport --
protection of data and headers, low latency-overhead, congestion-control
agility, and strong loss-recovery, to name a few.

So, I agree with Ted and Sal's sentiments. Fixing up our existing designs
for existing deployments is definitely very valuable and hopefully
inevitable, but it does not take away from the fact that QUIC is a clean
protocol design that incorporates, as first principles, lessons learned
from our collective past. Going forward, I expect there to be debates about
which protocol is the best fit for an application, and I encourage that --
having real choice in transport protocols at design time and at run time is
a wonderful thing, and it's long overdue.

- jana

--94eb2c0a7b68ec073b0533ddcdbd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Michael,=C2=A0


Are there any plans to analyse the requirements in a protocol independent
way and try to figure out if these requirements can also be met by evolving=


one or more of the existing transport protocols (in combination with the ap=
propriate

(D)TLS)? And then making a decision whether it is appropriate to

evolve existing protocols in addition to or instead of developing a new one=
...

I agree with you that the requirements =
of QUIC should be requirements for new protocols and for evolution of exist=
ing ones.=C2=A0The lessons of QUIC are expected to inform other transport w=
ork -- QUIC has provided inputs to TCP and TLS about the importance of avoi=
ding handshake RTTs, and more recently, RACK (draft-cheng-tcpm-rack-00)=C2=
=A0is similar in spirit to QUIC's loss recovery.=C2=A0

Subsequent protocol work must learn QUIC's lessons, just as=C2=
=A0QUIC learned from its predecessors. While there's inevitably functio=
nal overlap between QUIC and any of {TCP, SCTP, MPTCP} (which have overlaps=
 of their own), much of the work of QUIC has been in refining and tightly i=
ntegrating mechanisms that we have learned from previous transports into a =
modern transport -- protection of data and headers, low latency-overhead, c=
ongestion-control agility, and strong loss-recovery, to name a few.=C2=A0

So, I agree with Ted and Sal's sentiments. Fixi=
ng up our existing designs for existing deployments is definitely very valu=
able and hopefully inevitable, but it does not take away from the fact that=
 QUIC is a clean protocol design that incorporates, as first principles, le=
ssons learned from our collective past. Going forward, I expect there to be=
 debates about which protocol is the best fit for an application, and I enc=
ourage that -- having real choice in transport protocols at design time and=
 at run time is a wonderful thing, and it's long overdue.

- jana


--94eb2c0a7b68ec073b0533ddcdbd--


From nobody Sat May 28 01:17:37 2016
Return-Path: 
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 C564B12D5D2 for ; Sat, 28 May 2016 01:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.027
X-Spam-Level: 
X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 Z5KF-Hs23xsI for ; Sat, 28 May 2016 01:17:33 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC7412D5D0 for ; Sat, 28 May 2016 01:17:33 -0700 (PDT)
Received: from [192.168.1.100] (p508F09C1.dip0.t-ipconnect.de [80.143.9.193]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 90F39721E280C; Sat, 28 May 2016 10:17:29 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Tuexen 
In-Reply-To: 
Date: Sat, 28 May 2016 10:17:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de>
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de> 
To: Jana Iyengar 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: quic@ietf.org
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 May 2016 08:17:36 -0000

> On 28 May 2016, at 04:30, Jana Iyengar  wrote:
>=20
> Hi Michael,=20
>=20
> Are there any plans to analyse the requirements in a protocol =
independent
> way and try to figure out if these requirements can also be met by =
evolving
> one or more of the existing transport protocols (in combination with =
the appropriate
> (D)TLS)? And then making a decision whether it is appropriate to
> evolve existing protocols in addition to or instead of developing a =
new one...
>=20
> I agree with you that the requirements of QUIC should be requirements =
for new protocols and for evolution of existing ones. The lessons of =
QUIC are expected to inform other transport work -- QUIC has provided =
inputs to TCP and TLS about the importance of avoiding handshake RTTs, =
and more recently, RACK (draft-cheng-tcpm-rack-00) is similar in spirit =
to QUIC's loss recovery.=20
>=20
> Subsequent protocol work must learn QUIC's lessons, just as QUIC =
learned from its predecessors. While there's inevitably functional =
overlap between QUIC and any of {TCP, SCTP, MPTCP} (which have overlaps =
of their own), much of the work of QUIC has been in refining and tightly =
integrating mechanisms that we have learned from previous transports =
into a modern transport -- protection of data and headers, low =
latency-overhead, congestion-control agility, and strong loss-recovery, =
to name a few.=20
Hi Jana,

so these are some of the requirements, right? I'm wondering if it makes =
sense to provide such a list
of findings in a protocol independent way. What is important and what is =
not needs knowledge of the
results of the experiments Google where running.
Without such a description, it is hard for other groups to figure out if =
it is important to consider
integrating a specific feature of QUIC.

Best regards
Michael
>=20
> So, I agree with Ted and Sal's sentiments. Fixing up our existing =
designs for existing deployments is definitely very valuable and =
hopefully inevitable, but it does not take away from the fact that QUIC =
is a clean protocol design that incorporates, as first principles, =
lessons learned from our collective past. Going forward, I expect there =
to be debates about which protocol is the best fit for an application, =
and I encourage that -- having real choice in transport protocols at =
design time and at run time is a wonderful thing, and it's long overdue.
>=20
> - jana


From nobody Sat May 28 09:15:43 2016
Return-Path: 
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 6982A12B011 for ; Sat, 28 May 2016 09:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 5W7jTUV-NdRG for ; Sat, 28 May 2016 09:15:39 -0700 (PDT)
Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (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 D279412B048 for ; Sat, 28 May 2016 09:15:38 -0700 (PDT)
Received: by mail-qg0-x22b.google.com with SMTP id 90so62891790qgz.1 for ; Sat, 28 May 2016 09:15:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=qVOXSVc5+txNwheKP54ytO+AMUwWCBaTf2ZVMPT5ytA=; b=YYN5TpQOjn1RaS9cfxDxa0swSQaKEuCtmiIVD41mIrH09oj/MVW8r+ysuMnLpFfq1n Ys4BmByuyM3RVpRKJfYBHKUy1G2KZ8m4xBu7PsgNsD7u9++QA9lYhjhA1ZEKZXGfCBVJ 8bIuP20V22yqmzrgvwqPJpsQNGoB9Lmk8j00/Dqh9YOGUM3fsugipRbHraHJBpFFVZz8 SBwXo9DUcPhvadWI/cv+Mt0zrmK8aASC3nbzs3vhkD4jN0cs3OYwg4FKtvMeevSmw6Ui fZdA0KH5sA6XlOXcr2qX4pQU378a9tmMZZ+aQZzMyrepKrj5n++yyGJN6Dqo9J/deSPD n2Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=qVOXSVc5+txNwheKP54ytO+AMUwWCBaTf2ZVMPT5ytA=; b=FzKAAlcKN0EUfsngNJ3v+VYLTngrrSy9Wpzp8SIb1i+U2WUkI9FjNt6m6PUolMg0ZO V7xe41BUycjQ2hM6/jjs52lj23xAapcd7Im1o2XWzXCxYpT8jaBQEwCal/So+gmOup67 ciPmRN7tNdQwAvjMA+2PAN1/mWurE+Qch6U5olMIi5DxMs86L611X0PNk5qRsPrgOc0S D7VbZBEeKA6PpvwX+CqyM3ZktVk3Jdwvn6ltGEak93zXWiC8ySwFT9rQilOgl1kkdJQG oFisdZ813T/V8RyPK5Nq3Pkyqpz0pQyaQm+34qWLAP9VwfOBJJMfDjDA2uwIEEyvgNW4 QXrw==
X-Gm-Message-State: ALyK8tJQ2hMQGIbGDLOIqNwR/R0q8Y9rbhGgZVdH6tp97F01IfyTk3qYMqgh2vCJ5YRwSPk6RNvtHkBT71MclA==
MIME-Version: 1.0
X-Received: by 10.140.42.65 with SMTP id b59mr15587872qga.48.1464452137776; Sat, 28 May 2016 09:15:37 -0700 (PDT)
Sender: jim.roskind@gmail.com
Received: by 10.237.33.186 with HTTP; Sat, 28 May 2016 09:15:37 -0700 (PDT)
In-Reply-To: <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de>
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>  <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de>
Date: Sat, 28 May 2016 09:15:37 -0700
X-Google-Sender-Auth: DuEoQsw5ujuj5uYMI5Q_pWMHTHA
Message-ID: 
From: Jim Roskind 
To: Michael Tuexen 
Content-Type: multipart/alternative; boundary=001a11c12644767aa70533e955de
Archived-At: 
Cc: quic@ietf.org
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 May 2016 16:15:41 -0000

--001a11c12644767aa70533e955de
Content-Type: text/plain; charset=UTF-8

re: "...results of experiments [done by] Google."

Publication of experiments done in/around QUIC should be a treasure trove
for both QUIC and numerous other protocols.

Although not all-encompasing, I presented several of Google's experimental
results to IETF-88 back in 2013.  Be sure to take a look at:

https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf

Included in that IETF presentation (which I think was video recorded) were
slides showing:

a) NAT Eviction probabilities vs time, for UDP bindings (slide 10)
b) Round-trip packet-loss probability for trains of paced vs unpaced
packets of various sizes (slides 22 and 23)
c) Generic 0 vs 1 vs 2 FEC utility for paced and unpaced trains (slide 24)

All such experiments (and many more) need to be repeated and published over
time, as the deployment of middle boxes, links (mobile variants vs
non-mobile), routers, contemporaneous traffic patterns, etc. continue to
evolve.

Item (a) showed the viability of a UDP based multi-packet protocol, with
(then current) caveats that pauses in the stream beyond 30 seconds increase
eviction rates. This drove QUIC to support handling of that progressive
increase in eviction. There is some hope that upcoming IETF standardization
in this area will further improve the NAT-eviction landscape, but that will
certainly depend on vendors and deployment (market penetration) rates.

Item (b) showed the tremendous impact (value) of pacing, and also showed
the remarkable vulnerability (i.e., increased loss probability) of the 2nd
packet in a cold-connection. That surprising (previously unpublished?)
2nd-packet loss statistic was recently observed and verified to me verbally
by a second vendor for a related UDP protocol just a month ago (May 2016)
at a public presentation I gave.

Item (c) better showed the nature of the packet loss correlation (and
showed that loss should *not* be modeled by an independent identically
distributed process.). It clearly showed the lack of marginal value of
multiple-packet error recovery (i.e., 2-packet-loss FEC) for trains as long
as 21 packets (which is a plausible congestion window for a lossy
connection). The data also justified the significant utility of
1-packet-loss FEC for such short windows (i.e., congestion window under 21)
with very latency sensitive transmissions (such as stream creation for
small latency sensitive requests, including perchance advertisements).

We deduced in 2011 that about 5-7% of all chrome clients had UDP blocked
(from reaching Google) for even small packets, which is what drove the
decision to have a TCP fallback plan in QUIC.  I believe that experimental
deployment results for QUIC continued to support that 5-7% statistic,
though I'm very hopeful that system administrators will change this
blocking over time (for the better!).  I also look forward to ongoing
publication of this statistic by Google.

Another Google published result is the fact that UDP payload sizes over
1350 bytes tend to be blocked more often, which was indeed the driving
factor behind QUIC (initially) adopting a static payload size of 1350
bytes.

I expect that experiments done by multiple vendors will be published.  I
know that Firefox adopted Chrome's metrics gathering approach, and
hopefully if/when an experimental QUIC implementation appears there, then
additional results will continue to be published.




On Sat, May 28, 2016 at 1:17 AM, Michael Tuexen <
Michael.Tuexen@lurchi.franken.de> wrote:

> > On 28 May 2016, at 04:30, Jana Iyengar  wrote:
> >
> > Hi Michael,
> >
> > Are there any plans to analyse the requirements in a protocol independent
> > way and try to figure out if these requirements can also be met by
> evolving
> > one or more of the existing transport protocols (in combination with the
> appropriate
> > (D)TLS)? And then making a decision whether it is appropriate to
> > evolve existing protocols in addition to or instead of developing a new
> one...
> >
> > I agree with you that the requirements of QUIC should be requirements
> for new protocols and for evolution of existing ones. The lessons of QUIC
> are expected to inform other transport work -- QUIC has provided inputs to
> TCP and TLS about the importance of avoiding handshake RTTs, and more
> recently, RACK (draft-cheng-tcpm-rack-00) is similar in spirit to QUIC's
> loss recovery.
> >
> > Subsequent protocol work must learn QUIC's lessons, just as QUIC learned
> from its predecessors. While there's inevitably functional overlap between
> QUIC and any of {TCP, SCTP, MPTCP} (which have overlaps of their own), much
> of the work of QUIC has been in refining and tightly integrating mechanisms
> that we have learned from previous transports into a modern transport --
> protection of data and headers, low latency-overhead, congestion-control
> agility, and strong loss-recovery, to name a few.
> Hi Jana,
>
> so these are some of the requirements, right? I'm wondering if it makes
> sense to provide such a list
> of findings in a protocol independent way. What is important and what is
> not needs knowledge of the
> results of the experiments Google where running.
> Without such a description, it is hard for other groups to figure out if
> it is important to consider
> integrating a specific feature of QUIC.
>
> Best regards
> Michael
> >
> > So, I agree with Ted and Sal's sentiments. Fixing up our existing
> designs for existing deployments is definitely very valuable and hopefully
> inevitable, but it does not take away from the fact that QUIC is a clean
> protocol design that incorporates, as first principles, lessons learned
> from our collective past. Going forward, I expect there to be debates about
> which protocol is the best fit for an application, and I encourage that --
> having real choice in transport protocols at design time and at run time is
> a wonderful thing, and it's long overdue.
> >
> > - jana
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>

--001a11c12644767aa70533e955de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


re: "...results of experiments [done by] Google."=
;

Publication of experiments done in/around QUIC should =
be a treasure trove for both QUIC and numerous other protocols.
<=
br>
Although not all-encompasing, I presented several of Google&#=
39;s experimental results to IETF-88 back in 2013.=C2=A0 Be sure to take a =
look at:


Included i=
n that IETF presentation (which I think was video recorded) were slides sho=
wing:

a) NAT Eviction probabilities vs time, for U=
DP bindings (slide 10)
b) Round-trip packet-loss probability for =
trains of paced vs unpaced packets of various sizes (slides 22 and 23)
c) Generic 0 vs 1 vs 2 FEC utility for paced and unpaced trains (slid=
e 24)

All such experiments (and many more) need to=
 be repeated and published over time, as the deployment of middle boxes, li=
nks (mobile variants vs non-mobile), routers, contemporaneous traffic patte=
rns, etc. continue to evolve.

Item (a) showed the =
viability of a UDP based multi-packet protocol, with (then current) caveats=
 that pauses in the stream beyond 30 seconds increase eviction rates. This =
drove QUIC to support handling of that progressive increase in eviction. Th=
ere is some hope that upcoming IETF standardization in this area will furth=
er improve the NAT-eviction landscape, but that will certainly depend on ve=
ndors and deployment (market penetration) rates.

I=
tem (b) showed the tremendous impact (value) of pacing, and also showed the=
 remarkable vulnerability (i.e., increased loss probability) of the 2nd pac=
ket in a cold-connection. That surprising (previously unpublished?) 2nd-pac=
ket loss statistic was recently observed and verified to me verbally by a s=
econd vendor for a related UDP protocol just a month ago (May 2016) at a pu=
blic presentation I gave.=C2=A0

Item (c) better sh=
owed the nature of the packet loss correlation (and showed that loss should=
 *not* be modeled by an independent identically distributed process.). It c=
learly showed the lack of marginal value of multiple-packet error recovery =
(i.e., 2-packet-loss FEC) for trains as long as 21 packets (which is a plau=
sible congestion window for a lossy connection). The data also justified th=
e significant utility of 1-packet-loss FEC for such short windows (i.e., co=
ngestion window under 21) with very latency sensitive transmissions (such a=
s stream creation for small latency sensitive requests, including perchance=
 advertisements).=C2=A0

We deduced in 2011 that ab=
out 5-7% of all chrome clients had UDP blocked (from reaching Google) for e=
ven small packets, which is what drove the decision to have a TCP fallback =
plan in QUIC.=C2=A0 I believe that experimental deployment results for QUIC=
 continued to support that 5-7% statistic, though I'm very hopeful that=
 system administrators will change this blocking over time (for the better!=
).=C2=A0 I also look forward to ongoing publication of this statistic by Go=
ogle.

Another Google published result is =
the fact that UDP payload sizes over 1350 bytes tend to be blocked more oft=
en, which was indeed the driving factor behind QUIC (initially) adopting a =
static payload size of 1350 bytes.=C2=A0

I e=
xpect that experiments done by multiple vendors will be published.=C2=A0 I =
know that Firefox adopted Chrome's metrics gathering approach, and hope=
fully if/when an experimental QUIC implementation appears there, then addit=
ional results will continue to be published.


<=
/div>


On Sat, May 28, 2016 at 1:17 AM, Michael Tuexen =
<M=
ichael.Tuexen@lurchi.franken.de> wrote:
> On 28 May 2016, at 04:30, Jana Iyengar =
<jri@google.com> wrote:

>

> Hi Michael,

>

> Are there any plans to analyse the requirements in a protocol independ=
ent

> way and try to figure out if these requirements can also be met by evo=
lving

> one or more of the existing transport protocols (in combination with t=
he appropriate

> (D)TLS)? And then making a decision whether it is appropriate to

> evolve existing protocols in addition to or instead of developing a ne=
w one...

>

> I agree with you that the requirements of QUIC should be requirements =
for new protocols and for evolution of existing ones. The lessons of QUIC a=
re expected to inform other transport work -- QUIC has provided inputs to T=
CP and TLS about the importance of avoiding handshake RTTs, and more recent=
ly, RACK (draft-cheng-tcpm-rack-00) is similar in spirit to QUIC's loss=
 recovery.

>

> Subsequent protocol work must learn QUIC's lessons, just as QUIC l=
earned from its predecessors. While there's inevitably functional overl=
ap between QUIC and any of {TCP, SCTP, MPTCP} (which have overlaps of their=
 own), much of the work of QUIC has been in refining and tightly integratin=
g mechanisms that we have learned from previous transports into a modern tr=
ansport -- protection of data and headers, low latency-overhead, congestion=
-control agility, and strong loss-recovery, to name a few.

Hi Jana,



so these are some of the requirements, right? I'm wondering if it makes=
 sense to provide such a list

of findings in a protocol independent way. What is important and what is no=
t needs knowledge of the

results of the experiments Google where running.

Without such a description, it is hard for other groups to figure out if it=
 is important to consider

integrating a specific feature of QUIC.



Best regards

Michael

>

> So, I agree with Ted and Sal's sentiments. Fixing up our existing =
designs for existing deployments is definitely very valuable and hopefully =
inevitable, but it does not take away from the fact that QUIC is a clean pr=
otocol design that incorporates, as first principles, lessons learned from =
our collective past. Going forward, I expect there to be debates about whic=
h protocol is the best fit for an application, and I encourage that -- havi=
ng real choice in transport protocols at design time and at run time is a w=
onderful thing, and it's long overdue.

>

> - jana




____________________________=
___________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--001a11c12644767aa70533e955de--


From nobody Sat May 28 10:49:12 2016
Return-Path: 
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 1321312D114 for ; Sat, 28 May 2016 10:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 yR9HQWST4RoM for ; Sat, 28 May 2016 10:49:08 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 64BF212D0E8 for ; Sat, 28 May 2016 10:49:08 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id h185so63726526qke.2 for ; Sat, 28 May 2016 10:49:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=MEdrLCzdrx3imFe67cK7MgVWtaINDcvEbHKt8ra4ws4=; b=glZJUCJNNQGGzzIVADFZUdiMQYNcO8/mPx/DC1WWvK9nvNdN5ZAzIm7H46bAwd6lYL TQq3d0nnliNX9IKdPgR3LYmhBGufCWniIBL7ZrGWJEJyWp0aNml88kagihFS8any47fQ MIW53dt7UaR1QLHIhtUnOmf/ljVrajS8ZeIR7Ctu3GjBQdYmumQxe5FPNiCoyRtR7s5n hWKweRys94Lu2Bfcw2MdYClRyySqbBvC5bRlqPXcd4AF1SuNZk1ptQhx5GHa9dvtfv+n rLb/04LRVPola7Si1OMFgdxLk/elU/OrjCX07OcTBEsv1M8EZd766dJxRlbhkUNFmiOs qH3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=MEdrLCzdrx3imFe67cK7MgVWtaINDcvEbHKt8ra4ws4=; b=baXhXP801Pb9u3H0rUO7b42cNf9TYf3HgqPfVW28U/DZVvDzr+47zgRSycPp/7v7bI N/XdS1hNzT7dBdgWpjiVzOl+1SsFD2eIc/cB1212dcHU9S1fOSuaRaQvB4bzPRdgvsQR xd70ISHBNN+XfOAF7NnduQk1qV44+zqvAq/Hwi9kAMJbTfiP5hW2eoWRh/O+s+dKlPiE VylhfSD5mCEDZg0uq5KILK3sIjGvAt40bgKWGZwe2ENZ43/npsEY1ti0tR0AviETvfgI nj2yEvoWXuGwlDwmjSFkVa+RGxrFp8BphXihkoU9H90RVa9tr+hfsEJZCKFOwqjl0bUo Seyw==
X-Gm-Message-State: ALyK8tINFNbSuHFkwmuFi+WWpR5eCUSOovVCZmrPNgVarINYWZPkOMj7kBkG3+V5RaUEB3LTaTwZuQskBKrcIQ==
MIME-Version: 1.0
X-Received: by 10.55.170.200 with SMTP id t191mr19916114qke.100.1464457747397;  Sat, 28 May 2016 10:49:07 -0700 (PDT)
Sender: jim.roskind@gmail.com
Received: by 10.237.33.186 with HTTP; Sat, 28 May 2016 10:49:07 -0700 (PDT)
In-Reply-To: 
References: 
Date: Sat, 28 May 2016 10:49:07 -0700
X-Google-Sender-Auth: t01P9MKrb9ZQHqGof19pzrm1oVQ
Message-ID: 
From: Jim Roskind 
To: quic@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c06fc00d282d40533eaa37c
Archived-At: 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 May 2016 17:49:11 -0000

--94eb2c06fc00d282d40533eaa37c
Content-Type: text/plain; charset=UTF-8

I've tried to read the whole thread... but I don't think I saw items that
would address following concerns about the charter.

My general perspective is that QUIC was designed to exploit the tight
integration of numerous protocol elements that were traditionally separated
into layers.  Traditional layering included TCP handling
congestion/reliability, independent of TLS handling privacy and
authentication, independent of HTTP handling of request/response pairs
(multiplexed in HTTP/2). QUIC deviates from that pattern at the highest
level, when stream data is (usually) placed into separate UDP packets
(despite multiplexing), with independent decryption (usually) for each
stream fragment. Even QUIC's basic connection establishment tightly binds
awareness of all 3 traditional layers.

Other tight integration points in QUIC include the way the packet sequence
number is used as a basis for the crypto IV for packet decryption, while
also being used for N/ACK reliability (congestion(?) detection?)
notification. Those sequence numbers were also integrated into the
definition of the initial FEC strategy. Further, the rebundling of data
(rather than retransmission of packets with old sequence numbers) to
establish reliable transmission, then simplified the crypto use of the
sequence number as an IV (only a small fixed window could ever be
outstanding, and highly delayed packets could be safely/naturally discarded
by a decryption authentication failure).

Contrary to that tight-integration perspective that I've held for QUIC,
some of the charter suggests that numerous elements can be teased apart or
addressed separately.

a) Congestion control: I would expect that additional data (optionally)
transmitted as part of the core protocol would be critical to evolution of
congestion control.  Examples would include (optionally) better time
stamping; better understanding of received vs lost vs reconstructed (via
FEC) packets. Even the decision to send ACK data in standard packets in the
company of stream data represents a (optional??) point of integration.  The
charter appears to leave congestion control to documents external to the
wire spec, which surprises me.

b) FEC: The quote "specific FEC scheme definitions are out of scope"
concerned me.  Although I would not like new/novel FEC inventions to be
studied by the WG, I would absolutely expect that very specific FEC
definitions, which made the protocol workable at a wire spec level (i.e.,
what do you do with FEC related information to recover a packet or
information?? What extra data fields in the packets would be needed to
relate packets to FEC groups(?)?).

Although I spent years of my life designing, justifying, and working to
deploy QUIC, I'm new to the IETF, so I'd like to better understand the
planned (apparent) separation shown above... or understand why it doesn't
run contrary to the above perspective.

Thanks,

Jim

On Fri, May 13, 2016 at 4:26 PM, Ted Hardie  wrote:

> Howdy,
>
> As part of the BoF preparation, we put together a stab at a draft
> charter.  It's available as html and markdown on github at:
>
> https://github.com/IETF-QUIC/Charter
>
> I've attached the HTML version as well.
>
> It would be great to have some of the discussion on the list before the
> BoF.  Comments to the list or issues/pull requests at the github repo are
> welcome.  We will periodically reflect any issues or suggestion from the
> Repo back to the list, but this will be manual, so expect some lag.
>
> regards,
>
> Ted
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>

--94eb2c06fc00d282d40533eaa37c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I've tried to read the whole thread... but I don't=
 think I saw items that would address following concerns about the charter.=


My general perspective is that QUIC was designed to exp=
loit the tight integration of numerous protocol elements that were traditio=
nally separated into layers.=C2=A0 Traditional layering included TCP handli=
ng congestion/reliability, independent of TLS handling privacy and authenti=
cation, independent of HTTP handling of request/response pairs (multiplexed=
 in HTTP/2). QUIC deviates from that pattern at the highest level, when str=
eam data is (usually) placed into separate UDP packets (despite multiplexin=
g), with independent decryption (usually) for each stream fragment. Even QU=
IC's basic connection establishment tightly binds awareness of all 3 tr=
aditional layers.

Other tight integration points i=
n QUIC include the way the packet sequence number is used as a basis for th=
e crypto IV for packet decryption, while also being used for N/ACK reliabil=
ity (congestion(?) detection?) notification. Those sequence numbers were al=
so integrated into the definition of the initial FEC strategy. Further, the=
 rebundling of data (rather than retransmission of packets with old sequenc=
e numbers) to establish reliable transmission, then simplified the crypto u=
se of the sequence number as an IV (only a small fixed window could ever be=
 outstanding, and highly delayed packets could be safely/naturally discarde=
d by a decryption authentication failure).=C2=A0

C=
ontrary to that tight-integration perspective that I've held for QUIC, =
some of the charter suggests that numerous elements can be teased apart or =
addressed separately.

a) Congestion control: I would exp=
ect that additional data (optionally) transmitted as part of the core proto=
col would be critical to evolution of congestion control.=C2=A0 Examples wo=
uld include (optionally) better time stamping; better understanding of rece=
ived vs lost vs reconstructed (via FEC) packets. Even the decision to send =
ACK data in standard packets in the company of stream data represents a (op=
tional??) point of integration.=C2=A0 The charter appears to leave congesti=
on control to documents external to the wire spec, which surprises me.

b) FEC: The quote "specific FEC scheme defi=
nitions are out of scope" concerned me.=C2=A0 Although I would not lik=
e new/novel FEC inventions to be studied by the WG, I would absolutely expe=
ct that very specific FEC definitions, which made the protocol workable at =
a wire spec level (i.e., what do you do with FEC related information to rec=
over a packet or information?? What extra data fields in the packets would =
be needed to relate packets to FEC groups(?)?).

Al=
though I spent years of my life designing, justifying, and working to deplo=
y QUIC, I'm new to the IETF, so I'd like to better understand the p=
lanned (apparent) separation shown above... or understand why it doesn'=
t run contrary to the above perspective.

Thanks,

Jim

On Fri, May 13, 2016 at 4:26 PM, Ted Hardie <ted.ie=
tf@gmail.com> wrote:
Howdy,

As part of the BoF prepa=
ration, we put together a stab at a draft charter.=C2=A0 It's available=
 as html and markdown on github at:

https://github.com/IETF-QUIC/Charter=


I've attached the HTML version as well.=C2=A0 

It would be great to have some of the discussion on the list before=
 the BoF.=C2=A0 Comments to the list or issues/pull requests at the github =
repo are=20
welcome.=C2=A0 We will periodically reflect any issues or suggestion from t=
he
 Repo back to the list, but this will be manual, so expect some lag.
<=
div>
regards,

Ted


_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--94eb2c06fc00d282d40533eaa37c--


From nobody Sat May 28 20:05:40 2016
Return-Path: 
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 3AE8812D192 for ; Sat, 28 May 2016 20:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 m86qgBV9m83N for ; Sat, 28 May 2016 20:05:37 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 B28C812D190 for ; Sat, 28 May 2016 20:05:35 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id x189so137891742ywe.3 for ; Sat, 28 May 2016 20:05:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hHWVvw7G4vGZuFPe0elT/QnQOa8IP5ycYSdQK/oM+rA=; b=EcogDtJ6oMJwQoGOti4+7ebRDn6TolGp0jIlaFHCXfLfPB458kUqno4g3FbuY/+wMV h/MjCc28mnJqcurI9j1elCth+S4xoMYh4ks+suUuCFX6M8u8M0x4nhj8fzQ346CQLtQS sKC34hM3AhprbVYtzP7P1qsA355PiAw+EfSteRLE+nlSEkZRYCO1ZxgCttSBudJEdVTh X+raebqbVO35AIx2dFXbXDNv2nLyCOmp2RIIDHJS/xqsANpL8UybOig1ZDmWbkVa9+Ly mNYdwNbGK7h/3yXiH63NvMaES/I+d4QvuzfzCssxIU7lLAw1dzHB8RQ5/vhj8shGdD7u X/AA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hHWVvw7G4vGZuFPe0elT/QnQOa8IP5ycYSdQK/oM+rA=; b=kk0J1YdmZsaLHqRtl30VlAOmNVuLV6P3Oxc5SXLW8xDJCMbqCrZ7lYoRwQKRBM83+u 0vk+vYRMyHVsytEc4BUMz4yJQJuTkhQ851s9ZKjdjPCbBJ/vxzP1+PIv9BtSNbBzL+gY I/TxRpv7H1ZUy7vFizNiTOtGbYjUZrhwIied4uAECgCl+Nqj+6ZtH7Rg9VSC3wkSDxkT zqtfVK+ncK9DBygSJYU5R8tGgHI70otE0OViuCnMR3q7lySuKDGA+XNjmJcQKw95ywAP 92H18lmZGiZC118HauFoANq0zh/DjeqP+LcNcWj0CYEoASwujnnk2m0GKKJ7HV65HRSp UKag==
X-Gm-Message-State: ALyK8tJ6lISWtkoG8hd78I5pFFFAjbFOCH3mrtLzZ2tNfVLb6W4iblV9lFOo6ofYaxxnCCmox1ddZ3KswJEkPXCp
X-Received: by 10.129.165.135 with SMTP id c129mr14100861ywh.67.1464491134891;  Sat, 28 May 2016 20:05:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Sat, 28 May 2016 20:05:34 -0700 (PDT)
In-Reply-To: <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de>
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>  <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de>
From: Jana Iyengar 
Date: Sat, 28 May 2016 20:05:34 -0700
Message-ID: 
To: Michael Tuexen 
Content-Type: multipart/alternative; boundary=94eb2c12a062df74420533f26983
Archived-At: 
Cc: quic@ietf.org
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 May 2016 03:05:39 -0000

--94eb2c12a062df74420533f26983
Content-Type: text/plain; charset=UTF-8

Hi Michael,


> so these are some of the requirements, right? I'm wondering if it makes
> sense to provide such a list
> of findings in a protocol independent way. What is important and what is
> not needs knowledge of the
> results of the experiments Google where running.
> Without such a description, it is hard for other groups to figure out if
> it is important to consider
> integrating a specific feature of QUIC.
>

I don't think of them as necessarily requirements, but more as lessons
learned. For instance, monotonically-increasing sequence numbers make loss
detection and recovery much more efficient, but that's a fundamental design
decision that can't be retrofitted easily. Of course, there are others,
such as the elimination of handshake latency, but that's not a new lesson
for the transport community -- TCP Fast Open was underway in 2009.

That said, point taken. Though I'm not sure exactly what form or shape such
a "lessons" document would take, besides continuing presenting data in
TSVAREA and/or MAPRG. I'm happy to continue chatting about such a doc, but
this forum may not be the right place for it... especially since I don't
think that these lessons are only being learned in/from QUIC deployment.

- jana

Best regards
> Michael
> >
> > So, I agree with Ted and Sal's sentiments. Fixing up our existing
> designs for existing deployments is definitely very valuable and hopefully
> inevitable, but it does not take away from the fact that QUIC is a clean
> protocol design that incorporates, as first principles, lessons learned
> from our collective past. Going forward, I expect there to be debates about
> which protocol is the best fit for an application, and I encourage that --
> having real choice in transport protocols at design time and at run time is
> a wonderful thing, and it's long overdue.
> >
> > - jana
>
>

--94eb2c12a062df74420533f26983
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Michael,
=C2=A0

so these are some of the requirements, right? I'm wondering if it makes=
 sense to provide such a list

of findings in a protocol independent way. What is important and what is no=
t needs knowledge of the

results of the experiments Google where running.

Without such a description, it is hard for other groups to figure out if it=
 is important to consider

integrating a specific feature of QUIC.

I don't think of them as necessarily requirements, but more as lessons=
 learned. For instance, monotonically-increasing sequence numbers make loss=
 detection and recovery much more efficient, but that's a fundamental d=
esign decision that can't be retrofitted easily. Of course, there are o=
thers, such as the elimination of handshake latency, but that's not a n=
ew lesson for the transport community -- TCP Fast Open was underway in 2009=
.

That said, point taken. Though I'm not sure =
exactly what form or shape such a "lessons" document would take, =
besides continuing presenting data in TSVAREA and/or MAPRG. I'm happy t=
o continue chatting about such a doc, but this forum may not be the right p=
lace for it... especially since I don't think that these lessons are on=
ly being learned in/from QUIC deployment.

- jana


Best regards

Michael


>

> So, I agree with Ted and Sal's sentiments. Fixing up our existing =
designs for existing deployments is definitely very valuable and hopefully =
inevitable, but it does not take away from the fact that QUIC is a clean pr=
otocol design that incorporates, as first principles, lessons learned from =
our collective past. Going forward, I expect there to be debates about whic=
h protocol is the best fit for an application, and I encourage that -- havi=
ng real choice in transport protocols at design time and at run time is a w=
onderful thing, and it's long overdue.

>

> - jana







--94eb2c12a062df74420533f26983--


From nobody Sun May 29 08:28:18 2016
Return-Path: 
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 D142312D09F for ; Sun, 29 May 2016 08:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.027
X-Spam-Level: 
X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 JQt1mFT3s4SS for ; Sun, 29 May 2016 08:28:13 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A963112B020 for ; Sun, 29 May 2016 08:28:12 -0700 (PDT)
Received: from [192.168.1.100] (p508F1C7E.dip0.t-ipconnect.de [80.143.28.126]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 49085721E280C; Sun, 29 May 2016 17:28:09 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Tuexen 
In-Reply-To: 
Date: Sun, 29 May 2016 17:28:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de>
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>  <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de> 
To: Jim Roskind 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: quic@ietf.org
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 May 2016 15:28:16 -0000

> On 28 May 2016, at 18:15, Jim Roskind  wrote:
>=20
> re: "...results of experiments [done by] Google."
>=20
> Publication of experiments done in/around QUIC should be a treasure =
trove for both QUIC and numerous other protocols.
>=20
> Although not all-encompasing, I presented several of Google's =
experimental results to IETF-88 back in 2013.  Be sure to take a look =
at:
>=20
> https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf
>=20
> Included in that IETF presentation (which I think was video recorded) =
were slides showing:
>=20
> a) NAT Eviction probabilities vs time, for UDP bindings (slide 10)
> b) Round-trip packet-loss probability for trains of paced vs unpaced =
packets of various sizes (slides 22 and 23)
> c) Generic 0 vs 1 vs 2 FEC utility for paced and unpaced trains (slide =
24)
>=20
> All such experiments (and many more) need to be repeated and published =
over time, as the deployment of middle boxes, links (mobile variants vs =
non-mobile), routers, contemporaneous traffic patterns, etc. continue to =
evolve.
>=20
> Item (a) showed the viability of a UDP based multi-packet protocol, =
with (then current) caveats that pauses in the stream beyond 30 seconds =
increase eviction rates. This drove QUIC to support handling of that =
progressive increase in eviction. There is some hope that upcoming IETF =
standardization in this area will further improve the NAT-eviction =
landscape, but that will certainly depend on vendors and deployment =
(market penetration) rates.
>=20
> Item (b) showed the tremendous impact (value) of pacing, and also =
showed the remarkable vulnerability (i.e., increased loss probability) =
of the 2nd packet in a cold-connection. That surprising (previously =
unpublished?) 2nd-packet loss statistic was recently observed and =
verified to me verbally by a second vendor for a related UDP protocol =
just a month ago (May 2016) at a public presentation I gave.=20
>=20
> Item (c) better showed the nature of the packet loss correlation (and =
showed that loss should *not* be modeled by an independent identically =
distributed process.). It clearly showed the lack of marginal value of =
multiple-packet error recovery (i.e., 2-packet-loss FEC) for trains as =
long as 21 packets (which is a plausible congestion window for a lossy =
connection). The data also justified the significant utility of =
1-packet-loss FEC for such short windows (i.e., congestion window under =
21) with very latency sensitive transmissions (such as stream creation =
for small latency sensitive requests, including perchance =
advertisements).=20
>=20
> We deduced in 2011 that about 5-7% of all chrome clients had UDP =
blocked (from reaching Google) for even small packets, which is what =
drove the decision to have a TCP fallback plan in QUIC.  I believe that =
experimental deployment results for QUIC continued to support that 5-7% =
statistic, though I'm very hopeful that system administrators will =
change this blocking over time (for the better!).  I also look forward =
to ongoing publication of this statistic by Google.
>=20
> Another Google published result is the fact that UDP payload sizes =
over 1350 bytes tend to be blocked more often, which was indeed the =
driving factor behind QUIC (initially) adopting a static payload size of =
1350 bytes.=20
>=20
> I expect that experiments done by multiple vendors will be published.  =
I know that Firefox adopted Chrome's metrics gathering approach, and =
hopefully if/when an experimental QUIC implementation appears there, =
then additional results will continue to be published.
Hi Jim,

summarising the above means:
1. Legacy NAT traversal (doable via UDP encapsulation)
2. Pacing
3. FEC
4. Path MTU limit
combined with what Jana mentioned:
5. Fast connection setup
6. Improved loss recovery
7. CC agility
8. Encryption of transport layer information

Did I miss anything?

Best regards
Michael
>=20
>=20
>=20
>=20
> On Sat, May 28, 2016 at 1:17 AM, Michael Tuexen =
 wrote:
> > On 28 May 2016, at 04:30, Jana Iyengar  wrote:
> >
> > Hi Michael,
> >
> > Are there any plans to analyse the requirements in a protocol =
independent
> > way and try to figure out if these requirements can also be met by =
evolving
> > one or more of the existing transport protocols (in combination with =
the appropriate
> > (D)TLS)? And then making a decision whether it is appropriate to
> > evolve existing protocols in addition to or instead of developing a =
new one...
> >
> > I agree with you that the requirements of QUIC should be =
requirements for new protocols and for evolution of existing ones. The =
lessons of QUIC are expected to inform other transport work -- QUIC has =
provided inputs to TCP and TLS about the importance of avoiding =
handshake RTTs, and more recently, RACK (draft-cheng-tcpm-rack-00) is =
similar in spirit to QUIC's loss recovery.
> >
> > Subsequent protocol work must learn QUIC's lessons, just as QUIC =
learned from its predecessors. While there's inevitably functional =
overlap between QUIC and any of {TCP, SCTP, MPTCP} (which have overlaps =
of their own), much of the work of QUIC has been in refining and tightly =
integrating mechanisms that we have learned from previous transports =
into a modern transport -- protection of data and headers, low =
latency-overhead, congestion-control agility, and strong loss-recovery, =
to name a few.
> Hi Jana,
>=20
> so these are some of the requirements, right? I'm wondering if it =
makes sense to provide such a list
> of findings in a protocol independent way. What is important and what =
is not needs knowledge of the
> results of the experiments Google where running.
> Without such a description, it is hard for other groups to figure out =
if it is important to consider
> integrating a specific feature of QUIC.
>=20
> Best regards
> Michael
> >
> > So, I agree with Ted and Sal's sentiments. Fixing up our existing =
designs for existing deployments is definitely very valuable and =
hopefully inevitable, but it does not take away from the fact that QUIC =
is a clean protocol design that incorporates, as first principles, =
lessons learned from our collective past. Going forward, I expect there =
to be debates about which protocol is the best fit for an application, =
and I encourage that -- having real choice in transport protocols at =
design time and at run time is a wonderful thing, and it's long overdue.
> >
> > - jana
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>=20


From nobody Mon May 30 04:48:40 2016
Return-Path: 
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 8305C12D1DE for ; Mon, 30 May 2016 04:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 cdJQbr1M9ha4 for ; Mon, 30 May 2016 04:48:35 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 C3FF312D0ED for ; Mon, 30 May 2016 04:48:34 -0700 (PDT)
Received: by mail-qg0-x233.google.com with SMTP id e93so76712484qgf.2 for ; Mon, 30 May 2016 04:48:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=F7hNJRDtkRX2Vef7FqdJp0yxDV1lOXr3h+oD9cyy6Xs=; b=hk9aoskC4vkoAZHM3hRLomyxm01rSbz6Aj9IacYG8uXY1EYAcq29OB7dss3ZH0ZtVJ vg6r2/yNLH9Anxn9KafPmttiTcuGlAuwkW+/s7xGKlcNenoC0OLarnSf/z1D3YyM6SGW u9JpEe5ok5Rg5I1sR9SiFFjYox6sW78tAWXQ0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=F7hNJRDtkRX2Vef7FqdJp0yxDV1lOXr3h+oD9cyy6Xs=; b=VY/MYUjD2Q4ljX4YFMy9y3NjpjXjU5lDn4NGLtTZ3n3BAExQb5Bx9ejydUmdrvVetD zJ12Q0bDpmxFFWEHvTQq29V7vtsCjpOvJud3p9P4Uv40Ob+SNUscQS9Ttid+8JV5Fjoa P3tb/AHI7xOanU9mGgyj+YKvv3nvtc6q7MQpGi353QL4ZTUJ8v+v+8s2nTr63eAqgJcQ HIa5QqzD9VDQa6VGICvuz4YN36/hkZypQptQJSKhg+c2119z1q7GQeZbomFMx8VAUa9v qLu7SgIb/77tBPXLgVqqSFpsqVFxVSQBGH09BSAO/JTsyUNId9k4FMtm9CBpQDKJKs47 dlqQ==
X-Gm-Message-State: ALyK8tKXYtzTPl2jMZmr2xzvzD72dm+PbL8+xeWVrY/KX6NRutvOkoLVRkcEFw2JYwEE/qrA
X-Received: by 10.140.140.200 with SMTP id 191mr26631158qhm.0.1464608913486; Mon, 30 May 2016 04:48:33 -0700 (PDT)
Received: from [100.127.81.90] ([69.53.246.16]) by smtp.gmail.com with ESMTPSA id h92sm9470437qtd.7.2016.05.30.04.48.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 May 2016 04:48:31 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8BC4310A-CA80-492D-8C37-2B9A2D19924F"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Randall Stewart 
In-Reply-To: <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de>
Date: Mon, 30 May 2016 07:48:24 -0400
Message-Id: <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com>
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>  <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de>  <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de>
To: =?iso-8859-1?Q?Michael_T=FCxen?= 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: Jim Roskind , quic@ietf.org
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 11:48:38 -0000

--Apple-Mail=_8BC4310A-CA80-492D-8C37-2B9A2D19924F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Michael:

See below..

On May 29, 2016, at 11:28 AM, Michael Tuexen =
 wrote:

>> On 28 May 2016, at 18:15, Jim Roskind  wrote:
>>=20
>> re: "...results of experiments [done by] Google."
>>=20
>> Publication of experiments done in/around QUIC should be a treasure =
trove for both QUIC and numerous other protocols.
>>=20
>> Although not all-encompasing, I presented several of Google's =
experimental results to IETF-88 back in 2013.  Be sure to take a look =
at:
>>=20
>> https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf
>>=20
>> Included in that IETF presentation (which I think was video recorded) =
were slides showing:
>>=20
>> a) NAT Eviction probabilities vs time, for UDP bindings (slide 10)
>> b) Round-trip packet-loss probability for trains of paced vs unpaced =
packets of various sizes (slides 22 and 23)
>> c) Generic 0 vs 1 vs 2 FEC utility for paced and unpaced trains =
(slide 24)
>>=20
>> All such experiments (and many more) need to be repeated and =
published over time, as the deployment of middle boxes, links (mobile =
variants vs non-mobile), routers, contemporaneous traffic patterns, etc. =
continue to evolve.
>>=20
>> Item (a) showed the viability of a UDP based multi-packet protocol, =
with (then current) caveats that pauses in the stream beyond 30 seconds =
increase eviction rates. This drove QUIC to support handling of that =
progressive increase in eviction. There is some hope that upcoming IETF =
standardization in this area will further improve the NAT-eviction =
landscape, but that will certainly depend on vendors and deployment =
(market penetration) rates.
>>=20
>> Item (b) showed the tremendous impact (value) of pacing, and also =
showed the remarkable vulnerability (i.e., increased loss probability) =
of the 2nd packet in a cold-connection. That surprising (previously =
unpublished?) 2nd-packet loss statistic was recently observed and =
verified to me verbally by a second vendor for a related UDP protocol =
just a month ago (May 2016) at a public presentation I gave.=20
>>=20
>> Item (c) better showed the nature of the packet loss correlation (and =
showed that loss should *not* be modeled by an independent identically =
distributed process.). It clearly showed the lack of marginal value of =
multiple-packet error recovery (i.e., 2-packet-loss FEC) for trains as =
long as 21 packets (which is a plausible congestion window for a lossy =
connection). The data also justified the significant utility of =
1-packet-loss FEC for such short windows (i.e., congestion window under =
21) with very latency sensitive transmissions (such as stream creation =
for small latency sensitive requests, including perchance =
advertisements).=20
>>=20
>> We deduced in 2011 that about 5-7% of all chrome clients had UDP =
blocked (from reaching Google) for even small packets, which is what =
drove the decision to have a TCP fallback plan in QUIC.  I believe that =
experimental deployment results for QUIC continued to support that 5-7% =
statistic, though I'm very hopeful that system administrators will =
change this blocking over time (for the better!).  I also look forward =
to ongoing publication of this statistic by Google.
>>=20
>> Another Google published result is the fact that UDP payload sizes =
over 1350 bytes tend to be blocked more often, which was indeed the =
driving factor behind QUIC (initially) adopting a static payload size of =
1350 bytes.=20
>>=20
>> I expect that experiments done by multiple vendors will be published. =
 I know that Firefox adopted Chrome's metrics gathering approach, and =
hopefully if/when an experimental QUIC implementation appears there, =
then additional results will continue to be published.
> Hi Jim,

Thinking about this list in the broad sense..

>=20
> summarising the above means:
> 1. Legacy NAT traversal (doable via UDP encapsulation)

I think with TCP this is not an issue, SCTP would have to be
like Quic and be wrapped in UDP I think that is already occurring
within rc-web=92s data channel :-)


> 2. Pacing

I think pacing can be done on any transport and in general is
a *good* thing. The one thing about pacing is that it tends to=20
really hurt you in TSO/LRO (at least for TCP). I am currently working
on trying to come up with a method for pacing that does not loose
all the benefits of TSO but still gives us the desired =93paced=94 =
results.

> 3. FEC

This one I think for TCP would be a bit hard.. SCTP could in theory
do it.. I would be quite curious to know how much benefit is really
seen by this. I thought Ian mentioned to us at a past IETF that it
really helped in certain scenarios but how often does that occur
and what scenarios are they?  If google could share how often
they have this on and how much it helps in those cases that
would be interesting=85.

> 4. Path MTU limit

I have noticed, in my TCP work, that PMTU discovery does become
painful at times.. and just having a fixed size makes life a lot easier.
Of course with IPSEC and IPv6 and other fun things 1350 bytes may even =
be
too big :-)

Then again I have heard arguments for keeping Time-Stamps off by default
due to the wasted size in the packet. Which makes me wonder, if we are
so concerned about the time-stamp size should we be concerned about
the extra bytes that we loose in a 1500 byte MTU?=20

Its a shame too since time-stamps really make TCP (with PRR and RACK) =
much
more robust.. We only see 15% or so of connections that have SACK not=20
doing Time-Stamps so its not too bad (I think thats due to the fact that =
most of
our clients are linux based which like FreeBSD and Mac turn time-stamp =
on
by default). Sack on the other hand I see in about 99.9% of all clients =
which
is way cool :-)

> combined with what Jana mentioned:
> 5. Fast connection setup

This I think can be done in both TCP and SCTP.. I would hope that
TLS 1.3 will gain that for all protocols that use it :-)

> 6. Improved loss recovery

I have actually been implementing RACK and PRR for TCP and am
beginning to see the same benefits in TCP that we have heard
about with Quic..  so these are very very useful things thats for sure =
:-)

> 7. CC agility

I can=92t speak for windows or MacOS .. but I think that both Linux and =
FreeBSD
have had this for many years now.. I know when I look in the cc for BSD =
there
are at least eight congestion control algorithms that are available and =
I am sure
Linux probably has more :)

> 8. Encryption of transport layer information

That does eliminate snooping middle boxes.. but some environments (such =
as
mobile) might not like that :-)=20

I doubt you could easily do this with TCP or SCTP.. since middle boxes =
expect
packet formates to look a particular way. Anything new of course does =
not
have this issue.. possibly wrapping a protocol in UDP would gain you =
that though :-)

>=20
> Did I miss anything?

Is multi-streaming missing from the list? I think it was mentioned in =
some
of the slides. We currently don=92t see any benefit in this, but we are =
not
loading multiple images for a web-page.. instead streaming a movie..

I would imagine our client teams during search for a movie might like =
this
but I would imagine they (like many web based things) open multiple =
connections.

One question I wonder (and this is for both Quic and SCTP) is the =
ability to do
LRO/TSO. I have found that one of our Caches which typically outputs =
about
36Gbps drops its speed in 1/2 if I ifconfig off TSO/LRO. When you pull =
the
things into user space and encrypt it you loose the ability to do these =
functions.
I don=92t think SCTP has ever been able to do TSO/LRO as well..  Thats =
one big
impact to performance that needs to be thought about..

I would also like to see any new protocol implementable in the kernel as =
well. Currently
Quic uses a floating point number for time-stamps and that would be =
pretty heavy weight
for the kernel.. having a compatible integer equivalent would be =
something I think that is needed.

Best wishes

R


>=20
> Best regards
> Michael
>>=20
>>=20
>>=20
>>=20
>> On Sat, May 28, 2016 at 1:17 AM, Michael Tuexen =
 wrote:
>>> On 28 May 2016, at 04:30, Jana Iyengar  wrote:
>>>=20
>>> Hi Michael,
>>>=20
>>> Are there any plans to analyse the requirements in a protocol =
independent
>>> way and try to figure out if these requirements can also be met by =
evolving
>>> one or more of the existing transport protocols (in combination with =
the appropriate
>>> (D)TLS)? And then making a decision whether it is appropriate to
>>> evolve existing protocols in addition to or instead of developing a =
new one...
>>>=20
>>> I agree with you that the requirements of QUIC should be =
requirements for new protocols and for evolution of existing ones. The =
lessons of QUIC are expected to inform other transport work -- QUIC has =
provided inputs to TCP and TLS about the importance of avoiding =
handshake RTTs, and more recently, RACK (draft-cheng-tcpm-rack-00) is =
similar in spirit to QUIC's loss recovery.
>>>=20
>>> Subsequent protocol work must learn QUIC's lessons, just as QUIC =
learned from its predecessors. While there's inevitably functional =
overlap between QUIC and any of {TCP, SCTP, MPTCP} (which have overlaps =
of their own), much of the work of QUIC has been in refining and tightly =
integrating mechanisms that we have learned from previous transports =
into a modern transport -- protection of data and headers, low =
latency-overhead, congestion-control agility, and strong loss-recovery, =
to name a few.
>> Hi Jana,
>>=20
>> so these are some of the requirements, right? I'm wondering if it =
makes sense to provide such a list
>> of findings in a protocol independent way. What is important and what =
is not needs knowledge of the
>> results of the experiments Google where running.
>> Without such a description, it is hard for other groups to figure out =
if it is important to consider
>> integrating a specific feature of QUIC.
>>=20
>> Best regards
>> Michael
>>>=20
>>> So, I agree with Ted and Sal's sentiments. Fixing up our existing =
designs for existing deployments is definitely very valuable and =
hopefully inevitable, but it does not take away from the fact that QUIC =
is a clean protocol design that incorporates, as first principles, =
lessons learned from our collective past. Going forward, I expect there =
to be debates about which protocol is the best fit for an application, =
and I encourage that -- having real choice in transport protocols at =
design time and at run time is a wonderful thing, and it's long overdue.
>>>=20
>>> - jana
>>=20
>> _______________________________________________
>> QUIC mailing list
>> QUIC@ietf.org
>> https://www.ietf.org/mailman/listinfo/quic
>>=20
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic

--------
Randall Stewart
rrs@netflix.com
803-317-4952






--Apple-Mail=_8BC4310A-CA80-492D-8C37-2B9A2D19924F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Michael:

See =
below..

On May 29, 2016, at 11:28 AM, Michael =
Tuexen <Michael.Tuexen@lurchi.fra=
nken.de> wrote:

On 28 May =
2016, at 18:15, Jim Roskind <JimRoskind@gmail.com> =
wrote:

re: "...results of experiments [done by] =
Google."

Publication of experiments done in/around QUIC should be =
a treasure trove for both QUIC and numerous other =
protocols.

Although not all-encompasing, I presented several of =
Google's experimental results to IETF-88 back in 2013.  Be sure to =
take a look at:

https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf=


Included in that IETF presentation (which I think was video =
recorded) were slides showing:

a) NAT Eviction probabilities vs =
time, for UDP bindings (slide 10)
b) Round-trip packet-loss =
probability for trains of paced vs unpaced packets of various sizes =
(slides 22 and 23)
c) Generic 0 vs 1 vs 2 FEC utility for paced and =
unpaced trains (slide 24)

All such experiments (and many more) =
need to be repeated and published over time, as the deployment of middle =
boxes, links (mobile variants vs non-mobile), routers, contemporaneous =
traffic patterns, etc. continue to evolve.

Item (a) showed the =
viability of a UDP based multi-packet protocol, with (then current) =
caveats that pauses in the stream beyond 30 seconds increase eviction =
rates. This drove QUIC to support handling of that progressive increase =
in eviction. There is some hope that upcoming IETF standardization in =
this area will further improve the NAT-eviction landscape, but that will =
certainly depend on vendors and deployment (market penetration) =
rates.

Item (b) showed the tremendous impact (value) of pacing, =
and also showed the remarkable vulnerability (i.e., increased loss =
probability) of the 2nd packet in a cold-connection. That surprising =
(previously unpublished?) 2nd-packet loss statistic was recently =
observed and verified to me verbally by a second vendor for a related =
UDP protocol just a month ago (May 2016) at a public presentation I =
gave. 

Item (c) =
better showed the nature of the packet loss correlation (and showed that =
loss should *not* be modeled by an independent identically distributed =
process.). It clearly showed the lack of marginal value of =
multiple-packet error recovery (i.e., 2-packet-loss FEC) for trains as =
long as 21 packets (which is a plausible congestion window for a lossy =
connection). The data also justified the significant utility of =
1-packet-loss FEC for such short windows (i.e., congestion window under =
21) with very latency sensitive transmissions (such as stream creation =
for small latency sensitive requests, including perchance =
advertisements). 

We deduced in 2011 =
that about 5-7% of all chrome clients had UDP blocked (from reaching =
Google) for even small packets, which is what drove the decision to have =
a TCP fallback plan in QUIC.  I believe that experimental =
deployment results for QUIC continued to support that 5-7% statistic, =
though I'm very hopeful that system administrators will change this =
blocking over time (for the better!).  I also look forward to =
ongoing publication of this statistic by Google.

Another Google =
published result is the fact that UDP payload sizes over 1350 bytes tend =
to be blocked more often, which was indeed the driving factor behind =
QUIC (initially) adopting a static payload size of 1350 bytes. 

I expect that =
experiments done by multiple vendors will be published.  I know =
that Firefox adopted Chrome's metrics gathering approach, and hopefully =
if/when an experimental QUIC implementation appears there, then =
additional results will continue to be published.
Hi =
Jim,

Thinking about this list in =
the broad sense..


summarising the above means:
1. =
Legacy NAT traversal (doable via UDP =
encapsulation)

I think with =
TCP this is not an issue, SCTP would have to be
like Quic and =
be wrapped in UDP I think that is already occurring
within =
rc-web=92s data channel :-)


2. =
Pacing

I think pacing can be =
done on any transport and in general is
a *good* thing. The =
one thing about pacing is that it tends to 
really hurt =
you in TSO/LRO (at least for TCP). I am currently working
on =
trying to come up with a method for pacing that does not =
loose
all the benefits of TSO but still gives us the desired =
=93paced=94 results.

3. =
FEC

This one I think for TCP =
would be a bit hard.. SCTP could in theory
do it.. I would be =
quite curious to know how much benefit is really
seen by this. =
I thought Ian mentioned to us at a past IETF that it
really =
helped in certain scenarios but how often does that occur
and =
what scenarios are they?  If google could share how =
often
they have this on and how much it helps in those cases =
that
would be interesting=85.

4. Path MTU =
limit

I have noticed, in my =
TCP work, that PMTU discovery does become
painful at times.. =
and just having a fixed size makes life a lot easier.
Of =
course with IPSEC and IPv6 and other fun things 1350 bytes may even =
be
too big :-)

Then again I have =
heard arguments for keeping Time-Stamps off by default
due to =
the wasted size in the packet. Which makes me wonder, if we =
are
so concerned about the time-stamp size should we be =
concerned about
the extra bytes that we loose in a 1500 byte =
MTU? 

Its a shame too since time-stamps =
really make TCP (with PRR and RACK) much
more robust.. We only =
see 15% or so of connections that have SACK not 
doing =
Time-Stamps so its not too bad (I think thats due to the fact that most =
of
our clients are linux based which like FreeBSD and Mac turn =
time-stamp on
by default). Sack on the other hand I see in =
about 99.9% of all clients which
is way cool =
:-)

combined with what Jana mentioned:
5. Fast connection =
setup

This I think can be done =
in both TCP and SCTP.. I would hope that
TLS 1.3 will gain =
that for all protocols that use it :-)

6. Improved loss =
recovery

I have actually been =
implementing RACK and PRR for TCP and am
beginning to see the =
same benefits in TCP that we have heard
about with Quic.. =
 so these are very very useful things thats for sure =
:-)

7. CC =
agility

I can=92t speak for =
windows or MacOS .. but I think that both Linux and =
FreeBSD
have had this for many years now.. I know when I look =
in the cc for BSD there
are at least eight congestion control =
algorithms that are available and I am sure
Linux probably has =
more :)

8. =
Encryption of transport layer =
information

That does eliminate =
snooping middle boxes.. but some environments (such as
mobile) =
might not like that :-) 

I doubt you could =
easily do this with TCP or SCTP.. since middle boxes =
expect
packet formates to look a particular way. Anything new =
of course does not
have this issue.. possibly wrapping a =
protocol in UDP would gain you that though :-)


Did I miss =
anything?

Is multi-streaming =
missing from the list? I think it was mentioned in some
of the =
slides. We currently don=92t see any benefit in this, but we are =
not
loading multiple images for a web-page.. instead streaming =
a movie..

I would imagine our client teams =
during search for a movie might like this
but I would imagine =
they (like many web based things) open multiple =
connections.

One question I wonder (and this is =
for both Quic and SCTP) is the ability to do
LRO/TSO. I have =
found that one of our Caches which typically outputs =
about
36Gbps drops its speed in 1/2 if I ifconfig off TSO/LRO. =
When you pull the
things into user space and encrypt it you =
loose the ability to do these functions.
I don=92t think SCTP =
has ever been able to do TSO/LRO as well..  Thats one =
big
impact to performance that needs to be thought =
about..

I would also like to see any new =
protocol implementable in the kernel as well. Currently
Quic =
uses a floating point number for time-stamps and that would be pretty =
heavy weight
for the kernel.. having a compatible integer =
equivalent would be something I think that is =
needed.

Best =
wishes

R



Best =
regards
Michael




On Sat, =
May 28, 2016 at 1:17 AM, Michael Tuexen <Michael.Tuexen@lurchi.fra=
nken.de> wrote:
On 28 May 2016, at =
04:30, Jana Iyengar <jri@google.com> wrote:

Hi =
Michael,

Are there any plans to analyse the requirements in a =
protocol independent
way and try to figure out if these requirements =
can also be met by evolving
one or more of the existing transport =
protocols (in combination with the appropriate
(D)TLS)? And then =
making a decision whether it is appropriate to
evolve existing =
protocols in addition to or instead of developing a new one...

I =
agree with you that the requirements of QUIC should be requirements for =
new protocols and for evolution of existing ones. The lessons of QUIC =
are expected to inform other transport work -- QUIC has provided inputs =
to TCP and TLS about the importance of avoiding handshake RTTs, and more =
recently, RACK (draft-cheng-tcpm-rack-00) is similar in spirit to QUIC's =
loss recovery.

Subsequent protocol work must learn QUIC's =
lessons, just as QUIC learned from its predecessors. While there's =
inevitably functional overlap between QUIC and any of {TCP, SCTP, MPTCP} =
(which have overlaps of their own), much of the work of QUIC has been in =
refining and tightly integrating mechanisms that we have learned from =
previous transports into a modern transport -- protection of data and =
headers, low latency-overhead, congestion-control agility, and strong =
loss-recovery, to name a few.
Hi Jana,

so these =
are some of the requirements, right? I'm wondering if it makes sense to =
provide such a list
of findings in a protocol independent way. What =
is important and what is not needs knowledge of the
results of the =
experiments Google where running.
Without such a description, it is =
hard for other groups to figure out if it is important to =
consider
integrating a specific feature of QUIC.

Best =
regards
Michael

So, I agree with Ted =
and Sal's sentiments. Fixing up our existing designs for existing =
deployments is definitely very valuable and hopefully inevitable, but it =
does not take away from the fact that QUIC is a clean protocol design =
that incorporates, as first principles, lessons learned from our =
collective past. Going forward, I expect there to be debates about which =
protocol is the best fit for an application, and I encourage that -- =
having real choice in transport protocols at design time and at run time =
is a wonderful thing, and it's long overdue.

- =
jana

_______________________________________________QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/quic


______________________________=
_________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/quic



--------
Randall Stewart
803-317-4952=









=

--Apple-Mail=_8BC4310A-CA80-492D-8C37-2B9A2D19924F--


From nobody Mon May 30 06:19:07 2016
Return-Path: 
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 66BA712D54C for ; Mon, 30 May 2016 06:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.027
X-Spam-Level: 
X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 P7yPJsphvhfV for ; Mon, 30 May 2016 06:19:02 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1634012D535 for ; Mon, 30 May 2016 06:19:02 -0700 (PDT)
Received: from [10.225.20.58] (nat-eduroam-st-111.fh-muenster.de [194.95.73.111]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id DC094721E280C; Mon, 30 May 2016 15:18:58 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Tuexen 
In-Reply-To: <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com>
Date: Mon, 30 May 2016 15:18:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>  <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de>  <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com>
To: Randall Stewart 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Jim Roskind , quic@ietf.org
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 13:19:06 -0000

> On 30 May 2016, at 13:48, Randall Stewart  wrote:
>=20
> Michael:
>=20
> See below..
>=20
> On May 29, 2016, at 11:28 AM, Michael Tuexen =
 wrote:
>=20
>>> On 28 May 2016, at 18:15, Jim Roskind  wrote:
>>>=20
>>> re: "...results of experiments [done by] Google."
>>>=20
>>> Publication of experiments done in/around QUIC should be a treasure =
trove for both QUIC and numerous other protocols.
>>>=20
>>> Although not all-encompasing, I presented several of Google's =
experimental results to IETF-88 back in 2013.  Be sure to take a look =
at:
>>>=20
>>> https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf
>>>=20
>>> Included in that IETF presentation (which I think was video =
recorded) were slides showing:
>>>=20
>>> a) NAT Eviction probabilities vs time, for UDP bindings (slide 10)
>>> b) Round-trip packet-loss probability for trains of paced vs unpaced =
packets of various sizes (slides 22 and 23)
>>> c) Generic 0 vs 1 vs 2 FEC utility for paced and unpaced trains =
(slide 24)
>>>=20
>>> All such experiments (and many more) need to be repeated and =
published over time, as the deployment of middle boxes, links (mobile =
variants vs non-mobile), routers, contemporaneous traffic patterns, etc. =
continue to evolve.
>>>=20
>>> Item (a) showed the viability of a UDP based multi-packet protocol, =
with (then current) caveats that pauses in the stream beyond 30 seconds =
increase eviction rates. This drove QUIC to support handling of that =
progressive increase in eviction. There is some hope that upcoming IETF =
standardization in this area will further improve the NAT-eviction =
landscape, but that will certainly depend on vendors and deployment =
(market penetration) rates.
>>>=20
>>> Item (b) showed the tremendous impact (value) of pacing, and also =
showed the remarkable vulnerability (i.e., increased loss probability) =
of the 2nd packet in a cold-connection. That surprising (previously =
unpublished?) 2nd-packet loss statistic was recently observed and =
verified to me verbally by a second vendor for a related UDP protocol =
just a month ago (May 2016) at a public presentation I gave.=20
>>>=20
>>> Item (c) better showed the nature of the packet loss correlation =
(and showed that loss should *not* be modeled by an independent =
identically distributed process.). It clearly showed the lack of =
marginal value of multiple-packet error recovery (i.e., 2-packet-loss =
FEC) for trains as long as 21 packets (which is a plausible congestion =
window for a lossy connection). The data also justified the significant =
utility of 1-packet-loss FEC for such short windows (i.e., congestion =
window under 21) with very latency sensitive transmissions (such as =
stream creation for small latency sensitive requests, including =
perchance advertisements).=20
>>>=20
>>> We deduced in 2011 that about 5-7% of all chrome clients had UDP =
blocked (from reaching Google) for even small packets, which is what =
drove the decision to have a TCP fallback plan in QUIC.  I believe that =
experimental deployment results for QUIC continued to support that 5-7% =
statistic, though I'm very hopeful that system administrators will =
change this blocking over time (for the better!).  I also look forward =
to ongoing publication of this statistic by Google.
>>>=20
>>> Another Google published result is the fact that UDP payload sizes =
over 1350 bytes tend to be blocked more often, which was indeed the =
driving factor behind QUIC (initially) adopting a static payload size of =
1350 bytes.=20
>>>=20
>>> I expect that experiments done by multiple vendors will be =
published.  I know that Firefox adopted Chrome's metrics gathering =
approach, and hopefully if/when an experimental QUIC implementation =
appears there, then additional results will continue to be published.
>> Hi Jim,
>=20
> Thinking about this list in the broad sense..
>=20
>>=20
>> summarising the above means:
>> 1. Legacy NAT traversal (doable via UDP encapsulation)
>=20
> I think with TCP this is not an issue, SCTP would have to be
> like Quic and be wrapped in UDP I think that is already occurring
> within rc-web=92s data channel :-)
>=20
>=20
>> 2. Pacing
>=20
> I think pacing can be done on any transport and in general is
> a *good* thing. The one thing about pacing is that it tends to=20
> really hurt you in TSO/LRO (at least for TCP). I am currently working
> on trying to come up with a method for pacing that does not loose
> all the benefits of TSO but still gives us the desired =93paced=94 =
results.
>=20
>> 3. FEC
>=20
> This one I think for TCP would be a bit hard.. SCTP could in theory
> do it.. I would be quite curious to know how much benefit is really
> seen by this. I thought Ian mentioned to us at a past IETF that it
> really helped in certain scenarios but how often does that occur
> and what scenarios are they?  If google could share how often
> they have this on and how much it helps in those cases that
> would be interesting=85.
>=20
>> 4. Path MTU limit
>=20
> I have noticed, in my TCP work, that PMTU discovery does become
> painful at times.. and just having a fixed size makes life a lot =
easier.
> Of course with IPSEC and IPv6 and other fun things 1350 bytes may even =
be
> too big :-)
>=20
> Then again I have heard arguments for keeping Time-Stamps off by =
default
> due to the wasted size in the packet. Which makes me wonder, if we are
> so concerned about the time-stamp size should we be concerned about
> the extra bytes that we loose in a 1500 byte MTU?=20
>=20
> Its a shame too since time-stamps really make TCP (with PRR and RACK) =
much
> more robust.. We only see 15% or so of connections that have SACK not=20=

> doing Time-Stamps so its not too bad (I think thats due to the fact =
that most of
> our clients are linux based which like FreeBSD and Mac turn time-stamp =
on
> by default). Sack on the other hand I see in about 99.9% of all =
clients which
> is way cool :-)
>=20
>> combined with what Jana mentioned:
>> 5. Fast connection setup
>=20
> This I think can be done in both TCP and SCTP.. I would hope that
> TLS 1.3 will gain that for all protocols that use it :-)
>=20
>> 6. Improved loss recovery
>=20
> I have actually been implementing RACK and PRR for TCP and am
> beginning to see the same benefits in TCP that we have heard
> about with Quic..  so these are very very useful things thats for sure =
:-)
>=20
>> 7. CC agility
>=20
> I can=92t speak for windows or MacOS .. but I think that both Linux =
and FreeBSD
> have had this for many years now.. I know when I look in the cc for =
BSD there
> are at least eight congestion control algorithms that are available =
and I am sure
> Linux probably has more :)
>=20
>> 8. Encryption of transport layer information
>=20
> That does eliminate snooping middle boxes.. but some environments =
(such as
> mobile) might not like that :-)=20
>=20
> I doubt you could easily do this with TCP or SCTP.. since middle boxes =
expect
> packet formates to look a particular way. Anything new of course does =
not
> have this issue.. possibly wrapping a protocol in UDP would gain you =
that though :-)
>=20
>>=20
>> Did I miss anything?
>=20
> Is multi-streaming missing from the list? I think it was mentioned in =
some
> of the slides. We currently don=92t see any benefit in this, but we =
are not
> loading multiple images for a web-page.. instead streaming a movie..
Ahh, yes. I missed that.
>=20
> I would imagine our client teams during search for a movie might like =
this
> but I would imagine they (like many web based things) open multiple =
connections.
>=20
> One question I wonder (and this is for both Quic and SCTP) is the =
ability to do
> LRO/TSO. I have found that one of our Caches which typically outputs =
about
> 36Gbps drops its speed in 1/2 if I ifconfig off TSO/LRO. When you pull =
the
Is this also true when you do non-hardware assisted TLS? If not, then =
this
features becomes less important when you consider a combined =
transport/security
layer as an entity...

Best regards
Michael
> things into user space and encrypt it you loose the ability to do =
these functions.
> I don=92t think SCTP has ever been able to do TSO/LRO as well..  Thats =
one big
> impact to performance that needs to be thought about..
>=20
> I would also like to see any new protocol implementable in the kernel =
as well. Currently
> Quic uses a floating point number for time-stamps and that would be =
pretty heavy weight
> for the kernel.. having a compatible integer equivalent would be =
something I think that is needed.
>=20
> Best wishes
>=20
> R
>=20
>=20
>>=20
>> Best regards
>> Michael
>>>=20
>>>=20
>>>=20
>>>=20
>>> On Sat, May 28, 2016 at 1:17 AM, Michael Tuexen =
 wrote:
>>>> On 28 May 2016, at 04:30, Jana Iyengar  wrote:
>>>>=20
>>>> Hi Michael,
>>>>=20
>>>> Are there any plans to analyse the requirements in a protocol =
independent
>>>> way and try to figure out if these requirements can also be met by =
evolving
>>>> one or more of the existing transport protocols (in combination =
with the appropriate
>>>> (D)TLS)? And then making a decision whether it is appropriate to
>>>> evolve existing protocols in addition to or instead of developing a =
new one...
>>>>=20
>>>> I agree with you that the requirements of QUIC should be =
requirements for new protocols and for evolution of existing ones. The =
lessons of QUIC are expected to inform other transport work -- QUIC has =
provided inputs to TCP and TLS about the importance of avoiding =
handshake RTTs, and more recently, RACK (draft-cheng-tcpm-rack-00) is =
similar in spirit to QUIC's loss recovery.
>>>>=20
>>>> Subsequent protocol work must learn QUIC's lessons, just as QUIC =
learned from its predecessors. While there's inevitably functional =
overlap between QUIC and any of {TCP, SCTP, MPTCP} (which have overlaps =
of their own), much of the work of QUIC has been in refining and tightly =
integrating mechanisms that we have learned from previous transports =
into a modern transport -- protection of data and headers, low =
latency-overhead, congestion-control agility, and strong loss-recovery, =
to name a few.
>>> Hi Jana,
>>>=20
>>> so these are some of the requirements, right? I'm wondering if it =
makes sense to provide such a list
>>> of findings in a protocol independent way. What is important and =
what is not needs knowledge of the
>>> results of the experiments Google where running.
>>> Without such a description, it is hard for other groups to figure =
out if it is important to consider
>>> integrating a specific feature of QUIC.
>>>=20
>>> Best regards
>>> Michael
>>>>=20
>>>> So, I agree with Ted and Sal's sentiments. Fixing up our existing =
designs for existing deployments is definitely very valuable and =
hopefully inevitable, but it does not take away from the fact that QUIC =
is a clean protocol design that incorporates, as first principles, =
lessons learned from our collective past. Going forward, I expect there =
to be debates about which protocol is the best fit for an application, =
and I encourage that -- having real choice in transport protocols at =
design time and at run time is a wonderful thing, and it's long overdue.
>>>>=20
>>>> - jana
>>>=20
>>> _______________________________________________
>>> QUIC mailing list
>>> QUIC@ietf.org
>>> https://www.ietf.org/mailman/listinfo/quic
>>>=20
>>=20
>> _______________________________________________
>> QUIC mailing list
>> QUIC@ietf.org
>> https://www.ietf.org/mailman/listinfo/quic
>=20
> --------
> Randall Stewart
> rrs@netflix.com
> 803-317-4952
>=20
>=20
>=20
>=20
>=20


From nobody Mon May 30 06:23:01 2016
Return-Path: 
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 33A3C12D54F for ; Mon, 30 May 2016 06:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 I1dnv-owunv7 for ; Mon, 30 May 2016 06:22:54 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 1B96E12D535 for ; Mon, 30 May 2016 06:22:54 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id y126so122198649qke.1 for ; Mon, 30 May 2016 06:22:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=RRqsMrLINQHrvsnFjChBlsIywLJgMv7A3SEoC/YGYVI=; b=KwFOXDFTSxLZsFRWKa/vtDRgqoDAB2H+0sQOIVA4ZWlAF41HcfdjE2VP3iVdp+lA1W XTl69mZ3X/IA81fUk/PhIgvj1iqVirQG8skEs2GhO4qm7T/YZTxYugsa6w10GIvk8w9L cKZCz0OGgbvRv9FYJtM5VZglwDs1VQp/I0yJk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RRqsMrLINQHrvsnFjChBlsIywLJgMv7A3SEoC/YGYVI=; b=PcUApta+5CnmfrFdh5M9cIQVNeCTlvC055e7HNEMKJIutbmUaQXWRzEnQ/eNWJHYsg 7LnOer3Fz4Es8buGGuBEo0PHbWTXKt2r+Ox2JTGgN9Q/a5BkFjh389i+cghNxCkISKHi ThkUx1728SiQ7xbLtPaGQV6v1tKdaIMx2yrg3kJFXisn8HFRoOmqQ1JhSKsDQioy0gZn dsL01CnCUV6ugvB8Nursg54kuVi7lyt432wQw5D1hujyytIooecopivSYpcIt5OZyMjR tpuvFC9hkbgcGRPaEi6JMwvqpdjwZ8eTB7FAbXdpOSMuuoGuwjljKpimp9n7Lim5DDG5 t1UA==
X-Gm-Message-State: ALyK8tJsCYdtyjQEcZyCXKrOMs0ePlsMwsmWVUjROJiZb2l1kNHAR13QW85sReS0j6HfTu3n
X-Received: by 10.55.159.72 with SMTP id i69mr2405695qke.29.1464614572899; Mon, 30 May 2016 06:22:52 -0700 (PDT)
Received: from [100.127.81.90] ([69.53.246.16]) by smtp.gmail.com with ESMTPSA id v18sm1540957qhb.47.2016.05.30.06.22.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 May 2016 06:22:49 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7FCC08F5-EFF9-4115-B04E-38453FD02519"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Randall Stewart 
In-Reply-To: 
Date: Mon, 30 May 2016 09:22:41 -0400
Message-Id: <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com>
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>  <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de>  <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com> 
To: =?iso-8859-1?Q?Michael_T=FCxen?= 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: Jim Roskind , quic@ietf.org
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2016 13:22:58 -0000

--Apple-Mail=_7FCC08F5-EFF9-4115-B04E-38453FD02519
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On May 30, 2016, at 9:18 AM, Michael Tuexen =
 wrote:

>> On 30 May 2016, at 13:48, Randall Stewart  wrote:
>>=20
>> Michael:
>>=20
>> See below..
>>=20
>> On May 29, 2016, at 11:28 AM, Michael Tuexen =
 wrote:
>>=20
>>>> On 28 May 2016, at 18:15, Jim Roskind  wrote:
>>>>=20
>>>> re: "...results of experiments [done by] Google."
>>>>=20
>>>> Publication of experiments done in/around QUIC should be a treasure =
trove for both QUIC and numerous other protocols.
>>>>=20
>>>> Although not all-encompasing, I presented several of Google's =
experimental results to IETF-88 back in 2013.  Be sure to take a look =
at:
>>>>=20
>>>> https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf
>>>>=20
>>>> Included in that IETF presentation (which I think was video =
recorded) were slides showing:
>>>>=20
>>>> a) NAT Eviction probabilities vs time, for UDP bindings (slide 10)
>>>> b) Round-trip packet-loss probability for trains of paced vs =
unpaced packets of various sizes (slides 22 and 23)
>>>> c) Generic 0 vs 1 vs 2 FEC utility for paced and unpaced trains =
(slide 24)
>>>>=20
>>>> All such experiments (and many more) need to be repeated and =
published over time, as the deployment of middle boxes, links (mobile =
variants vs non-mobile), routers, contemporaneous traffic patterns, etc. =
continue to evolve.
>>>>=20
>>>> Item (a) showed the viability of a UDP based multi-packet protocol, =
with (then current) caveats that pauses in the stream beyond 30 seconds =
increase eviction rates. This drove QUIC to support handling of that =
progressive increase in eviction. There is some hope that upcoming IETF =
standardization in this area will further improve the NAT-eviction =
landscape, but that will certainly depend on vendors and deployment =
(market penetration) rates.
>>>>=20
>>>> Item (b) showed the tremendous impact (value) of pacing, and also =
showed the remarkable vulnerability (i.e., increased loss probability) =
of the 2nd packet in a cold-connection. That surprising (previously =
unpublished?) 2nd-packet loss statistic was recently observed and =
verified to me verbally by a second vendor for a related UDP protocol =
just a month ago (May 2016) at a public presentation I gave.=20
>>>>=20
>>>> Item (c) better showed the nature of the packet loss correlation =
(and showed that loss should *not* be modeled by an independent =
identically distributed process.). It clearly showed the lack of =
marginal value of multiple-packet error recovery (i.e., 2-packet-loss =
FEC) for trains as long as 21 packets (which is a plausible congestion =
window for a lossy connection). The data also justified the significant =
utility of 1-packet-loss FEC for such short windows (i.e., congestion =
window under 21) with very latency sensitive transmissions (such as =
stream creation for small latency sensitive requests, including =
perchance advertisements).=20
>>>>=20
>>>> We deduced in 2011 that about 5-7% of all chrome clients had UDP =
blocked (from reaching Google) for even small packets, which is what =
drove the decision to have a TCP fallback plan in QUIC.  I believe that =
experimental deployment results for QUIC continued to support that 5-7% =
statistic, though I'm very hopeful that system administrators will =
change this blocking over time (for the better!).  I also look forward =
to ongoing publication of this statistic by Google.
>>>>=20
>>>> Another Google published result is the fact that UDP payload sizes =
over 1350 bytes tend to be blocked more often, which was indeed the =
driving factor behind QUIC (initially) adopting a static payload size of =
1350 bytes.=20
>>>>=20
>>>> I expect that experiments done by multiple vendors will be =
published.  I know that Firefox adopted Chrome's metrics gathering =
approach, and hopefully if/when an experimental QUIC implementation =
appears there, then additional results will continue to be published.
>>> Hi Jim,
>>=20
>> Thinking about this list in the broad sense..
>>=20
>>>=20
>>> summarising the above means:
>>> 1. Legacy NAT traversal (doable via UDP encapsulation)
>>=20
>> I think with TCP this is not an issue, SCTP would have to be
>> like Quic and be wrapped in UDP I think that is already occurring
>> within rc-web=92s data channel :-)
>>=20
>>=20
>>> 2. Pacing
>>=20
>> I think pacing can be done on any transport and in general is
>> a *good* thing. The one thing about pacing is that it tends to=20
>> really hurt you in TSO/LRO (at least for TCP). I am currently working
>> on trying to come up with a method for pacing that does not loose
>> all the benefits of TSO but still gives us the desired =93paced=94 =
results.
>>=20
>>> 3. FEC
>>=20
>> This one I think for TCP would be a bit hard.. SCTP could in theory
>> do it.. I would be quite curious to know how much benefit is really
>> seen by this. I thought Ian mentioned to us at a past IETF that it
>> really helped in certain scenarios but how often does that occur
>> and what scenarios are they?  If google could share how often
>> they have this on and how much it helps in those cases that
>> would be interesting=85.
>>=20
>>> 4. Path MTU limit
>>=20
>> I have noticed, in my TCP work, that PMTU discovery does become
>> painful at times.. and just having a fixed size makes life a lot =
easier.
>> Of course with IPSEC and IPv6 and other fun things 1350 bytes may =
even be
>> too big :-)
>>=20
>> Then again I have heard arguments for keeping Time-Stamps off by =
default
>> due to the wasted size in the packet. Which makes me wonder, if we =
are
>> so concerned about the time-stamp size should we be concerned about
>> the extra bytes that we loose in a 1500 byte MTU?=20
>>=20
>> Its a shame too since time-stamps really make TCP (with PRR and RACK) =
much
>> more robust.. We only see 15% or so of connections that have SACK not=20=

>> doing Time-Stamps so its not too bad (I think thats due to the fact =
that most of
>> our clients are linux based which like FreeBSD and Mac turn =
time-stamp on
>> by default). Sack on the other hand I see in about 99.9% of all =
clients which
>> is way cool :-)
>>=20
>>> combined with what Jana mentioned:
>>> 5. Fast connection setup
>>=20
>> This I think can be done in both TCP and SCTP.. I would hope that
>> TLS 1.3 will gain that for all protocols that use it :-)
>>=20
>>> 6. Improved loss recovery
>>=20
>> I have actually been implementing RACK and PRR for TCP and am
>> beginning to see the same benefits in TCP that we have heard
>> about with Quic..  so these are very very useful things thats for =
sure :-)
>>=20
>>> 7. CC agility
>>=20
>> I can=92t speak for windows or MacOS .. but I think that both Linux =
and FreeBSD
>> have had this for many years now.. I know when I look in the cc for =
BSD there
>> are at least eight congestion control algorithms that are available =
and I am sure
>> Linux probably has more :)
>>=20
>>> 8. Encryption of transport layer information
>>=20
>> That does eliminate snooping middle boxes.. but some environments =
(such as
>> mobile) might not like that :-)=20
>>=20
>> I doubt you could easily do this with TCP or SCTP.. since middle =
boxes expect
>> packet formates to look a particular way. Anything new of course does =
not
>> have this issue.. possibly wrapping a protocol in UDP would gain you =
that though :-)
>>=20
>>>=20
>>> Did I miss anything?
>>=20
>> Is multi-streaming missing from the list? I think it was mentioned in =
some
>> of the slides. We currently don=92t see any benefit in this, but we =
are not
>> loading multiple images for a web-page.. instead streaming a movie..
> Ahh, yes. I missed that.
>>=20
>> I would imagine our client teams during search for a movie might like =
this
>> but I would imagine they (like many web based things) open multiple =
connections.
>>=20
>> One question I wonder (and this is for both Quic and SCTP) is the =
ability to do
>> LRO/TSO. I have found that one of our Caches which typically outputs =
about
>> 36Gbps drops its speed in 1/2 if I ifconfig off TSO/LRO. When you =
pull the
> Is this also true when you do non-hardware assisted TLS? If not, then =
this
> features becomes less important when you consider a combined =
transport/security
> layer as an entity=85


We actually do TLS encryption inside the kernel ahead of TSO. It is true
that we generally only send 16k at a time to TSO (the TLS record length) =
but this
does not seem to cause us to suffer too much.

How this all works can be found at:

https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf

and

https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf

So though encryption is happening in the kernel we still can use TSO.. =
and do :-)

We have one particular machine that we get 80Gbps of encrypted traffic =
out of (our
newest flash cache :-D.. thanks to a whole *lot* of work from the NF OCA =
team :D)

R

>=20
> Best regards
> Michael
>> things into user space and encrypt it you loose the ability to do =
these functions.
>> I don=92t think SCTP has ever been able to do TSO/LRO as well..  =
Thats one big
>> impact to performance that needs to be thought about..
>>=20
>> I would also like to see any new protocol implementable in the kernel =
as well. Currently
>> Quic uses a floating point number for time-stamps and that would be =
pretty heavy weight
>> for the kernel.. having a compatible integer equivalent would be =
something I think that is needed.
>>=20
>> Best wishes
>>=20
>> R
>>=20
>>=20
>>>=20
>>> Best regards
>>> Michael
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On Sat, May 28, 2016 at 1:17 AM, Michael Tuexen =
 wrote:
>>>>> On 28 May 2016, at 04:30, Jana Iyengar  wrote:
>>>>>=20
>>>>> Hi Michael,
>>>>>=20
>>>>> Are there any plans to analyse the requirements in a protocol =
independent
>>>>> way and try to figure out if these requirements can also be met by =
evolving
>>>>> one or more of the existing transport protocols (in combination =
with the appropriate
>>>>> (D)TLS)? And then making a decision whether it is appropriate to
>>>>> evolve existing protocols in addition to or instead of developing =
a new one...
>>>>>=20
>>>>> I agree with you that the requirements of QUIC should be =
requirements for new protocols and for evolution of existing ones. The =
lessons of QUIC are expected to inform other transport work -- QUIC has =
provided inputs to TCP and TLS about the importance of avoiding =
handshake RTTs, and more recently, RACK (draft-cheng-tcpm-rack-00) is =
similar in spirit to QUIC's loss recovery.
>>>>>=20
>>>>> Subsequent protocol work must learn QUIC's lessons, just as QUIC =
learned from its predecessors. While there's inevitably functional =
overlap between QUIC and any of {TCP, SCTP, MPTCP} (which have overlaps =
of their own), much of the work of QUIC has been in refining and tightly =
integrating mechanisms that we have learned from previous transports =
into a modern transport -- protection of data and headers, low =
latency-overhead, congestion-control agility, and strong loss-recovery, =
to name a few.
>>>> Hi Jana,
>>>>=20
>>>> so these are some of the requirements, right? I'm wondering if it =
makes sense to provide such a list
>>>> of findings in a protocol independent way. What is important and =
what is not needs knowledge of the
>>>> results of the experiments Google where running.
>>>> Without such a description, it is hard for other groups to figure =
out if it is important to consider
>>>> integrating a specific feature of QUIC.
>>>>=20
>>>> Best regards
>>>> Michael
>>>>>=20
>>>>> So, I agree with Ted and Sal's sentiments. Fixing up our existing =
designs for existing deployments is definitely very valuable and =
hopefully inevitable, but it does not take away from the fact that QUIC =
is a clean protocol design that incorporates, as first principles, =
lessons learned from our collective past. Going forward, I expect there =
to be debates about which protocol is the best fit for an application, =
and I encourage that -- having real choice in transport protocols at =
design time and at run time is a wonderful thing, and it's long overdue.
>>>>>=20
>>>>> - jana
>>>>=20
>>>> _______________________________________________
>>>> QUIC mailing list
>>>> QUIC@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/quic
>>>>=20
>>>=20
>>> _______________________________________________
>>> QUIC mailing list
>>> QUIC@ietf.org
>>> https://www.ietf.org/mailman/listinfo/quic
>>=20
>> --------
>> Randall Stewart
>> rrs@netflix.com
>> 803-317-4952

--------
Randall Stewart
rrs@netflix.com
803-317-4952






--Apple-Mail=_7FCC08F5-EFF9-4115-B04E-38453FD02519
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On May 30, 2016, at 9:18 AM, Michael =
Tuexen <Michael.Tuexen@lurchi.fra=
nken.de> wrote:

On 30 May =
2016, at 13:48, Randall Stewart <rrs@netflix.com> =
wrote:

Michael:

See below..

On May 29, 2016, at =
11:28 AM, Michael Tuexen <Michael.Tuexen@lurchi.fra=
nken.de> wrote:

On 28 May 2016, at 18:15, Jim Roskind <JimRoskind@gmail.com> =
wrote:

re: "...results of experiments [done by] =
Google."

Publication of experiments done in/around QUIC should be =
a treasure trove for both QUIC and numerous other =
protocols.

Although not all-encompasing, I presented several of =
Google's experimental results to IETF-88 back in 2013.  Be sure to =
take a look at:

https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf=


Included in that IETF presentation (which I think was video =
recorded) were slides showing:

a) NAT Eviction probabilities vs =
time, for UDP bindings (slide 10)
b) Round-trip packet-loss =
probability for trains of paced vs unpaced packets of various sizes =
(slides 22 and 23)
c) Generic 0 vs 1 vs 2 FEC utility for paced and =
unpaced trains (slide 24)

All such experiments (and many more) =
need to be repeated and published over time, as the deployment of middle =
boxes, links (mobile variants vs non-mobile), routers, contemporaneous =
traffic patterns, etc. continue to evolve.

Item (a) showed the =
viability of a UDP based multi-packet protocol, with (then current) =
caveats that pauses in the stream beyond 30 seconds increase eviction =
rates. This drove QUIC to support handling of that progressive increase =
in eviction. There is some hope that upcoming IETF standardization in =
this area will further improve the NAT-eviction landscape, but that will =
certainly depend on vendors and deployment (market penetration) =
rates.

Item (b) showed the tremendous impact (value) of pacing, =
and also showed the remarkable vulnerability (i.e., increased loss =
probability) of the 2nd packet in a cold-connection. That surprising =
(previously unpublished?) 2nd-packet loss statistic was recently =
observed and verified to me verbally by a second vendor for a related =
UDP protocol just a month ago (May 2016) at a public presentation I =
gave. 

Item (c) =
better showed the nature of the packet loss correlation (and showed that =
loss should *not* be modeled by an independent identically distributed =
process.). It clearly showed the lack of marginal value of =
multiple-packet error recovery (i.e., 2-packet-loss FEC) for trains as =
long as 21 packets (which is a plausible congestion window for a lossy =
connection). The data also justified the significant utility of =
1-packet-loss FEC for such short windows (i.e., congestion window under =
21) with very latency sensitive transmissions (such as stream creation =
for small latency sensitive requests, including perchance =
advertisements). 

We deduced in 2011 =
that about 5-7% of all chrome clients had UDP blocked (from reaching =
Google) for even small packets, which is what drove the decision to have =
a TCP fallback plan in QUIC.  I believe that experimental =
deployment results for QUIC continued to support that 5-7% statistic, =
though I'm very hopeful that system administrators will change this =
blocking over time (for the better!).  I also look forward to =
ongoing publication of this statistic by Google.

Another Google =
published result is the fact that UDP payload sizes over 1350 bytes tend =
to be blocked more often, which was indeed the driving factor behind =
QUIC (initially) adopting a static payload size of 1350 bytes. 

I expect that =
experiments done by multiple vendors will be published.  I know =
that Firefox adopted Chrome's metrics gathering approach, and hopefully =
if/when an experimental QUIC implementation appears there, then =
additional results will continue to be published.
Hi =
Jim,

Thinking about this list in the broad =
sense..


summarising the above =
means:
1. Legacy NAT traversal (doable via UDP =
encapsulation)

I think with TCP this is not an =
issue, SCTP would have to be
like Quic and be wrapped in UDP I think =
that is already occurring
within rc-web=92s data channel =
:-)


2. Pacing

I =
think pacing can be done on any transport and in general is
a *good* =
thing. The one thing about pacing is that it tends to 
really hurt you in =
TSO/LRO (at least for TCP). I am currently working
on trying to come =
up with a method for pacing that does not loose
all the benefits of =
TSO but still gives us the desired =93paced=94 =
results.

3. =
FEC

This one I think for TCP would be a bit hard.. =
SCTP could in theory
do it.. I would be quite curious to know how =
much benefit is really
seen by this. I thought Ian mentioned to us at =
a past IETF that it
really helped in certain scenarios but how often =
does that occur
and what scenarios are they?  If google could =
share how often
they have this on and how much it helps in those =
cases that
would be interesting=85.

4.=
 Path MTU limit

I have noticed, in my TCP work, that =
PMTU discovery does become
painful at times.. and just having a fixed =
size makes life a lot easier.
Of course with IPSEC and IPv6 and other =
fun things 1350 bytes may even be
too big :-)

Then again I =
have heard arguments for keeping Time-Stamps off by default
due to =
the wasted size in the packet. Which makes me wonder, if we are
so =
concerned about the time-stamp size should we be concerned about
the =
extra bytes that we loose in a 1500 byte MTU? 

Its a shame too =
since time-stamps really make TCP (with PRR and RACK) much
more =
robust.. We only see 15% or so of connections that have SACK not 
doing Time-Stamps so =
its not too bad (I think thats due to the fact that most of
our =
clients are linux based which like FreeBSD and Mac turn time-stamp =
on
by default). Sack on the other hand I see in about 99.9% of all =
clients which
is way cool :-)

combined=
 with what Jana mentioned:
5. Fast connection =
setup

This I think can be done in both TCP and =
SCTP.. I would hope that
TLS 1.3 will gain that for all protocols =
that use it :-)

6. Improved loss =
recovery

I have actually been implementing RACK and =
PRR for TCP and am
beginning to see the same benefits in TCP that we =
have heard
about with Quic..  so these are very very useful =
things thats for sure :-)

7. CC =
agility

I can=92t speak for windows or MacOS .. but =
I think that both Linux and FreeBSD
have had this for many years =
now.. I know when I look in the cc for BSD there
are at least eight =
congestion control algorithms that are available and I am sure
Linux =
probably has more :)

8. Encryption of =
transport layer information

That does eliminate =
snooping middle boxes.. but some environments (such as
mobile) might =
not like that :-) 

I doubt you could =
easily do this with TCP or SCTP.. since middle boxes expect
packet =
formates to look a particular way. Anything new of course does =
not
have this issue.. possibly wrapping a protocol in UDP would gain =
you that though :-)


Did I miss =
anything?

Is multi-streaming missing from the list? =
I think it was mentioned in some
of the slides. We currently don=92t =
see any benefit in this, but we are not
loading multiple images for a =
web-page.. instead streaming a movie..
Ahh, yes. I =
missed that.

I would imagine our client =
teams during search for a movie might like this
but I would imagine =
they (like many web based things) open multiple connections.

One =
question I wonder (and this is for both Quic and SCTP) is the ability to =
do
LRO/TSO. I have found that one of our Caches which typically =
outputs about
36Gbps drops its speed in 1/2 if I ifconfig off =
TSO/LRO. When you pull the
Is this also true when you do =
non-hardware assisted TLS? If not, then this
features becomes less =
important when you consider a combined transport/security
layer as an =
entity=85


We =
actually do TLS encryption inside the kernel ahead of TSO. It is =
true
that we generally only send 16k at a time to TSO (the TLS =
record length) but this
does not seem to cause us to suffer =
too much.

How this all works can be found =
at:


and<=
/div>


<=
div>So though encryption is happening in the kernel we still can use =
TSO.. and do :-)

We have one particular machine =
that we get 80Gbps of encrypted traffic out of (our
newest =
flash cache :-D.. thanks to a whole *lot* of work from the NF OCA team =
:D)

R


Best =
regards
Michael
things into user space =
and encrypt it you loose the ability to do these functions.
I don=92t =
think SCTP has ever been able to do TSO/LRO as well..  Thats one =
big
impact to performance that needs to be thought about..

I =
would also like to see any new protocol implementable in the kernel as =
well. Currently
Quic uses a floating point number for time-stamps and =
that would be pretty heavy weight
for the kernel.. having a =
compatible integer equivalent would be something I think that is =
needed.

Best wishes

R



Best regards
Michael




On Sat, May 28, 2016 at 1:17 AM, Michael =
Tuexen <Michael.Tuexen@lurchi.fra=
nken.de> wrote:
On 28 May 2016, at =
04:30, Jana Iyengar <jri@google.com> wrote:

Hi =
Michael,

Are there any plans to analyse the requirements in a =
protocol independent
way and try to figure out if these requirements =
can also be met by evolving
one or more of the existing transport =
protocols (in combination with the appropriate
(D)TLS)? And then =
making a decision whether it is appropriate to
evolve existing =
protocols in addition to or instead of developing a new one...

I =
agree with you that the requirements of QUIC should be requirements for =
new protocols and for evolution of existing ones. The lessons of QUIC =
are expected to inform other transport work -- QUIC has provided inputs =
to TCP and TLS about the importance of avoiding handshake RTTs, and more =
recently, RACK (draft-cheng-tcpm-rack-00) is similar in spirit to QUIC's =
loss recovery.

Subsequent protocol work must learn QUIC's =
lessons, just as QUIC learned from its predecessors. While there's =
inevitably functional overlap between QUIC and any of {TCP, SCTP, MPTCP} =
(which have overlaps of their own), much of the work of QUIC has been in =
refining and tightly integrating mechanisms that we have learned from =
previous transports into a modern transport -- protection of data and =
headers, low latency-overhead, congestion-control agility, and strong =
loss-recovery, to name a few.
Hi Jana,

so these =
are some of the requirements, right? I'm wondering if it makes sense to =
provide such a list
of findings in a protocol independent way. What =
is important and what is not needs knowledge of the
results of the =
experiments Google where running.
Without such a description, it is =
hard for other groups to figure out if it is important to =
consider
integrating a specific feature of QUIC.

Best =
regards
Michael

So, I agree with Ted =
and Sal's sentiments. Fixing up our existing designs for existing =
deployments is definitely very valuable and hopefully inevitable, but it =
does not take away from the fact that QUIC is a clean protocol design =
that incorporates, as first principles, lessons learned from our =
collective past. Going forward, I expect there to be debates about which =
protocol is the best fit for an application, and I encourage that -- =
having real choice in transport protocols at design time and at run time =
is a wonderful thing, and it's long overdue.

- =
jana

_______________________________________________QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/quic


______________________________=
_________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/quic

--------
Randall =
Stewart
rrs@netflix.com
803-317-4952



--------
Randall Stewart
803-317-4952=









=

--Apple-Mail=_7FCC08F5-EFF9-4115-B04E-38453FD02519--


From nobody Mon May 30 19:54:53 2016
Return-Path: 
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 9155912B040 for ; Mon, 30 May 2016 19:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 onT1dNufJxCQ for ; Mon, 30 May 2016 19:54:49 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B1312D128 for ; Mon, 30 May 2016 19:54:48 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 34DF822E1FA for ; Mon, 30 May 2016 22:54:37 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 31 May 2016 12:54:35 +1000
References: <20160518001706.24865.86238.idtracker@ietfa.amsl.com>
To: quic@ietf.org
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [QUIC] Fwd: Last Call:  (UDP Usage Guidelines) to Best Current Practice
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 02:54:51 -0000

Apologies if I missed discussion about this.=20

If this is to be a BCP, is it safe to assume that a) it will apply to =
QUIC if chartered, and b) that folks here are comfortable with its =
requirements?

Cheers,



> Begin forwarded message:
>=20
> From: The IESG 
> Subject: Last Call:  (UDP Usage =
Guidelines) to Best Current Practice
> Date: 18 May 2016 at 10:17:06 AM AEST
> To: "IETF-Announce" 
> Cc: draft-ietf-tsvwg-rfc5405bis@ietf.org, tsvwg-chairs@ietf.org, =
tsvwg@ietf.org
> Reply-To: ietf@ietf.org
> Archived-At: =

>=20
>=20
> The IESG has received a request from the Transport Area Working Group =
WG
> (tsvwg) to consider the following document:
> - 'UDP Usage Guidelines'
>   as Best Current Practice
>=20
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2016-05-31. Exceptionally, comments may =
be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>=20
> Abstract
>=20
>=20
>   The User Datagram Protocol (UDP) provides a minimal message-passing
>   transport that has no inherent congestion control mechanisms.  This
>   document provides guidelines on the use of UDP for the designers of
>   applications, tunnels and other protocols that use UDP.  Congestion
>   control guidelines are a primary focus, but the document also
>   provides guidance on other topics, including message sizes,
>   reliability, checksums, middlebox traversal, the use of ECN, DSCPs,
>   and ports.
>=20
>   Because congestion control is critical to the stable operation of =
the
>   Internet, applications and other protocols that choose to use UDP as
>   an Internet transport must employ mechanisms to prevent congestion
>   collapse and to establish some degree of fairness with concurrent
>   traffic.  They may also need to implement additional mechanisms,
>   depending on how they use UDP.
>=20
>   Some guidance is also applicable to the design of other protocols
>   (e.g., protocols layered directly on IP or via IP-based tunnels),
>   especially when these protocols do not themselves provide congestion
>   control.
>=20
>   This document obsoletes RFC5405 and adds guidelines for multicast =
UDP
>   usage.
>=20
>=20
>=20
>=20
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/
>=20
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ballot/
>=20
>=20
> No IPR declarations have been submitted directly on this I-D.
>=20
>=20

--
Mark Nottingham   https://www.mnot.net/


From nobody Mon May 30 22:56:21 2016
Return-Path: 
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 E33CD12D666 for ; Mon, 30 May 2016 22:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 KrO9yE3Qew5q for ; Mon, 30 May 2016 22:56:15 -0700 (PDT)
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 5284C12D139 for ; Mon, 30 May 2016 22:56:15 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id h19so178958644ywc.0 for ; Mon, 30 May 2016 22:56:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4n8lZeHAPAY/4CvL9gYPx9Jk0r2JRIg75n13jbUqGAQ=; b=pRkI/KFdz7Cc6wYxknOYvhUG9flaGOBsFaIuOioW502G1m5zrlLDyKWOC3lmGVFXQY jtKFllNOudJIvqjBPw2PF3ChpcbKO6pol1RNijkKyFHetqG8V6Btfy4FRB43cZKJBxrF aSxQHyHooq6id0URvr65piVrvG8h72A2jTv6/hSk/qrVjuOHT8RkeH969Qr1HYxIs6JA ZrIp8FJl1RWJP7c+aTZ5prkBfCT9a2VCPGCBwIAu7xEthul/VsSAIQarFnluW0Rs1dDs haf5HuGmUWukuPkQNVva9QgWI4C6jOYygiOkek6SitCuNsQTgJeCckSS4EOanWfjLShs t48A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4n8lZeHAPAY/4CvL9gYPx9Jk0r2JRIg75n13jbUqGAQ=; b=mwyDZsAj9SZSEFFV18Iz03wCFtTNzv9ymE2kX3erYaAmXMsfrrFd6h2Er3ylCc8GLU J+J/BhTbaLbHo0eobBec0lmLDjz6bNSoYHzr96lB9ZevRsdGoDtRUAR/uAq9J9turTHC /GfdsqBDRUDBQ3kj+zZetIiCkwkaOaBiom8M7rp4MmMCCpZKdMdVh4jJlY6i+80/kOhj vliQEcX1Qe4nihGrCwM+k5+9P1nDxsFXhUfw4ecf1PxJQ0QQIYiiKfnb3ekbCGw5p71z TfF24gGv/mcX8d19w1uFbsEfjGRw/+Wzfhl2lHKHpIZixH0TVsUp8Deh2FOwC8gDvxcZ 9S9A==
X-Gm-Message-State: ALyK8tJ/plKZ52SgTx7hYuMyZwB5qtoZ9AKCyBU/QqS76z+u9cxsc0BNn4n9R/yMOBDFQHL1ocDWjKfVIUv0rEkN
X-Received: by 10.13.218.65 with SMTP id c62mr18815367ywe.36.1464674174336; Mon, 30 May 2016 22:56:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Mon, 30 May 2016 22:56:13 -0700 (PDT)
In-Reply-To: <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com>
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>  <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de>  <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com>  <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com>
From: Jana Iyengar 
Date: Mon, 30 May 2016 22:56:13 -0700
Message-ID: 
To: Randall Stewart 
Content-Type: multipart/alternative; boundary=94eb2c080508dfe2ee05341d07fb
Archived-At: 
Cc: =?UTF-8?Q?Michael_T=C3=BCxen?= , quic@ietf.org
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 05:56:19 -0000

--94eb2c080508dfe2ee05341d07fb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Michael, Randall,

In general, I'd agree with some of these, but I don't want to get into the
details here since I am not sure what the point of this exercise is at the
moment.

I think we are in agreement that doing a clean-slate design allows us to
build a transport with lessons we've learned so far as first principles.
This is the opportunity we as a community have right now. I think many of
these can be retrofit into SCTP (or into TCP), but some may have to be
coerced, and some others may either be impossible or require significant
surgery. We would only know by trying, and I encourage that work.

Perhaps a list of features that can be added to TCP can be discussed on
TCPM, and similarly to SCTP on TSVWG. I'd be happy to chime in on those
threads.

- jana


On Mon, May 30, 2016 at 6:22 AM, Randall Stewart  wrote:

>
> On May 30, 2016, at 9:18 AM, Michael Tuexen <
> Michael.Tuexen@lurchi.franken.de> wrote:
>
> On 30 May 2016, at 13:48, Randall Stewart  wrote:
>
> Michael:
>
> See below..
>
> On May 29, 2016, at 11:28 AM, Michael Tuexen <
> Michael.Tuexen@lurchi.franken.de> wrote:
>
> On 28 May 2016, at 18:15, Jim Roskind  wrote:
>
> re: "...results of experiments [done by] Google."
>
> Publication of experiments done in/around QUIC should be a treasure trove
> for both QUIC and numerous other protocols.
>
> Although not all-encompasing, I presented several of Google's experimenta=
l
> results to IETF-88 back in 2013.  Be sure to take a look at:
>
> https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf
>
> Included in that IETF presentation (which I think was video recorded) wer=
e
> slides showing:
>
> a) NAT Eviction probabilities vs time, for UDP bindings (slide 10)
> b) Round-trip packet-loss probability for trains of paced vs unpaced
> packets of various sizes (slides 22 and 23)
> c) Generic 0 vs 1 vs 2 FEC utility for paced and unpaced trains (slide 24=
)
>
> All such experiments (and many more) need to be repeated and published
> over time, as the deployment of middle boxes, links (mobile variants vs
> non-mobile), routers, contemporaneous traffic patterns, etc. continue to
> evolve.
>
> Item (a) showed the viability of a UDP based multi-packet protocol, with
> (then current) caveats that pauses in the stream beyond 30 seconds increa=
se
> eviction rates. This drove QUIC to support handling of that progressive
> increase in eviction. There is some hope that upcoming IETF standardizati=
on
> in this area will further improve the NAT-eviction landscape, but that wi=
ll
> certainly depend on vendors and deployment (market penetration) rates.
>
> Item (b) showed the tremendous impact (value) of pacing, and also showed
> the remarkable vulnerability (i.e., increased loss probability) of the 2n=
d
> packet in a cold-connection. That surprising (previously unpublished?)
> 2nd-packet loss statistic was recently observed and verified to me verbal=
ly
> by a second vendor for a related UDP protocol just a month ago (May 2016)
> at a public presentation I gave.
>
> Item (c) better showed the nature of the packet loss correlation (and
> showed that loss should *not* be modeled by an independent identically
> distributed process.). It clearly showed the lack of marginal value of
> multiple-packet error recovery (i.e., 2-packet-loss FEC) for trains as lo=
ng
> as 21 packets (which is a plausible congestion window for a lossy
> connection). The data also justified the significant utility of
> 1-packet-loss FEC for such short windows (i.e., congestion window under 2=
1)
> with very latency sensitive transmissions (such as stream creation for
> small latency sensitive requests, including perchance advertisements).
>
> We deduced in 2011 that about 5-7% of all chrome clients had UDP blocked
> (from reaching Google) for even small packets, which is what drove the
> decision to have a TCP fallback plan in QUIC.  I believe that experimenta=
l
> deployment results for QUIC continued to support that 5-7% statistic,
> though I'm very hopeful that system administrators will change this
> blocking over time (for the better!).  I also look forward to ongoing
> publication of this statistic by Google.
>
> Another Google published result is the fact that UDP payload sizes over
> 1350 bytes tend to be blocked more often, which was indeed the driving
> factor behind QUIC (initially) adopting a static payload size of 1350 byt=
es.
>
>
> I expect that experiments done by multiple vendors will be published.  I
> know that Firefox adopted Chrome's metrics gathering approach, and
> hopefully if/when an experimental QUIC implementation appears there, then
> additional results will continue to be published.
>
> Hi Jim,
>
>
> Thinking about this list in the broad sense..
>
>
> summarising the above means:
> 1. Legacy NAT traversal (doable via UDP encapsulation)
>
>
> I think with TCP this is not an issue, SCTP would have to be
> like Quic and be wrapped in UDP I think that is already occurring
> within rc-web=E2=80=99s data channel :-)
>
>
> 2. Pacing
>
>
> I think pacing can be done on any transport and in general is
> a *good* thing. The one thing about pacing is that it tends to
> really hurt you in TSO/LRO (at least for TCP). I am currently working
> on trying to come up with a method for pacing that does not loose
> all the benefits of TSO but still gives us the desired =E2=80=9Cpaced=E2=
=80=9D results.
>
> 3. FEC
>
>
> This one I think for TCP would be a bit hard.. SCTP could in theory
> do it.. I would be quite curious to know how much benefit is really
> seen by this. I thought Ian mentioned to us at a past IETF that it
> really helped in certain scenarios but how often does that occur
> and what scenarios are they?  If google could share how often
> they have this on and how much it helps in those cases that
> would be interesting=E2=80=A6.
>
> 4. Path MTU limit
>
>
> I have noticed, in my TCP work, that PMTU discovery does become
> painful at times.. and just having a fixed size makes life a lot easier.
> Of course with IPSEC and IPv6 and other fun things 1350 bytes may even be
> too big :-)
>
> Then again I have heard arguments for keeping Time-Stamps off by default
> due to the wasted size in the packet. Which makes me wonder, if we are
> so concerned about the time-stamp size should we be concerned about
> the extra bytes that we loose in a 1500 byte MTU?
>
> Its a shame too since time-stamps really make TCP (with PRR and RACK) muc=
h
> more robust.. We only see 15% or so of connections that have SACK not
> doing Time-Stamps so its not too bad (I think thats due to the fact that
> most of
> our clients are linux based which like FreeBSD and Mac turn time-stamp on
> by default). Sack on the other hand I see in about 99.9% of all clients
> which
> is way cool :-)
>
> combined with what Jana mentioned:
> 5. Fast connection setup
>
>
> This I think can be done in both TCP and SCTP.. I would hope that
> TLS 1.3 will gain that for all protocols that use it :-)
>
> 6. Improved loss recovery
>
>
> I have actually been implementing RACK and PRR for TCP and am
> beginning to see the same benefits in TCP that we have heard
> about with Quic..  so these are very very useful things thats for sure :-=
)
>
> 7. CC agility
>
>
> I can=E2=80=99t speak for windows or MacOS .. but I think that both Linux=
 and
> FreeBSD
> have had this for many years now.. I know when I look in the cc for BSD
> there
> are at least eight congestion control algorithms that are available and I
> am sure
> Linux probably has more :)
>
> 8. Encryption of transport layer information
>
>
> That does eliminate snooping middle boxes.. but some environments (such a=
s
> mobile) might not like that :-)
>
> I doubt you could easily do this with TCP or SCTP.. since middle boxes
> expect
> packet formates to look a particular way. Anything new of course does not
> have this issue.. possibly wrapping a protocol in UDP would gain you that
> though :-)
>
>
> Did I miss anything?
>
>
> Is multi-streaming missing from the list? I think it was mentioned in som=
e
> of the slides. We currently don=E2=80=99t see any benefit in this, but we=
 are not
> loading multiple images for a web-page.. instead streaming a movie..
>
> Ahh, yes. I missed that.
>
>
> I would imagine our client teams during search for a movie might like thi=
s
> but I would imagine they (like many web based things) open multiple
> connections.
>
> One question I wonder (and this is for both Quic and SCTP) is the ability
> to do
> LRO/TSO. I have found that one of our Caches which typically outputs abou=
t
> 36Gbps drops its speed in 1/2 if I ifconfig off TSO/LRO. When you pull th=
e
>
> Is this also true when you do non-hardware assisted TLS? If not, then thi=
s
> features becomes less important when you consider a combined
> transport/security
> layer as an entity=E2=80=A6
>
>
>
> We actually do TLS encryption inside the kernel ahead of TSO. It is true
> that we generally only send 16k at a time to TSO (the TLS record length)
> but this
> does not seem to cause us to suffer too much.
>
> How this all works can be found at:
>
> https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf
>
> and
>
> https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf
>
> So though encryption is happening in the kernel we still can use TSO.. an=
d
> do :-)
>
> We have one particular machine that we get 80Gbps of encrypted traffic ou=
t
> of (our
> newest flash cache :-D.. thanks to a whole *lot* of work from the NF OCA
> team :D)
>
> R
>
>
> Best regards
> Michael
>
> things into user space and encrypt it you loose the ability to do these
> functions.
> I don=E2=80=99t think SCTP has ever been able to do TSO/LRO as well..  Th=
ats one
> big
> impact to performance that needs to be thought about..
>
> I would also like to see any new protocol implementable in the kernel as
> well. Currently
> Quic uses a floating point number for time-stamps and that would be prett=
y
> heavy weight
> for the kernel.. having a compatible integer equivalent would be somethin=
g
> I think that is needed.
>
> Best wishes
>
> R
>
>
>
> Best regards
> Michael
>
>
>
>
>
> On Sat, May 28, 2016 at 1:17 AM, Michael Tuexen <
> Michael.Tuexen@lurchi.franken.de> wrote:
>
> On 28 May 2016, at 04:30, Jana Iyengar  wrote:
>
> Hi Michael,
>
> Are there any plans to analyse the requirements in a protocol independent
> way and try to figure out if these requirements can also be met by evolvi=
ng
> one or more of the existing transport protocols (in combination with the
> appropriate
> (D)TLS)? And then making a decision whether it is appropriate to
> evolve existing protocols in addition to or instead of developing a new
> one...
>
> I agree with you that the requirements of QUIC should be requirements for
> new protocols and for evolution of existing ones. The lessons of QUIC are
> expected to inform other transport work -- QUIC has provided inputs to TC=
P
> and TLS about the importance of avoiding handshake RTTs, and more recentl=
y,
> RACK (draft-cheng-tcpm-rack-00) is similar in spirit to QUIC's loss
> recovery.
>
> Subsequent protocol work must learn QUIC's lessons, just as QUIC learned
> from its predecessors. While there's inevitably functional overlap betwee=
n
> QUIC and any of {TCP, SCTP, MPTCP} (which have overlaps of their own), mu=
ch
> of the work of QUIC has been in refining and tightly integrating mechanis=
ms
> that we have learned from previous transports into a modern transport --
> protection of data and headers, low latency-overhead, congestion-control
> agility, and strong loss-recovery, to name a few.
>
> Hi Jana,
>
> so these are some of the requirements, right? I'm wondering if it makes
> sense to provide such a list
> of findings in a protocol independent way. What is important and what is
> not needs knowledge of the
> results of the experiments Google where running.
> Without such a description, it is hard for other groups to figure out if
> it is important to consider
> integrating a specific feature of QUIC.
>
> Best regards
> Michael
>
>
> So, I agree with Ted and Sal's sentiments. Fixing up our existing designs
> for existing deployments is definitely very valuable and hopefully
> inevitable, but it does not take away from the fact that QUIC is a clean
> protocol design that incorporates, as first principles, lessons learned
> from our collective past. Going forward, I expect there to be debates abo=
ut
> which protocol is the best fit for an application, and I encourage that -=
-
> having real choice in transport protocols at design time and at run time =
is
> a wonderful thing, and it's long overdue.
>
> - jana
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>
> --------
> Randall Stewart
> rrs@netflix.com
> 803-317-4952
>
>
> --------
> Randall Stewart
> rrs@netflix.com
> 803-317-4952
>
>
>
>
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>

--94eb2c080508dfe2ee05341d07fb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Michael, Randall,

In general, I'd a=
gree with some of these, but I don't want to get into the details here =
since I am not sure what the point of this exercise is at the moment.
=


I think we are in agreement that doing a clean-slate de=
sign allows us to build a transport with lessons we've learned so far a=
s first principles. This is the opportunity we as a community have right no=
w. I think many of these can be retrofit into SCTP (or into TCP), but some =
may have to be coerced, and some others may either be impossible or require=
 significant surgery. We would only know by trying, and I encourage that wo=
rk.

Perhaps a list of features that can be added t=
o TCP can be discussed on TCPM, and similarly to SCTP on TSVWG. I'd be =
happy to chime in on those threads.

- jana


On Mon, May 30, 2016 at 6:22 AM, Randall Stewart <rrs@netflix.com><=
/span> wrote:

On May 30, 2016, at 9:18 AM, =
Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:

=
On 30 May 2016, at 13:48, Randall Stewart <rrs@netflix.com> wrote:

Michael:
<=
br>See below..

On May 29, 2016, at 11:28 AM, Michael Tuexen <Michael.T=
uexen@lurchi.franken.de> wrote:

On 28 May 2016, at 18:15, Jim Roskind <JimRoskind@gmail.com>=
; wrote:

re: "...results of experiments [done by] Google."=


Publication of experiments done in/around QUIC should be a treasure=
 trove for both QUIC and numerous other protocols.

Although not all-=
encompasing, I presented several of Google's experimental results to IE=
TF-88 back in 2013.=C2=A0 Be sure to take a look at:

https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf=


Included in that IETF presentation (which I think was video rec=
orded) were slides showing:

a) NAT Eviction probabilities vs time, f=
or UDP bindings (slide 10)
b) Round-trip packet-loss probability for tra=
ins of paced vs unpaced packets of various sizes (slides 22 and 23)
c) G=
eneric 0 vs 1 vs 2 FEC utility for paced and unpaced trains (slide 24)
<=
br>All such experiments (and many more) need to be repeated and published o=
ver time, as the deployment of middle boxes, links (mobile variants vs non-=
mobile), routers, contemporaneous traffic patterns, etc. continue to evolve=
.

Item (a) showed the viability of a UDP based multi-packet protocol=
, with (then current) caveats that pauses in the stream beyond 30 seconds i=
ncrease eviction rates. This drove QUIC to support handling of that progres=
sive increase in eviction. There is some hope that upcoming IETF standardiz=
ation in this area will further improve the NAT-eviction landscape, but tha=
t will certainly depend on vendors and deployment (market penetration) rate=
s.

Item (b) showed the tremendous impact (value) of pacing, and also=
 showed the remarkable vulnerability (i.e., increased loss probability) of =
the 2nd packet in a cold-connection. That surprising (previously unpublishe=
d?) 2nd-packet loss statistic was recently observed and verified to me verb=
ally by a second vendor for a related UDP protocol just a month ago (May 20=
16) at a public presentation I gave.=C2=A0

Item (c) bet=
ter showed the nature of the packet loss correlation (and showed that loss =
should *not* be modeled by an independent identically distributed process.)=
. It clearly showed the lack of marginal value of multiple-packet error rec=
overy (i.e., 2-packet-loss FEC) for trains as long as 21 packets (which is =
a plausible congestion window for a lossy connection). The data also justif=
ied the significant utility of 1-packet-loss FEC for such short windows (i.=
e., congestion window under 21) with very latency sensitive transmissions (=
such as stream creation for small latency sensitive requests, including per=
chance advertisements).=C2=A0

We deduced in 2011 that a=
bout 5-7% of all chrome clients had UDP blocked (from reaching Google) for =
even small packets, which is what drove the decision to have a TCP fallback=
 plan in QUIC.=C2=A0 I believe that experimental deployment results for QUI=
C continued to support that 5-7% statistic, though I'm very hopeful tha=
t system administrators will change this blocking over time (for the better=
!).=C2=A0 I also look forward to ongoing publication of this statistic by G=
oogle.

Another Google published result is the fact that UDP payload =
sizes over 1350 bytes tend to be blocked more often, which was indeed the d=
riving factor behind QUIC (initially) adopting a static payload size of 135=
0 bytes.=C2=A0

I expect that experiments done by multip=
le vendors will be published.=C2=A0 I know that Firefox adopted Chrome'=
s metrics gathering approach, and hopefully if/when an experimental QUIC im=
plementation appears there, then additional results will continue to be pub=
lished.
Hi Jim,

Thinking about this lis=
t in the broad sense..


summarising the=
 above means:
1. Legacy NAT traversal (doable via UDP encapsulation)
=


I think with TCP this is not an issue, SCTP would have to =
be
like Quic and be wrapped in UDP I think that is already occurring
=
within rc-web=E2=80=99s data channel :-)


2. Pacing

I think pacing can be done on any transpor=
t and in general is
a *good* thing. The one thing about pacing is that i=
t tends to=C2=A0
really hurt you in TSO/LRO (at least for T=
CP). I am currently working
on trying to come up with a method for pacin=
g that does not loose
all the benefits of TSO but still gives us the des=
ired =E2=80=9Cpaced=E2=80=9D results.

3. F=
EC

This one I think for TCP would be a bit hard.. SCTP =
could in theory
do it.. I would be quite curious to know how much benefi=
t is really
seen by this. I thought Ian mentioned to us at a past IETF t=
hat it
really helped in certain scenarios but how often does that occur<=
br>and what scenarios are they?=C2=A0 If google could share how often
th=
ey have this on and how much it helps in those cases that
would be inter=
esting=E2=80=A6.

4. Path MTU limit

I have noticed, in my TCP work, that PMTU discovery does becom=
e
painful at times.. and just having a fixed size makes life a lot easie=
r.
Of course with IPSEC and IPv6 and other fun things 1350 bytes may eve=
n be
too big :-)

Then again I have heard arguments for keeping Ti=
me-Stamps off by default
due to the wasted size in the packet. Which mak=
es me wonder, if we are
so concerned about the time-stamp size should we=
 be concerned about
the extra bytes that we loose in a 1500 byte MTU?=C2=A0

Its a shame too since time-stamps really make TCP (=
with PRR and RACK) much
more robust.. We only see 15% or so of connectio=
ns that have SACK not=C2=A0
doing Time-Stamps so its not to=
o bad (I think thats due to the fact that most of
our clients are linux =
based which like FreeBSD and Mac turn time-stamp on
by default). Sack on=
 the other hand I see in about 99.9% of all clients which
is way cool :-=
)

combined with what Jana mentioned:
5.=
 Fast connection setup

This I think can be done in both=
 TCP and SCTP.. I would hope that
TLS 1.3 will gain that for all protoco=
ls that use it :-)

6. Improved loss recove=
ry

I have actually been implementing RACK and PRR for T=
CP and am
beginning to see the same benefits in TCP that we have heardabout with Quic.. =C2=A0so these are very very useful things thats for su=
re :-)

7. CC agility

I=
 can=E2=80=99t speak for windows or MacOS .. but I think that both Linux an=
d FreeBSD
have had this for many years now.. I know when I look in the c=
c for BSD there
are at least eight congestion control algorithms that ar=
e available and I am sure
Linux probably has more :)

8. Encryption of transport layer information
=

That does eliminate snooping middle boxes.. but some environments (such=
 as
mobile) might not like that :-)=C2=A0

I doubt yo=
u could easily do this with TCP or SCTP.. since middle boxes expect
pack=
et formates to look a particular way. Anything new of course does not
ha=
ve this issue.. possibly wrapping a protocol in UDP would gain you that tho=
ugh :-)


Did I miss anything?

Is multi-streaming missing from the list? I think it was mention=
ed in some
of the slides. We currently don=E2=80=99t see any benefit in =
this, but we are not
loading multiple images for a web-page.. instead st=
reaming a movie..
Ahh, yes. I missed that.

I would imagine our client teams during search for a movie=
 might like this
but I would imagine they (like many web based things) o=
pen multiple connections.

One question I wonder (and this is for bot=
h Quic and SCTP) is the ability to do
LRO/TSO. I have found that one of =
our Caches which typically outputs about
36Gbps drops its speed in 1/2 i=
f I ifconfig off TSO/LRO. When you pull the
Is this also tr=
ue when you do non-hardware assisted TLS? If not, then this
features bec=
omes less important when you consider a combined transport/security
layer as an entity=E2=80=A6

<=
br>
We actually do TLS encryption inside the kernel ahead of TSO.=
 It is true
that we generally only send 16k at a time to TSO (the=
 TLS record length) but this
does not seem to cause us to suffer =
too much.

How this all works can be found at:


and

So though encryption is happening in the kernel we still can u=
se TSO.. and do :-)

We have one particular machine=
 that we get 80Gbps of encrypted traffic out of (our
newest flash=
 cache :-D.. thanks to a whole *lot* of work from the NF OCA team :D)
=


R
<=
/font>


Best regards<=
br>Michael
things into user space and encrypt =
it you loose the ability to do these functions.
I don=E2=80=99t think SC=
TP has ever been able to do TSO/LRO as well..=C2=A0 Thats one big
impact=
 to performance that needs to be thought about..

I would also like t=
o see any new protocol implementable in the kernel as well. Currently
Qu=
ic uses a floating point number for time-stamps and that would be pretty he=
avy weight
for the kernel.. having a compatible integer equivalent would=
 be something I think that is needed.

Best wishes

R


Best regards
Michael




On Sat, May 28, 2016 at 1:17 AM, Michael Tuexen &=
lt;Mi=
chael.Tuexen@lurchi.franken.de> wrote:
=
On 28 May 2016, at 04:30, Jana Iyengar <jri@google.com> wrote:

Hi Michael,
Are there any plans to analyse the requirements in a protocol independent<=
br>way and try to figure out if these requirements can also be met by evolv=
ing
one or more of the existing transport protocols (in combination with=
 the appropriate
(D)TLS)? And then making a decision whether it is appro=
priate to
evolve existing protocols in addition to or instead of develop=
ing a new one...

I agree with you that the requirements of QUIC shou=
ld be requirements for new protocols and for evolution of existing ones. Th=
e lessons of QUIC are expected to inform other transport work -- QUIC has p=
rovided inputs to TCP and TLS about the importance of avoiding handshake RT=
Ts, and more recently, RACK (draft-cheng-tcpm-rack-00) is similar in spirit=
 to QUIC's loss recovery.

Subsequent protocol work must learn QU=
IC's lessons, just as QUIC learned from its predecessors. While there&#=
39;s inevitably functional overlap between QUIC and any of {TCP, SCTP, MPTC=
P} (which have overlaps of their own), much of the work of QUIC has been in=
 refining and tightly integrating mechanisms that we have learned from prev=
ious transports into a modern transport -- protection of data and headers, =
low latency-overhead, congestion-control agility, and strong loss-recovery,=
 to name a few.
Hi Jana,

so these are some of the re=
quirements, right? I'm wondering if it makes sense to provide such a li=
st
of findings in a protocol independent way. What is important and what=
 is not needs knowledge of the
results of the experiments Google where r=
unning.
Without such a description, it is hard for other groups to figur=
e out if it is important to consider
integrating a specific feature of Q=
UIC.

Best regards
Michael

So, I =
agree with Ted and Sal's sentiments. Fixing up our existing designs for=
 existing deployments is definitely very valuable and hopefully inevitable,=
 but it does not take away from the fact that QUIC is a clean protocol desi=
gn that incorporates, as first principles, lessons learned from our collect=
ive past. Going forward, I expect there to be debates about which protocol =
is the best fit for an application, and I encourage that -- having real cho=
ice in transport protocols at design time and at run time is a wonderful th=
ing, and it's long overdue.

- jana

_________=
______________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.=
org/mailman/listinfo/quic


_____________________=
__________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/=
listinfo/quic

--------
Randall Stewart
rrs@netflix.com
803-317-49=
52



--------
Randall Stewart
rrs@netflix.com=










_______________________________________________
QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--94eb2c080508dfe2ee05341d07fb--


From nobody Tue May 31 02:38:40 2016
Return-Path: 
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 D52AF12D6C2 for ; Tue, 31 May 2016 02:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.027
X-Spam-Level: 
X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 d1aB7LF8zTqe for ; Tue, 31 May 2016 02:38:36 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBB512D6B2 for ; Tue, 31 May 2016 02:38:35 -0700 (PDT)
Received: from [192.168.1.100] (p508F01C0.dip0.t-ipconnect.de [80.143.1.192]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id BE679721E2822; Tue, 31 May 2016 11:38:26 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Tuexen 
In-Reply-To: 
Date: Tue, 31 May 2016 11:38:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F18220C-880D-4CD8-B8B6-293344094E82@lurchi.franken.de>
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>  <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de>  <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com>  <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> 
To: Jana Iyengar 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: quic@ietf.org, Randall Stewart 
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 09:38:40 -0000

> On 31 May 2016, at 07:56, Jana Iyengar  wrote:
>=20
> Michael, Randall,
>=20
> In general, I'd agree with some of these, but I don't want to get into =
the details here since I am not sure what the point of this exercise is =
at the moment.
I'm trying to figure out if one could evolve TCP or SCTP in combination =
with (D)TLS to get a similar
performing protocol.
>=20
> I think we are in agreement that doing a clean-slate design allows us =
to build a transport with lessons we've learned so far as first =
principles. This is the opportunity we as a community have right now. I =
think many of these can be retrofit into SCTP (or into TCP), but some =
may have to be coerced, and some others may either be impossible or =
require significant surgery. We would only know by trying, and I =
encourage that work.
And this is what I'm trying to figure out. How hard is it to evolve =
either TCP or SCTP. =46rom a deployment point of
view you want to support userland stacks, which requires UDP =
encapsulation. But that is defined for SCTP and even
could be done for TCP. The other points on the list are protocol =
features which would need evolving the protocols.
>=20
> Perhaps a list of features that can be added to TCP can be discussed =
on TCPM, and similarly to SCTP on TSVWG. I'd be happy to chime in on =
those threads.
I'm currently trying to figure out how such a list might look like.

Best regards
Michael
>=20
> - jana
>=20
>=20
> On Mon, May 30, 2016 at 6:22 AM, Randall Stewart  =
wrote:
>=20
> On May 30, 2016, at 9:18 AM, Michael Tuexen =
 wrote:
>=20
>>> On 30 May 2016, at 13:48, Randall Stewart  wrote:
>>>=20
>>> Michael:
>>>=20
>>> See below..
>>>=20
>>> On May 29, 2016, at 11:28 AM, Michael Tuexen =
 wrote:
>>>=20
>>>>> On 28 May 2016, at 18:15, Jim Roskind  =
wrote:
>>>>>=20
>>>>> re: "...results of experiments [done by] Google."
>>>>>=20
>>>>> Publication of experiments done in/around QUIC should be a =
treasure trove for both QUIC and numerous other protocols.
>>>>>=20
>>>>> Although not all-encompasing, I presented several of Google's =
experimental results to IETF-88 back in 2013.  Be sure to take a look =
at:
>>>>>=20
>>>>> =
https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf
>>>>>=20
>>>>> Included in that IETF presentation (which I think was video =
recorded) were slides showing:
>>>>>=20
>>>>> a) NAT Eviction probabilities vs time, for UDP bindings (slide 10)
>>>>> b) Round-trip packet-loss probability for trains of paced vs =
unpaced packets of various sizes (slides 22 and 23)
>>>>> c) Generic 0 vs 1 vs 2 FEC utility for paced and unpaced trains =
(slide 24)
>>>>>=20
>>>>> All such experiments (and many more) need to be repeated and =
published over time, as the deployment of middle boxes, links (mobile =
variants vs non-mobile), routers, contemporaneous traffic patterns, etc. =
continue to evolve.
>>>>>=20
>>>>> Item (a) showed the viability of a UDP based multi-packet =
protocol, with (then current) caveats that pauses in the stream beyond =
30 seconds increase eviction rates. This drove QUIC to support handling =
of that progressive increase in eviction. There is some hope that =
upcoming IETF standardization in this area will further improve the =
NAT-eviction landscape, but that will certainly depend on vendors and =
deployment (market penetration) rates.
>>>>>=20
>>>>> Item (b) showed the tremendous impact (value) of pacing, and also =
showed the remarkable vulnerability (i.e., increased loss probability) =
of the 2nd packet in a cold-connection. That surprising (previously =
unpublished?) 2nd-packet loss statistic was recently observed and =
verified to me verbally by a second vendor for a related UDP protocol =
just a month ago (May 2016) at a public presentation I gave.=20
>>>>>=20
>>>>> Item (c) better showed the nature of the packet loss correlation =
(and showed that loss should *not* be modeled by an independent =
identically distributed process.). It clearly showed the lack of =
marginal value of multiple-packet error recovery (i.e., 2-packet-loss =
FEC) for trains as long as 21 packets (which is a plausible congestion =
window for a lossy connection). The data also justified the significant =
utility of 1-packet-loss FEC for such short windows (i.e., congestion =
window under 21) with very latency sensitive transmissions (such as =
stream creation for small latency sensitive requests, including =
perchance advertisements).=20
>>>>>=20
>>>>> We deduced in 2011 that about 5-7% of all chrome clients had UDP =
blocked (from reaching Google) for even small packets, which is what =
drove the decision to have a TCP fallback plan in QUIC.  I believe that =
experimental deployment results for QUIC continued to support that 5-7% =
statistic, though I'm very hopeful that system administrators will =
change this blocking over time (for the better!).  I also look forward =
to ongoing publication of this statistic by Google.
>>>>>=20
>>>>> Another Google published result is the fact that UDP payload sizes =
over 1350 bytes tend to be blocked more often, which was indeed the =
driving factor behind QUIC (initially) adopting a static payload size of =
1350 bytes.=20
>>>>>=20
>>>>> I expect that experiments done by multiple vendors will be =
published.  I know that Firefox adopted Chrome's metrics gathering =
approach, and hopefully if/when an experimental QUIC implementation =
appears there, then additional results will continue to be published.
>>>> Hi Jim,
>>>=20
>>> Thinking about this list in the broad sense..
>>>=20
>>>>=20
>>>> summarising the above means:
>>>> 1. Legacy NAT traversal (doable via UDP encapsulation)
>>>=20
>>> I think with TCP this is not an issue, SCTP would have to be
>>> like Quic and be wrapped in UDP I think that is already occurring
>>> within rc-web=E2=80=99s data channel :-)
>>>=20
>>>=20
>>>> 2. Pacing
>>>=20
>>> I think pacing can be done on any transport and in general is
>>> a *good* thing. The one thing about pacing is that it tends to=20
>>> really hurt you in TSO/LRO (at least for TCP). I am currently =
working
>>> on trying to come up with a method for pacing that does not loose
>>> all the benefits of TSO but still gives us the desired =E2=80=9Cpaced=E2=
=80=9D results.
>>>=20
>>>> 3. FEC
>>>=20
>>> This one I think for TCP would be a bit hard.. SCTP could in theory
>>> do it.. I would be quite curious to know how much benefit is really
>>> seen by this. I thought Ian mentioned to us at a past IETF that it
>>> really helped in certain scenarios but how often does that occur
>>> and what scenarios are they?  If google could share how often
>>> they have this on and how much it helps in those cases that
>>> would be interesting=E2=80=A6.
>>>=20
>>>> 4. Path MTU limit
>>>=20
>>> I have noticed, in my TCP work, that PMTU discovery does become
>>> painful at times.. and just having a fixed size makes life a lot =
easier.
>>> Of course with IPSEC and IPv6 and other fun things 1350 bytes may =
even be
>>> too big :-)
>>>=20
>>> Then again I have heard arguments for keeping Time-Stamps off by =
default
>>> due to the wasted size in the packet. Which makes me wonder, if we =
are
>>> so concerned about the time-stamp size should we be concerned about
>>> the extra bytes that we loose in a 1500 byte MTU?=20
>>>=20
>>> Its a shame too since time-stamps really make TCP (with PRR and =
RACK) much
>>> more robust.. We only see 15% or so of connections that have SACK =
not=20
>>> doing Time-Stamps so its not too bad (I think thats due to the fact =
that most of
>>> our clients are linux based which like FreeBSD and Mac turn =
time-stamp on
>>> by default). Sack on the other hand I see in about 99.9% of all =
clients which
>>> is way cool :-)
>>>=20
>>>> combined with what Jana mentioned:
>>>> 5. Fast connection setup
>>>=20
>>> This I think can be done in both TCP and SCTP.. I would hope that
>>> TLS 1.3 will gain that for all protocols that use it :-)
>>>=20
>>>> 6. Improved loss recovery
>>>=20
>>> I have actually been implementing RACK and PRR for TCP and am
>>> beginning to see the same benefits in TCP that we have heard
>>> about with Quic..  so these are very very useful things thats for =
sure :-)
>>>=20
>>>> 7. CC agility
>>>=20
>>> I can=E2=80=99t speak for windows or MacOS .. but I think that both =
Linux and FreeBSD
>>> have had this for many years now.. I know when I look in the cc for =
BSD there
>>> are at least eight congestion control algorithms that are available =
and I am sure
>>> Linux probably has more :)
>>>=20
>>>> 8. Encryption of transport layer information
>>>=20
>>> That does eliminate snooping middle boxes.. but some environments =
(such as
>>> mobile) might not like that :-)=20
>>>=20
>>> I doubt you could easily do this with TCP or SCTP.. since middle =
boxes expect
>>> packet formates to look a particular way. Anything new of course =
does not
>>> have this issue.. possibly wrapping a protocol in UDP would gain you =
that though :-)
>>>=20
>>>>=20
>>>> Did I miss anything?
>>>=20
>>> Is multi-streaming missing from the list? I think it was mentioned =
in some
>>> of the slides. We currently don=E2=80=99t see any benefit in this, =
but we are not
>>> loading multiple images for a web-page.. instead streaming a movie..
>> Ahh, yes. I missed that.
>>>=20
>>> I would imagine our client teams during search for a movie might =
like this
>>> but I would imagine they (like many web based things) open multiple =
connections.
>>>=20
>>> One question I wonder (and this is for both Quic and SCTP) is the =
ability to do
>>> LRO/TSO. I have found that one of our Caches which typically outputs =
about
>>> 36Gbps drops its speed in 1/2 if I ifconfig off TSO/LRO. When you =
pull the
>> Is this also true when you do non-hardware assisted TLS? If not, then =
this
>> features becomes less important when you consider a combined =
transport/security
>> layer as an entity=E2=80=A6
>=20
>=20
> We actually do TLS encryption inside the kernel ahead of TSO. It is =
true
> that we generally only send 16k at a time to TSO (the TLS record =
length) but this
> does not seem to cause us to suffer too much.
>=20
> How this all works can be found at:
>=20
> https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf
>=20
> and
>=20
> https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf
>=20
> So though encryption is happening in the kernel we still can use TSO.. =
and do :-)
>=20
> We have one particular machine that we get 80Gbps of encrypted traffic =
out of (our
> newest flash cache :-D.. thanks to a whole *lot* of work from the NF =
OCA team :D)
>=20
> R
>=20
>>=20
>> Best regards
>> Michael
>>> things into user space and encrypt it you loose the ability to do =
these functions.
>>> I don=E2=80=99t think SCTP has ever been able to do TSO/LRO as =
well..  Thats one big
>>> impact to performance that needs to be thought about..
>>>=20
>>> I would also like to see any new protocol implementable in the =
kernel as well. Currently
>>> Quic uses a floating point number for time-stamps and that would be =
pretty heavy weight
>>> for the kernel.. having a compatible integer equivalent would be =
something I think that is needed.
>>>=20
>>> Best wishes
>>>=20
>>> R
>>>=20
>>>=20
>>>>=20
>>>> Best regards
>>>> Michael
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Sat, May 28, 2016 at 1:17 AM, Michael Tuexen =
 wrote:
>>>>>> On 28 May 2016, at 04:30, Jana Iyengar  wrote:
>>>>>>=20
>>>>>> Hi Michael,
>>>>>>=20
>>>>>> Are there any plans to analyse the requirements in a protocol =
independent
>>>>>> way and try to figure out if these requirements can also be met =
by evolving
>>>>>> one or more of the existing transport protocols (in combination =
with the appropriate
>>>>>> (D)TLS)? And then making a decision whether it is appropriate to
>>>>>> evolve existing protocols in addition to or instead of developing =
a new one...
>>>>>>=20
>>>>>> I agree with you that the requirements of QUIC should be =
requirements for new protocols and for evolution of existing ones. The =
lessons of QUIC are expected to inform other transport work -- QUIC has =
provided inputs to TCP and TLS about the importance of avoiding =
handshake RTTs, and more recently, RACK (draft-cheng-tcpm-rack-00) is =
similar in spirit to QUIC's loss recovery.
>>>>>>=20
>>>>>> Subsequent protocol work must learn QUIC's lessons, just as QUIC =
learned from its predecessors. While there's inevitably functional =
overlap between QUIC and any of {TCP, SCTP, MPTCP} (which have overlaps =
of their own), much of the work of QUIC has been in refining and tightly =
integrating mechanisms that we have learned from previous transports =
into a modern transport -- protection of data and headers, low =
latency-overhead, congestion-control agility, and strong loss-recovery, =
to name a few.
>>>>> Hi Jana,
>>>>>=20
>>>>> so these are some of the requirements, right? I'm wondering if it =
makes sense to provide such a list
>>>>> of findings in a protocol independent way. What is important and =
what is not needs knowledge of the
>>>>> results of the experiments Google where running.
>>>>> Without such a description, it is hard for other groups to figure =
out if it is important to consider
>>>>> integrating a specific feature of QUIC.
>>>>>=20
>>>>> Best regards
>>>>> Michael
>>>>>>=20
>>>>>> So, I agree with Ted and Sal's sentiments. Fixing up our existing =
designs for existing deployments is definitely very valuable and =
hopefully inevitable, but it does not take away from the fact that QUIC =
is a clean protocol design that incorporates, as first principles, =
lessons learned from our collective past. Going forward, I expect there =
to be debates about which protocol is the best fit for an application, =
and I encourage that -- having real choice in transport protocols at =
design time and at run time is a wonderful thing, and it's long overdue.
>>>>>>=20
>>>>>> - jana
>>>>>=20
>>>>> _______________________________________________
>>>>> QUIC mailing list
>>>>> QUIC@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/quic
>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> QUIC mailing list
>>>> QUIC@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/quic
>>>=20
>>> --------
>>> Randall Stewart
>>> rrs@netflix.com
>>> 803-317-4952
>=20
> --------
> Randall Stewart
> rrs@netflix.com
> 803-317-4952
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>=20
>=20


From nobody Tue May 31 08:20:14 2016
Return-Path: 
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 170AC12D5E3 for ; Tue, 31 May 2016 08:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 xUGu62_A9A_e for ; Tue, 31 May 2016 08:20:08 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 F142C12D1E8 for ; Tue, 31 May 2016 08:20:07 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id i187so5790136qkd.3 for ; Tue, 31 May 2016 08:20:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ezFjk4VupZffmXWzw1Z1ao9L32wxwBzPmonWqgNzauE=; b=ksUQhzjJqOEZi8USYixpd68LtxjxsOdHlgJ2WQ/W4hstIvdxYK9t0WEWfTKPeAdJoO n64Uz5aKGtmSqRvD9Fv+KuxKeLvcz4m0wHdgW5r9i7BNodIukIHJIhuYJQ4xSuv5MeV6 dYDB4vryYAwhcUjLrrNGT/QBc+ih3XXIU/YlI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ezFjk4VupZffmXWzw1Z1ao9L32wxwBzPmonWqgNzauE=; b=AS3XTJgV8ou+dky6GwwhYMmaX++j4QjtfBIO13sC2RNbhKcLoaBlkJqyBCXDBbfXJi 8vjrtNEjkGWdPD9jrIxpv2UpzVbu/tkC7etcKQcemFe1fNHffQA184OGJusoQLa5TyxN SS/v3IXmN1BTULCLuNqEkyacE1mpq+GrbgA99dKEjbDmLgyLcbbW0p8diq6cVuDFm3VD KW6wvUcqWBMXC4GuNfcriBX3v2A6szgBSTx6cDyQIxSCKOaZO9u8Sct0fzsgAewrWJZj kXBiiQ2mWdkGkAtVPM3KONUR8VNxgT+qCFF0+v0uc0+V4MBOtDj0cr8lylCY0VWCQpr3 2sqA==
X-Gm-Message-State: ALyK8tLbhvE/6Lk5kEPmVBfxg8ErGbe3+52q3J5aSRITNeQcrxNEVHnHjtHKBT4f3fVrNAOJ
X-Received: by 10.55.51.71 with SMTP id z68mr32793510qkz.50.1464708006303; Tue, 31 May 2016 08:20:06 -0700 (PDT)
Received: from [100.127.81.150] ([69.53.246.16]) by smtp.gmail.com with ESMTPSA id 76sm10978675qho.16.2016.05.31.08.20.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 31 May 2016 08:20:04 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7755196E-5DB7-4731-AE4B-C74578C11247"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Randall Stewart 
In-Reply-To: 
Date: Tue, 31 May 2016 11:19:50 -0400
Message-Id: <9C80DE7A-67A5-4DB6-B1D5-B3C5087703D6@netflix.com>
References: <28754BEC-F7A0-459D-9C28-2041F23A55E6@lurchi.franken.de>  <9035E19F-FDE2-43FF-BC3C-6A1DD14EC3DF@lurchi.franken.de>  <565B4FDF-1F17-4DCB-990F-FFBBEA5A84EC@lurchi.franken.de> <2D9EFFDB-E91D-433F-BFAB-13CD40CDCA2D@netflix.com>  <8EA7891D-3557-4EDB-9985-0C22F20B8E6B@netflix.com> 
To: Jana Iyengar 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: =?iso-8859-1?Q?Michael_T=FCxen?= , quic@ietf.org
Subject: Re: [QUIC] Requirements
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 15:20:12 -0000

--Apple-Mail=_7755196E-5DB7-4731-AE4B-C74578C11247
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Jana:

So this discussion leads me to a question for this activity (maybe =
others feel that way too)=85

Is this activity to:

(a) document what Google as done and produce an RFC showing here is =
=93Quic"
         
(b) solving a specific problem

If it is (b) it would make sense to figure out what the problem is and =
how
it could be solved most easily. In this case one could consider evolving =
TCP (or even
SCTP =85 but hey I do TCP right now :D). In case of (a) then this is not =
even something
we need to discuss..

Thanks

R
On May 31, 2016, at 1:56 AM, Jana Iyengar  wrote:

> Michael, Randall,
>=20
> In general, I'd agree with some of these, but I don't want to get into =
the details here since I am not sure what the point of this exercise is =
at the moment.
>=20
> I think we are in agreement that doing a clean-slate design allows us =
to build a transport with lessons we've learned so far as first =
principles. This is the opportunity we as a community have right now. I =
think many of these can be retrofit into SCTP (or into TCP), but some =
may have to be coerced, and some others may either be impossible or =
require significant surgery. We would only know by trying, and I =
encourage that work.
>=20
> Perhaps a list of features that can be added to TCP can be discussed =
on TCPM, and similarly to SCTP on TSVWG. I'd be happy to chime in on =
those threads.
>=20
> - jana
>=20
>=20
> On Mon, May 30, 2016 at 6:22 AM, Randall Stewart  =
wrote:
>=20
> On May 30, 2016, at 9:18 AM, Michael Tuexen =
 wrote:
>=20
>>> On 30 May 2016, at 13:48, Randall Stewart  wrote:
>>>=20
>>> Michael:
>>>=20
>>> See below..
>>>=20
>>> On May 29, 2016, at 11:28 AM, Michael Tuexen =
 wrote:
>>>=20
>>>>> On 28 May 2016, at 18:15, Jim Roskind  =
wrote:
>>>>>=20
>>>>> re: "...results of experiments [done by] Google."
>>>>>=20
>>>>> Publication of experiments done in/around QUIC should be a =
treasure trove for both QUIC and numerous other protocols.
>>>>>=20
>>>>> Although not all-encompasing, I presented several of Google's =
experimental results to IETF-88 back in 2013.  Be sure to take a look =
at:
>>>>>=20
>>>>> =
https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf
>>>>>=20
>>>>> Included in that IETF presentation (which I think was video =
recorded) were slides showing:
>>>>>=20
>>>>> a) NAT Eviction probabilities vs time, for UDP bindings (slide 10)
>>>>> b) Round-trip packet-loss probability for trains of paced vs =
unpaced packets of various sizes (slides 22 and 23)
>>>>> c) Generic 0 vs 1 vs 2 FEC utility for paced and unpaced trains =
(slide 24)
>>>>>=20
>>>>> All such experiments (and many more) need to be repeated and =
published over time, as the deployment of middle boxes, links (mobile =
variants vs non-mobile), routers, contemporaneous traffic patterns, etc. =
continue to evolve.
>>>>>=20
>>>>> Item (a) showed the viability of a UDP based multi-packet =
protocol, with (then current) caveats that pauses in the stream beyond =
30 seconds increase eviction rates. This drove QUIC to support handling =
of that progressive increase in eviction. There is some hope that =
upcoming IETF standardization in this area will further improve the =
NAT-eviction landscape, but that will certainly depend on vendors and =
deployment (market penetration) rates.
>>>>>=20
>>>>> Item (b) showed the tremendous impact (value) of pacing, and also =
showed the remarkable vulnerability (i.e., increased loss probability) =
of the 2nd packet in a cold-connection. That surprising (previously =
unpublished?) 2nd-packet loss statistic was recently observed and =
verified to me verbally by a second vendor for a related UDP protocol =
just a month ago (May 2016) at a public presentation I gave.=20
>>>>>=20
>>>>> Item (c) better showed the nature of the packet loss correlation =
(and showed that loss should *not* be modeled by an independent =
identically distributed process.). It clearly showed the lack of =
marginal value of multiple-packet error recovery (i.e., 2-packet-loss =
FEC) for trains as long as 21 packets (which is a plausible congestion =
window for a lossy connection). The data also justified the significant =
utility of 1-packet-loss FEC for such short windows (i.e., congestion =
window under 21) with very latency sensitive transmissions (such as =
stream creation for small latency sensitive requests, including =
perchance advertisements).=20
>>>>>=20
>>>>> We deduced in 2011 that about 5-7% of all chrome clients had UDP =
blocked (from reaching Google) for even small packets, which is what =
drove the decision to have a TCP fallback plan in QUIC.  I believe that =
experimental deployment results for QUIC continued to support that 5-7% =
statistic, though I'm very hopeful that system administrators will =
change this blocking over time (for the better!).  I also look forward =
to ongoing publication of this statistic by Google.
>>>>>=20
>>>>> Another Google published result is the fact that UDP payload sizes =
over 1350 bytes tend to be blocked more often, which was indeed the =
driving factor behind QUIC (initially) adopting a static payload size of =
1350 bytes.=20
>>>>>=20
>>>>> I expect that experiments done by multiple vendors will be =
published.  I know that Firefox adopted Chrome's metrics gathering =
approach, and hopefully if/when an experimental QUIC implementation =
appears there, then additional results will continue to be published.
>>>> Hi Jim,
>>>=20
>>> Thinking about this list in the broad sense..
>>>=20
>>>>=20
>>>> summarising the above means:
>>>> 1. Legacy NAT traversal (doable via UDP encapsulation)
>>>=20
>>> I think with TCP this is not an issue, SCTP would have to be
>>> like Quic and be wrapped in UDP I think that is already occurring
>>> within rc-web=92s data channel :-)
>>>=20
>>>=20
>>>> 2. Pacing
>>>=20
>>> I think pacing can be done on any transport and in general is
>>> a *good* thing. The one thing about pacing is that it tends to=20
>>> really hurt you in TSO/LRO (at least for TCP). I am currently =
working
>>> on trying to come up with a method for pacing that does not loose
>>> all the benefits of TSO but still gives us the desired =93paced=94 =
results.
>>>=20
>>>> 3. FEC
>>>=20
>>> This one I think for TCP would be a bit hard.. SCTP could in theory
>>> do it.. I would be quite curious to know how much benefit is really
>>> seen by this. I thought Ian mentioned to us at a past IETF that it
>>> really helped in certain scenarios but how often does that occur
>>> and what scenarios are they?  If google could share how often
>>> they have this on and how much it helps in those cases that
>>> would be interesting=85.
>>>=20
>>>> 4. Path MTU limit
>>>=20
>>> I have noticed, in my TCP work, that PMTU discovery does become
>>> painful at times.. and just having a fixed size makes life a lot =
easier.
>>> Of course with IPSEC and IPv6 and other fun things 1350 bytes may =
even be
>>> too big :-)
>>>=20
>>> Then again I have heard arguments for keeping Time-Stamps off by =
default
>>> due to the wasted size in the packet. Which makes me wonder, if we =
are
>>> so concerned about the time-stamp size should we be concerned about
>>> the extra bytes that we loose in a 1500 byte MTU?=20
>>>=20
>>> Its a shame too since time-stamps really make TCP (with PRR and =
RACK) much
>>> more robust.. We only see 15% or so of connections that have SACK =
not=20
>>> doing Time-Stamps so its not too bad (I think thats due to the fact =
that most of
>>> our clients are linux based which like FreeBSD and Mac turn =
time-stamp on
>>> by default). Sack on the other hand I see in about 99.9% of all =
clients which
>>> is way cool :-)
>>>=20
>>>> combined with what Jana mentioned:
>>>> 5. Fast connection setup
>>>=20
>>> This I think can be done in both TCP and SCTP.. I would hope that
>>> TLS 1.3 will gain that for all protocols that use it :-)
>>>=20
>>>> 6. Improved loss recovery
>>>=20
>>> I have actually been implementing RACK and PRR for TCP and am
>>> beginning to see the same benefits in TCP that we have heard
>>> about with Quic..  so these are very very useful things thats for =
sure :-)
>>>=20
>>>> 7. CC agility
>>>=20
>>> I can=92t speak for windows or MacOS .. but I think that both Linux =
and FreeBSD
>>> have had this for many years now.. I know when I look in the cc for =
BSD there
>>> are at least eight congestion control algorithms that are available =
and I am sure
>>> Linux probably has more :)
>>>=20
>>>> 8. Encryption of transport layer information
>>>=20
>>> That does eliminate snooping middle boxes.. but some environments =
(such as
>>> mobile) might not like that :-)=20
>>>=20
>>> I doubt you could easily do this with TCP or SCTP.. since middle =
boxes expect
>>> packet formates to look a particular way. Anything new of course =
does not
>>> have this issue.. possibly wrapping a protocol in UDP would gain you =
that though :-)
>>>=20
>>>>=20
>>>> Did I miss anything?
>>>=20
>>> Is multi-streaming missing from the list? I think it was mentioned =
in some
>>> of the slides. We currently don=92t see any benefit in this, but we =
are not
>>> loading multiple images for a web-page.. instead streaming a movie..
>> Ahh, yes. I missed that.
>>>=20
>>> I would imagine our client teams during search for a movie might =
like this
>>> but I would imagine they (like many web based things) open multiple =
connections.
>>>=20
>>> One question I wonder (and this is for both Quic and SCTP) is the =
ability to do
>>> LRO/TSO. I have found that one of our Caches which typically outputs =
about
>>> 36Gbps drops its speed in 1/2 if I ifconfig off TSO/LRO. When you =
pull the
>> Is this also true when you do non-hardware assisted TLS? If not, then =
this
>> features becomes less important when you consider a combined =
transport/security
>> layer as an entity=85
>=20
>=20
> We actually do TLS encryption inside the kernel ahead of TSO. It is =
true
> that we generally only send 16k at a time to TSO (the TLS record =
length) but this
> does not seem to cause us to suffer too much.
>=20
> How this all works can be found at:
>=20
> https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf
>=20
> and
>=20
> https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf
>=20
> So though encryption is happening in the kernel we still can use TSO.. =
and do :-)
>=20
> We have one particular machine that we get 80Gbps of encrypted traffic =
out of (our
> newest flash cache :-D.. thanks to a whole *lot* of work from the NF =
OCA team :D)
>=20
> R
>=20
>>=20
>> Best regards
>> Michael
>>> things into user space and encrypt it you loose the ability to do =
these functions.
>>> I don=92t think SCTP has ever been able to do TSO/LRO as well..  =
Thats one big
>>> impact to performance that needs to be thought about..
>>>=20
>>> I would also like to see any new protocol implementable in the =
kernel as well. Currently
>>> Quic uses a floating point number for time-stamps and that would be =
pretty heavy weight
>>> for the kernel.. having a compatible integer equivalent would be =
something I think that is needed.
>>>=20
>>> Best wishes
>>>=20
>>> R
>>>=20
>>>=20
>>>>=20
>>>> Best regards
>>>> Michael
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Sat, May 28, 2016 at 1:17 AM, Michael Tuexen =
 wrote:
>>>>>> On 28 May 2016, at 04:30, Jana Iyengar  wrote:
>>>>>>=20
>>>>>> Hi Michael,
>>>>>>=20
>>>>>> Are there any plans to analyse the requirements in a protocol =
independent
>>>>>> way and try to figure out if these requirements can also be met =
by evolving
>>>>>> one or more of the existing transport protocols (in combination =
with the appropriate
>>>>>> (D)TLS)? And then making a decision whether it is appropriate to
>>>>>> evolve existing protocols in addition to or instead of developing =
a new one...
>>>>>>=20
>>>>>> I agree with you that the requirements of QUIC should be =
requirements for new protocols and for evolution of existing ones. The =
lessons of QUIC are expected to inform other transport work -- QUIC has =
provided inputs to TCP and TLS about the importance of avoiding =
handshake RTTs, and more recently, RACK (draft-cheng-tcpm-rack-00) is =
similar in spirit to QUIC's loss recovery.
>>>>>>=20
>>>>>> Subsequent protocol work must learn QUIC's lessons, just as QUIC =
learned from its predecessors. While there's inevitably functional =
overlap between QUIC and any of {TCP, SCTP, MPTCP} (which have overlaps =
of their own), much of the work of QUIC has been in refining and tightly =
integrating mechanisms that we have learned from previous transports =
into a modern transport -- protection of data and headers, low =
latency-overhead, congestion-control agility, and strong loss-recovery, =
to name a few.
>>>>> Hi Jana,
>>>>>=20
>>>>> so these are some of the requirements, right? I'm wondering if it =
makes sense to provide such a list
>>>>> of findings in a protocol independent way. What is important and =
what is not needs knowledge of the
>>>>> results of the experiments Google where running.
>>>>> Without such a description, it is hard for other groups to figure =
out if it is important to consider
>>>>> integrating a specific feature of QUIC.
>>>>>=20
>>>>> Best regards
>>>>> Michael
>>>>>>=20
>>>>>> So, I agree with Ted and Sal's sentiments. Fixing up our existing =
designs for existing deployments is definitely very valuable and =
hopefully inevitable, but it does not take away from the fact that QUIC =
is a clean protocol design that incorporates, as first principles, =
lessons learned from our collective past. Going forward, I expect there =
to be debates about which protocol is the best fit for an application, =
and I encourage that -- having real choice in transport protocols at =
design time and at run time is a wonderful thing, and it's long overdue.
>>>>>>=20
>>>>>> - jana
>>>>>=20
>>>>> _______________________________________________
>>>>> QUIC mailing list
>>>>> QUIC@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/quic
>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> QUIC mailing list
>>>> QUIC@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/quic
>>>=20
>>> --------
>>> Randall Stewart
>>> rrs@netflix.com
>>> 803-317-4952
>=20
>=20
> --------
> Randall Stewart
> rrs@netflix.com
> 803-317-4952
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>=20
>=20

--------
Randall Stewart
rrs@netflix.com
803-317-4952






--Apple-Mail=_7755196E-5DB7-4731-AE4B-C74578C11247
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Jana:

So this discussion leads me =
to a question for this activity (maybe others feel that way =
too)=85

Is this activity =
to:

(a) document what Google as done and =
produce an RFC showing here is =93Quic"
      =
   <or>
(b) solving a specific =
problem

If it is (b) it would make sense to =
figure out what the problem is and how
it could be solved most =
easily. In this case one could consider evolving TCP (or =
even
SCTP =85 but hey I do TCP right now :D). In case of (a) =
then this is not even something
we need to =
discuss..

Thanks

R
=

On May 31, 2016, at 1:56 AM, Jana Iyengar <jri@google.com> wrote:

Michael, Randall,

In general, I'd agree =
with some of these, but I don't want to get into the details here since =
I am not sure what the point of this exercise is at the =
moment.

I think we are in agreement that doing =
a clean-slate design allows us to build a transport with lessons we've =
learned so far as first principles. This is the opportunity we as a =
community have right now. I think many of these can be retrofit into =
SCTP (or into TCP), but some may have to be coerced, and some others may =
either be impossible or require significant surgery. We would only know =
by trying, and I encourage that work.

Perhaps a =
list of features that can be added to TCP can be discussed on TCPM, and =
similarly to SCTP on TSVWG. I'd be happy to chime in on those =
threads.

- jana


On Mon, May 30, =
2016 at 6:22 AM, Randall Stewart <rrs@netflix.com> wrote:

On =
May 30, 2016, at 9:18 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> =
wrote:

On 30 May 2016, at 13:48, Randall =
Stewart <rrs@netflix.com> =
wrote:

Michael:

See below..

On May 29, 2016, at =
11:28 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> =
wrote:

On 28 =
May 2016, at 18:15, Jim Roskind <JimRoskind@gmail.com> wrote:

re: =
"...results of experiments [done by] Google."

Publication of =
experiments done in/around QUIC should be a treasure trove for both QUIC =
and numerous other protocols.

Although not all-encompasing, I =
presented several of Google's experimental results to IETF-88 back in =
2013.  Be sure to take a look at:

https://www.ietf.org/proceedings/88/slides/slides-88-tsv=
area-10.pdf

Included in that IETF presentation (which I think =
was video recorded) were slides showing:

a) NAT Eviction =
probabilities vs time, for UDP bindings (slide 10)
b) Round-trip =
packet-loss probability for trains of paced vs unpaced packets of =
various sizes (slides 22 and 23)
c) Generic 0 vs 1 vs 2 FEC utility =
for paced and unpaced trains (slide 24)

All such experiments (and =
many more) need to be repeated and published over time, as the =
deployment of middle boxes, links (mobile variants vs non-mobile), =
routers, contemporaneous traffic patterns, etc. continue to =
evolve.

Item (a) showed the viability of a UDP based multi-packet =
protocol, with (then current) caveats that pauses in the stream beyond =
30 seconds increase eviction rates. This drove QUIC to support handling =
of that progressive increase in eviction. There is some hope that =
upcoming IETF standardization in this area will further improve the =
NAT-eviction landscape, but that will certainly depend on vendors and =
deployment (market penetration) rates.

Item (b) showed the =
tremendous impact (value) of pacing, and also showed the remarkable =
vulnerability (i.e., increased loss probability) of the 2nd packet in a =
cold-connection. That surprising (previously unpublished?) 2nd-packet =
loss statistic was recently observed and verified to me verbally by a =
second vendor for a related UDP protocol just a month ago (May 2016) at =
a public presentation I gave. 

Item (c) better =
showed the nature of the packet loss correlation (and showed that loss =
should *not* be modeled by an independent identically distributed =
process.). It clearly showed the lack of marginal value of =
multiple-packet error recovery (i.e., 2-packet-loss FEC) for trains as =
long as 21 packets (which is a plausible congestion window for a lossy =
connection). The data also justified the significant utility of =
1-packet-loss FEC for such short windows (i.e., congestion window under =
21) with very latency sensitive transmissions (such as stream creation =
for small latency sensitive requests, including perchance =
advertisements). 

We deduced in 2011 that about =
5-7% of all chrome clients had UDP blocked (from reaching Google) for =
even small packets, which is what drove the decision to have a TCP =
fallback plan in QUIC.  I believe that experimental deployment =
results for QUIC continued to support that 5-7% statistic, though I'm =
very hopeful that system administrators will change this blocking over =
time (for the better!).  I also look forward to ongoing publication =
of this statistic by Google.

Another Google published result is =
the fact that UDP payload sizes over 1350 bytes tend to be blocked more =
often, which was indeed the driving factor behind QUIC (initially) =
adopting a static payload size of 1350 =
bytes. 

I expect that experiments done by =
multiple vendors will be published.  I know that Firefox adopted =
Chrome's metrics gathering approach, and hopefully if/when an =
experimental QUIC implementation appears there, then additional results =
will continue to be published.
Hi =
Jim,

Thinking about this list in the broad =
sense..


summarising the above =
means:
1. Legacy NAT traversal (doable via UDP =
encapsulation)

I think with TCP this is not an =
issue, SCTP would have to be
like Quic and be wrapped in UDP I think =
that is already occurring
within rc-web=92s data channel =
:-)


2. Pacing

I =
think pacing can be done on any transport and in general is
a *good* =
thing. The one thing about pacing is that it tends =
to 
really hurt you in TSO/LRO (at least for TCP). =
I am currently working
on trying to come up with a method for pacing =
that does not loose
all the benefits of TSO but still gives us the =
desired =93paced=94 results.

3. =
FEC

This one I think for TCP would be a bit hard.. =
SCTP could in theory
do it.. I would be quite curious to know how =
much benefit is really
seen by this. I thought Ian mentioned to us at =
a past IETF that it
really helped in certain scenarios but how often =
does that occur
and what scenarios are they?  If google could =
share how often
they have this on and how much it helps in those =
cases that
would be interesting=85.

4.=
 Path MTU limit

I have noticed, in my TCP work, that =
PMTU discovery does become
painful at times.. and just having a fixed =
size makes life a lot easier.
Of course with IPSEC and IPv6 and other =
fun things 1350 bytes may even be
too big :-)

Then again I =
have heard arguments for keeping Time-Stamps off by default
due to =
the wasted size in the packet. Which makes me wonder, if we are
so =
concerned about the time-stamp size should we be concerned about
the =
extra bytes that we loose in a 1500 byte =
MTU? 

Its a shame too since time-stamps really =
make TCP (with PRR and RACK) much
more robust.. We only see 15% or so =
of connections that have SACK not 
doing =
Time-Stamps so its not too bad (I think thats due to the fact that most =
of
our clients are linux based which like FreeBSD and Mac turn =
time-stamp on
by default). Sack on the other hand I see in about =
99.9% of all clients which
is way cool :-)

combined with what Jana mentioned:
5. Fast connection =
setup

This I think can be done in both TCP and =
SCTP.. I would hope that
TLS 1.3 will gain that for all protocols =
that use it :-)

6. Improved loss =
recovery

I have actually been implementing RACK and =
PRR for TCP and am
beginning to see the same benefits in TCP that we =
have heard
about with Quic..  so these are very very useful =
things thats for sure :-)

7. CC =
agility

I can=92t speak for windows or MacOS .. but =
I think that both Linux and FreeBSD
have had this for many years =
now.. I know when I look in the cc for BSD there
are at least eight =
congestion control algorithms that are available and I am sure
Linux =
probably has more :)

8. Encryption of =
transport layer information

That does eliminate =
snooping middle boxes.. but some environments (such as
mobile) might =
not like that :-) 

I doubt you could easily do =
this with TCP or SCTP.. since middle boxes expect
packet formates to =
look a particular way. Anything new of course does not
have this =
issue.. possibly wrapping a protocol in UDP would gain you that though =
:-)


Did I miss =
anything?

Is multi-streaming missing from the list? =
I think it was mentioned in some
of the slides. We currently don=92t =
see any benefit in this, but we are not
loading multiple images for a =
web-page.. instead streaming a movie..
Ahh, yes. I =
missed that.

I would imagine our client =
teams during search for a movie might like this
but I would imagine =
they (like many web based things) open multiple connections.

One =
question I wonder (and this is for both Quic and SCTP) is the ability to =
do
LRO/TSO. I have found that one of our Caches which typically =
outputs about
36Gbps drops its speed in 1/2 if I ifconfig off =
TSO/LRO. When you pull the
Is this also true when you do =
non-hardware assisted TLS? If not, then this
features becomes less =
important when you consider a combined =
transport/security
layer as an =
entity=85


We =
actually do TLS encryption inside the kernel ahead of TSO. It is =
true
that we generally only send 16k at a time to TSO (the TLS =
record length) but this
does not seem to cause us to suffer =
too much.

How this all works can be found =
at:


and


So though encryption is happening in the =
kernel we still can use TSO.. and do :-)

We =
have one particular machine that we get 80Gbps of encrypted traffic out =
of (our
newest flash cache :-D.. thanks to a whole *lot* of =
work from the NF OCA team :D)

R


Best =
regards
Michael
things into user space =
and encrypt it you loose the ability to do these functions.
I don=92t =
think SCTP has ever been able to do TSO/LRO as well..  Thats one =
big
impact to performance that needs to be thought about..

I =
would also like to see any new protocol implementable in the kernel as =
well. Currently
Quic uses a floating point number for time-stamps and =
that would be pretty heavy weight
for the kernel.. having a =
compatible integer equivalent would be something I think that is =
needed.

Best wishes

R



Best regards
Michael




On Sat, May 28, 2016 at 1:17 AM, Michael =
Tuexen <Michael.Tuexen@lurchi.franken.de> =
wrote:
On 28 May 2016, at 04:30, Jana =
Iyengar <jri@google.com> wrote:

Hi =
Michael,

Are there any plans to analyse the requirements in a =
protocol independent
way and try to figure out if these requirements =
can also be met by evolving
one or more of the existing transport =
protocols (in combination with the appropriate
(D)TLS)? And then =
making a decision whether it is appropriate to
evolve existing =
protocols in addition to or instead of developing a new one...

I =
agree with you that the requirements of QUIC should be requirements for =
new protocols and for evolution of existing ones. The lessons of QUIC =
are expected to inform other transport work -- QUIC has provided inputs =
to TCP and TLS about the importance of avoiding handshake RTTs, and more =
recently, RACK (draft-cheng-tcpm-rack-00) is similar in spirit to QUIC's =
loss recovery.

Subsequent protocol work must learn QUIC's =
lessons, just as QUIC learned from its predecessors. While there's =
inevitably functional overlap between QUIC and any of {TCP, SCTP, MPTCP} =
(which have overlaps of their own), much of the work of QUIC has been in =
refining and tightly integrating mechanisms that we have learned from =
previous transports into a modern transport -- protection of data and =
headers, low latency-overhead, congestion-control agility, and strong =
loss-recovery, to name a few.
Hi Jana,

so these =
are some of the requirements, right? I'm wondering if it makes sense to =
provide such a list
of findings in a protocol independent way. What =
is important and what is not needs knowledge of the
results of the =
experiments Google where running.
Without such a description, it is =
hard for other groups to figure out if it is important to =
consider
integrating a specific feature of QUIC.

Best =
regards
Michael

So, I agree with Ted =
and Sal's sentiments. Fixing up our existing designs for existing =
deployments is definitely very valuable and hopefully inevitable, but it =
does not take away from the fact that QUIC is a clean protocol design =
that incorporates, as first principles, lessons learned from our =
collective past. Going forward, I expect there to be debates about which =
protocol is the best fit for an application, and I encourage that -- =
having real choice in transport protocols at design time and at run time =
is a wonderful thing, and it's long overdue.

- =
jana

_______________________________________________QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic


_______________________________________________
QUIC =
mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic

--------
Randall Stewart
rrs@netflix.com
803-317-4952



--------
Randall Stewart






=


_______________________________________________<=
br>
QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic








--------
Randall Stewart
803-317-4952=









=

--Apple-Mail=_7755196E-5DB7-4731-AE4B-C74578C11247--


From nobody Tue May 31 14:08:00 2016
Return-Path: 
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 8CFC412D8EF for ; Tue, 31 May 2016 14:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 3Z_4QQek5zv5 for ; Tue, 31 May 2016 14:07:55 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 A79AA12D56C for ; Tue, 31 May 2016 14:07:55 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id j1so313337532oih.3 for ; Tue, 31 May 2016 14:07:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZWulgoDYN77RCqdOgcF86TdZ6WULAK47IF3jhKYQjkE=; b=TY4Yn5fXavZFhl5UJEpI3RWcj4J2X7qs1yEjj9qvhtcSMOB+u53gSVxJmIgVauSkYW tt1Cs0O8OqCZiYe6EtGO68aWEIxBNIBwPtTCJXdrINwSy6LmSksYhdMPROqeFUmSSLep ZEksifzxWVcH32atLppG3aDE7WjovQNor7wfO/QoYG9UUD++tRA4V7eoeIlYCVWB3jKl dEz/hfWSZ/1els1aeEik8YRc+Jj3Qdw1VFHPJ+dioFkAuncfhdEDKQOhIC0zvrRNu79J TLDZI8wfiqrRYegKAcDgEG15RZ+V5I86jyouJmIpLyJ49B0cxkAxBAb1FQX/bnos6drn vrbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZWulgoDYN77RCqdOgcF86TdZ6WULAK47IF3jhKYQjkE=; b=XIMF6oo9WNVZxTmeUAWUJP05RGV2HMA49lxym0aRY+V8woa9ffJxZ507EXlbEQS9PG RwtISDftkIwELSQHyuufaaueNxz41ob3jmdu6RDeYhYbcvO7RCLjYXIFsvzkWNow43k+ 8B79v18bedlRwIj9SRNcIwPwmExuI51xhAgyYHf84sNxr9W3W2mGzfVyDnWwb/j0Hg5r JzSiw7boANHW6TBB8aiIostxRaPNAhH+iAi6vH7Jed0Gx0xPGkJyPibiAdlbkys2/UsZ Dp41MQaWQYkReiqALYnSWEv/B7LHG6I1f2DTgidFZfe46jvrYod71yRN41ijVk/9zkF+ MV4w==
X-Gm-Message-State: ALyK8tKaRsv7WVioChsbZPvHSDW59OlrN9mdPisYl/Ho7fl2GZ6zl/27uoF4O6RFmmQmp7YVZHUGJBz/nKAjMQ==
X-Received: by 10.202.171.143 with SMTP id u137mr18754214oie.71.1464728874915;  Tue, 31 May 2016 14:07:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.195.137 with HTTP; Tue, 31 May 2016 14:07:35 -0700 (PDT)
In-Reply-To: 
References:  
From: Ted Hardie 
Date: Tue, 31 May 2016 14:07:35 -0700
Message-ID: 
To: Jim Roskind 
Content-Type: multipart/alternative; boundary=001a113c2efe482016053429c400
Archived-At: 
Cc: quic@ietf.org
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 May 2016 21:07:58 -0000

--001a113c2efe482016053429c400
Content-Type: text/plain; charset=UTF-8

Hi Jim,

Sorry for the belated reply--catching up after the long weekend. Reply at
the bottom.

On Sat, May 28, 2016 at 10:49 AM, Jim Roskind  wrote:

> I've tried to read the whole thread... but I don't think I saw items that
> would address following concerns about the charter.
>
> My general perspective is that QUIC was designed to exploit the tight
> integration of numerous protocol elements that were traditionally separated
> into layers.  Traditional layering included TCP handling
> congestion/reliability, independent of TLS handling privacy and
> authentication, independent of HTTP handling of request/response pairs
> (multiplexed in HTTP/2). QUIC deviates from that pattern at the highest
> level, when stream data is (usually) placed into separate UDP packets
> (despite multiplexing), with independent decryption (usually) for each
> stream fragment. Even QUIC's basic connection establishment tightly binds
> awareness of all 3 traditional layers.
>
> Other tight integration points in QUIC include the way the packet sequence
> number is used as a basis for the crypto IV for packet decryption, while
> also being used for N/ACK reliability (congestion(?) detection?)
> notification. Those sequence numbers were also integrated into the
> definition of the initial FEC strategy. Further, the rebundling of data
> (rather than retransmission of packets with old sequence numbers) to
> establish reliable transmission, then simplified the crypto use of the
> sequence number as an IV (only a small fixed window could ever be
> outstanding, and highly delayed packets could be safely/naturally discarded
> by a decryption authentication failure).
>
> Contrary to that tight-integration perspective that I've held for QUIC,
> some of the charter suggests that numerous elements can be teased apart or
> addressed separately.
>

> a) Congestion control: I would expect that additional data (optionally)
> transmitted as part of the core protocol would be critical to evolution of
> congestion control.  Examples would include (optionally) better time
> stamping; better understanding of received vs lost vs reconstructed (via
> FEC) packets. Even the decision to send ACK data in standard packets in the
> company of stream data represents a (optional??) point of integration.  The
> charter appears to leave congestion control to documents external to the
> wire spec, which surprises me.
>
> b) FEC: The quote "specific FEC scheme definitions are out of scope"
> concerned me.  Although I would not like new/novel FEC inventions to be
> studied by the WG, I would absolutely expect that very specific FEC
> definitions, which made the protocol workable at a wire spec level (i.e.,
> what do you do with FEC related information to recover a packet or
> information?? What extra data fields in the packets would be needed to
> relate packets to FEC groups(?)?).
>
> Although I spent years of my life designing, justifying, and working to
> deploy QUIC, I'm new to the IETF, so I'd like to better understand the
> planned (apparent) separation shown above... or understand why it doesn't
> run contrary to the above perspective.
>
>
So, the basic thining here is that the IETF builds building blocks, and
that when they are successful they tend to see a lot of re-use.  When
bringing this charter forward, the proponents looked at which building
blocks would likely get reused and how, and we tried to structure the work
both to enable future use and to reinforce the current interplay among
application, cryptographic protection, and transport features.

One piece that we saw as a re-usable building block was the cryptographic
handshake--sharing that with TLS 1.3 seemed to us to make sense both for
QUIC and TLS.

A second piece was the core transport work, which is re-usable across a
number of potential using applications.  We certainly didn't intend by that
to create a specific layering.  Rather, we wanted to make it easy for new
protocols to describe how they mapped their exchanges onto the mechanisms
of QUIC, by having all the mappings (including the original HTTP mapping)
be related to the core mechanisms.

The third piece was that process of describing a specific application's use
of the transport and cryptographic mechanisms.  Having a worked example of
that for a well-known application will help ensure that later applications
that want to re-use it will know which pieces are derived from QUIC and
which from other using applications.

To give an example:  imagine someone wanted to implement DPRIVE-like DNS
privacy by running  DNS over QUIC.  If we define QUIC as tightly bound to
its current application, the result will look a great deal like DNS over
HTTP (certainly possible, e.g. by making GET requests for DNS URIs).  But
if we enable new mappings, it will end up looking much more like DNS over a
scalable, non-blocking, cryptographically protected UDP transport.  The
un-needed HTTP-isms won't creep in as easily.  Admittedly, you might get
the latter result starting from the tightly bound version and ruthlessly
cutting and replacing, but you'd probably see the result as a sister
protocol to the original, rather than as a different use of the same.

The latter seemed preferable, at least to me.  There is a real danger here
of shipping the org chart, and one of the reasons we wanted to keep the
work in a single working group was to avoid drift between protocol
mechanisms in different areas of work.  I personally think that's the right
balance, but this is the part of the IETF process where that construction
gets discussed.

Just my thoughts on this,

regards,

Ted


> Thanks,
>
> Jim
>
> On Fri, May 13, 2016 at 4:26 PM, Ted Hardie  wrote:
>
>> Howdy,
>>
>> As part of the BoF preparation, we put together a stab at a draft
>> charter.  It's available as html and markdown on github at:
>>
>> https://github.com/IETF-QUIC/Charter
>>
>> I've attached the HTML version as well.
>>
>> It would be great to have some of the discussion on the list before the
>> BoF.  Comments to the list or issues/pull requests at the github repo are
>> welcome.  We will periodically reflect any issues or suggestion from the
>> Repo back to the list, but this will be manual, so expect some lag.
>>
>> regards,
>>
>> Ted
>>
>> _______________________________________________
>> QUIC mailing list
>> QUIC@ietf.org
>> https://www.ietf.org/mailman/listinfo/quic
>>
>>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>

--001a113c2efe482016053429c400
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Jim,

Sorry for the belated reply--cat=
ching up after the long weekend. Reply at the bottom.

On Sat, May 28, 2016 at 10:49 AM, J=
im Roskind <JimRoskind@gmail.com> wrote:
I've tried to read the whole thread.=
.. but I don't think I saw items that would address following concerns =
about the charter.

My general perspective is that QUIC w=
as designed to exploit the tight integration of numerous protocol elements =
that were traditionally separated into layers.=C2=A0 Traditional layering i=
ncluded TCP handling congestion/reliability, independent of TLS handling pr=
ivacy and authentication, independent of HTTP handling of request/response =
pairs (multiplexed in HTTP/2). QUIC deviates from that pattern at the highe=
st level, when stream data is (usually) placed into separate UDP packets (d=
espite multiplexing), with independent decryption (usually) for each stream=
 fragment. Even QUIC's basic connection establishment tightly binds awa=
reness of all 3 traditional layers.

Other tight in=
tegration points in QUIC include the way the packet sequence number is used=
 as a basis for the crypto IV for packet decryption, while also being used =
for N/ACK reliability (congestion(?) detection?) notification. Those sequen=
ce numbers were also integrated into the definition of the initial FEC stra=
tegy. Further, the rebundling of data (rather than retransmission of packet=
s with old sequence numbers) to establish reliable transmission, then simpl=
ified the crypto use of the sequence number as an IV (only a small fixed wi=
ndow could ever be outstanding, and highly delayed packets could be safely/=
naturally discarded by a decryption authentication failure).=C2=A0

Contrary to that tight-integration perspective that I'=
ve held for QUIC, some of the charter suggests that numerous elements can b=
e teased apart or addressed separately. 

a) Conge=
stion control: I would expect that additional data (optionally) transmitted=
 as part of the core protocol would be critical to evolution of congestion =
control.=C2=A0 Examples would include (optionally) better time stamping; be=
tter understanding of received vs lost vs reconstructed (via FEC) packets. =
Even the decision to send ACK data in standard packets in the company of st=
ream data represents a (optional??) point of integration.=C2=A0 The charter=
 appears to leave congestion control to documents external to the wire spec=
, which surprises me.

b) FEC: The quote &quo=
t;specific FEC scheme definitions are out of scope" concerned me.=C2=
=A0 Although I would not like new/novel FEC inventions to be studied by the=
 WG, I would absolutely expect that very specific FEC definitions, which ma=
de the protocol workable at a wire spec level (i.e., what do you do with FE=
C related information to recover a packet or information?? What extra data =
fields in the packets would be needed to relate packets to FEC groups(?)?).=


Although I spent years of my life designing, just=
ifying, and working to deploy QUIC, I'm new to the IETF, so I'd lik=
e to better understand the planned (apparent) separation shown above... or =
understand why it doesn't run contrary to the above perspective.
<=
div>

So, the basic thining =
here is that the IETF builds building blocks, and that when they are succes=
sful they tend to see a lot of re-use.=C2=A0 When bringing this charter for=
ward, the proponents looked at which building blocks would likely get reuse=
d and how, and we tried to structure the work both to enable future use and=
 to reinforce the current interplay among application, cryptographic protec=
tion, and transport features.=C2=A0 

One piece that we saw as a re-u=
sable building block was the cryptographic handshake--sharing that with TLS=
 1.3 seemed to us to make sense both for QUIC and TLS.=C2=A0 

A seco=
nd piece was the core transport work, which is re-usable across a number of=
 potential using applications.=C2=A0 We certainly didn't intend by that=
 to create a specific layering.=C2=A0 Rather, we wanted to make it easy for=
 new protocols to describe how they mapped their exchanges onto the mechani=
sms of QUIC, by having all the mappings (including the original HTTP mappin=
g) be related to the core mechanisms.

The thir=
d piece was that process of describing a specific application's use of =
the transport and cryptographic mechanisms.=C2=A0 Having a worked example o=
f that for a well-known application will help ensure that later application=
s that want to re-use it will know which pieces are derived from QUIC and w=
hich from other using applications.

To give an example:=
=C2=A0 imagine someone wanted to implement DPRIVE-like DNS privacy by runni=
ng=C2=A0 DNS over QUIC.=C2=A0 If we define QUIC as tightly bound to its cur=
rent application, the result will look a great deal like DNS over HTTP (cer=
tainly possible, e.g. by making GET requests for DNS URIs).=C2=A0 But if we=
 enable new mappings, it will end up looking much more like DNS over a scal=
able, non-blocking, cryptographically protected UDP transport.=C2=A0 The un=
-needed HTTP-isms won't creep in as easily.=C2=A0 Admittedly, you might=
 get the latter result starting from the tightly bound version and ruthless=
ly cutting and replacing, but you'd probably see the result as a sister=
 protocol to the original, rather than as a different use of the same.
<=
br>
The latter seemed preferable, at least to me.=C2=A0 There is =
a real danger here of shipping the org chart, and one of the reasons we wan=
ted to keep the work in a single working group was to avoid drift between p=
rotocol mechanisms in different areas of work.=C2=A0 I personally think tha=
t's the right balance, but this is the part of the IETF process where t=
hat construction gets discussed.

Just my thoughts on this=
,

regards,

Ted
=C2=A0
Thanks,

Jim

On Fri, May 13, 2016 at 4:26 P=
M, Ted Hardie <ted.ietf@gmail.com> wrote:
<=
div>
Howdy,

As part of the BoF preparation, we put to=
gether a stab at a draft charter.=C2=A0 It's available as html and mark=
down on github at:

https://github.com/IETF-QUIC/Charter

I&#=
39;ve attached the HTML version as well.=C2=A0 

It would =
be great to have some of the discussion on the list before the BoF.=C2=A0 C=
omments to the list or issues/pull requests at the github repo are=20
welcome.=C2=A0 We will periodically reflect any issues or suggestion from t=
he
 Repo back to the list, but this will be manual, so expect some lag.
<=
div>
regards,

Ted


__________________________________________=
_____

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





_______________________________________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--001a113c2efe482016053429c400--


From nobody Tue May 31 17:51:16 2016
Return-Path: 
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 0178F12D921 for ; Tue, 31 May 2016 17:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 AinQfPQ_LHGh for ; Tue, 31 May 2016 17:51:13 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 5D6E612D13C for ; Tue, 31 May 2016 17:51:13 -0700 (PDT)
Received: by mail-qg0-x230.google.com with SMTP id q32so100898981qgq.3 for ; Tue, 31 May 2016 17:51:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=6a2gEcpf7QrnRK3lsBavnPqAMdezRlVSVAAGTlS1LnQ=; b=ocVD8LS3Y7rTXVCOWXuMs/p4Jk77tWDWigVWvnCgJbWv/rB0aSfCE/cPQ2sSeyx+Zl +8WDc4I4/jN1o5e4tnaw+9qIl2KdFgbeUwJCfLmSfX8EYXNy6fsdDu+37RP20X7Tjmg0 ATZ/quYB11u+hoIMlryUoHwbWIgq1p9NJoRJvdiPwItohcyxSwqyCBgV6zIMqQAT/GF5 4kNdxnNJ2QUxuMWl5rBxxZ/mnbGoh2+lylvzHmblMUP/Ji6Ajn+fLU16wCGWWX+UByog 8BSRkdkJM/5tLTNRvRU8DU/uDbpyn6jyy9i3drzFpQqa3aJ63dFNzSRrsAefh/ZYkoSL n49Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=6a2gEcpf7QrnRK3lsBavnPqAMdezRlVSVAAGTlS1LnQ=; b=k8X/v9Q6BWfZaRBb9H/olGC3saULJCN/ZsS2hOZOgD55vWcKaA7bhzL7qwBSMtstQH G2VaQAaok0byeRrD1gvpFUVO2J6RM3U/wu5V6Vz+AFma8G1rc3NtnY44V9XbuJKpv3TJ D+vMiqg0ULhPjBme20+4YFWeM2GotpHzSTjHrfKKWVF9SFGGUixVyP4Qmivs00qXvkRp 90YvbbO5RZyONijzC7PNxwBrcGTWNa/bAh13FpuCA6QM+qMQA+ZPZfHkUBu/8BenZCrc vYKV8R1jp+oo4Ywv2hnpT0/uD/1nvwz+OwX62KoQ2z1qBRLNjFSOmhyEDYE86T6mtnIf NfNg==
X-Gm-Message-State: ALyK8tIOLv7S9NlhLYAtO0UE40mW10C37js2emzOZOyQ6gmWMhmgA4EuU29gkNS31wjjew==
X-Received: by 10.140.84.229 with SMTP id l92mr32548095qgd.100.1464742272396;  Tue, 31 May 2016 17:51:12 -0700 (PDT)
Received: from twicinski-ltm.internal.salesforce.com ([204.14.236.152]) by smtp.googlemail.com with ESMTPSA id n13sm11644066qhc.37.2016.05.31.17.51.11 for  (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2016 17:51:11 -0700 (PDT)
To: quic@ietf.org
References:   
From: Tim Wicinski 
Message-ID: 
Date: Tue, 31 May 2016 20:51:09 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Jun 2016 00:51:15 -0000

On 5/31/16 5:07 PM, Ted Hardie wrote:
>
> To give an example:  imagine someone wanted to implement DPRIVE-like DNS
> privacy by running  DNS over QUIC.  If we define QUIC as tightly bound
> to its current application, the result will look a great deal like DNS
> over HTTP (certainly possible, e.g. by making GET requests for DNS
> URIs).  But if we enable new mappings, it will end up looking much more
> like DNS over a scalable, non-blocking, cryptographically protected UDP
> transport.  The un-needed HTTP-isms won't creep in as easily.
> Admittedly, you might get the latter result starting from the tightly
> bound version and ruthlessly cutting and replacing, but you'd probably
> see the result as a sister protocol to the original, rather than as a
> different use of the same.

I've had this exact same conversation about a year ago (if not longer) 
with Jim.  He gave me some very useful advice on how to approach the 
problem.

But a protocol without the HTTP-isms makes more sense (but I'm a bit 
biased on the DNS side).

tim


From nobody Tue May 31 18:12:17 2016
Return-Path: 
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 0CAD312D62E for ; Tue, 31 May 2016 18:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=microsoft.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 yrTqk7LeqJs5 for ; Tue, 31 May 2016 18:12:12 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0793.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:793]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96EF12D959 for ; Tue, 31 May 2016 18:12:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BATxjwjkX8X0DhD2g7qezkdCTcRgX3I6wkAOJWLK2PA=; b=N1PvVR6XtPSg07diTtUjsxXRzfKHt6fOq1gk65odyI4/s62Lwa/XIKx5J9SeFs2sLzQhfwuKx/0D1l+daqYqCUocHQiZwf0IiSIanYsSA5UwyM7ECn5rf7nSN1qVUHOT8TF4etWREcm02dbKg68bLNQ36aLOmwEYBcxHdLMKRCE=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 1 Jun 2016 01:11:49 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0501.013; Wed, 1 Jun 2016 01:11:49 +0000
From: Christian Huitema 
To: Tim Wicinski , "quic@ietf.org" 
Thread-Topic: [QUIC] Draft charter
Thread-Index: AQHRrW/Sb0NYcU1DiUO0Xn0RTsSsY5/Ot5aAgATucoCAAD53gIAAAoZw
Date: Wed, 1 Jun 2016 01:11:49 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:d::37f]
x-ms-office365-filtering-correlation-id: a6fea8cc-6ce2-4580-806e-08d389b9b585
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:Yrw1PpUjSWd4xdpxKkFkIc4e9jQGKKZt8R0f2YaVdJEaLpnzlPtUzUAprTiN10QVjbzuWdVZ6AD+E+o+fMkDvSYcOzwZTMDfa4Jnud+SSw6eep6VmzDoMb9pIYHWVBYgQrqsdgA48B3wrONemlhuWA==; 24:U2YMH0qVwg3R7rGD5SaTI5p1hQav4vDF1Zy6xzcWIOJX3WnnbQ8PGYwQlq5UT6ToL15pYtC0H9o9X0TUKGAM/xPEm1otDLf8zdRALa9atw8=; 7:nSa10Z6Ew71P8tHIpdW7Di/+oOb65HQ88wcbGhYJPD9iHgT3Lp+vQ2P6CBUC+s/WUM1+aLZaz4ec/sSdobtElKpgctR1QzpcVVL0Js4PQO2UaTgOut7o5kK37PXXvIJwNwusQ8P+ecRQ5XUoEfcBjM8BOeaPTHiJNx4Vj7y7SnGe5wd1gPcZC1OKFNlX4hclyfzX/sLBxa7Yn734v/KLIw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; 
x-forefront-prvs: 096029FF66
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51444003)(377454003)(551934003)(92566002)(2906002)(86612001)(9686002)(93886004)(33656002)(586003)(5003600100002)(76576001)(8936002)(102836003)(6116002)(11100500001)(10290500002)(3660700001)(5005710100001)(189998001)(3280700002)(8676002)(81166006)(122556002)(2501003)(86362001)(5004730100002)(87936001)(77096005)(107886002)(54356999)(2950100001)(5002640100001)(2900100001)(106116001)(76176999)(5001770100001)(50986999)(5008740100001)(99286002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2016 01:11:49.4252 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653
Archived-At: 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Jun 2016 01:12:14 -0000

On Tuesday, May 31, 2016 5:51 PM, Tim Wicinski wrote:
>=20
> On 5/31/16 5:07 PM, Ted Hardie wrote:
> >
> > To give an example:  imagine someone wanted to implement DPRIVE-like
> > DNS privacy by running  DNS over QUIC.  If we define QUIC as tightly
> > bound to its current application, the result will look a great deal
> > like DNS over HTTP (certainly possible, e.g. by making GET requests
> > for DNS URIs).  But if we enable new mappings, it will end up looking
> > much more like DNS over a scalable, non-blocking, cryptographically
> > protected UDP transport.  The un-needed HTTP-isms won't creep in as eas=
ily.
> > Admittedly, you might get the latter result starting from the tightly
> > bound version and ruthlessly cutting and replacing, but you'd probably
> > see the result as a sister protocol to the original, rather than as a
> > different use of the same.
>=20
> I've had this exact same conversation about a year ago (if not longer) wi=
th Jim.
> He gave me some very useful advice on how to approach the problem.
>=20
> But a protocol without the HTTP-isms makes more sense (but I'm a bit bias=
ed
> on the DNS side).

I think that QUIC really has two layers. There is a bottom layer that manag=
es the transmission of encrypted packets, the detection of errors, and poss=
ibly the forward error correction. Then there is an upper layer that manage=
s the multiplexing of streams, and that cooperates with the bottom layer to=
 manage retransmissions.=20

Currently, the two layers are tied in multiple ways. The encryption layer c=
annot function without passing the stream 1 packets to the TLS machinery. T=
he stream management frames share a number space with the error management =
frames. The per connection receive window is managed as the aggregate of th=
e per stream receive window. But these are in fact simple problems, and it =
should be possible to disentangle the error detection layer and the stream =
management layer.

After that, yes, there are quite a few possible innovations. The stream abs=
traction works well for HTTP 2.0, but I would rather use a transaction-base=
d logic for DPRIVE, and maybe something different still for real-time multi=
-media. Or, if we think of multi-path, I could see a stream layer being mul=
tiplexed over two separate lower layers, managed as two separate connection=
s.=20

The whole point of defining a user mode transport is to enable this kind of=
 innovation!

-- Christian Huitema



From nobody Tue May 31 19:03:27 2016
Return-Path: 
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 BE47312D94D for ; Tue, 31 May 2016 19:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 sQdFQc6ZWx3v for ; Tue, 31 May 2016 19:03:23 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D797A12D916 for ; Tue, 31 May 2016 19:03:22 -0700 (PDT)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BAAE122E261; Tue, 31 May 2016 22:03:18 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 1 Jun 2016 12:03:15 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <3DC70DE0-FF05-4511-BCE2-2EC6A58C4407@mnot.net>
References:     
To: Christian Huitema 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Tim Wicinski , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Jun 2016 02:03:26 -0000

Hi Christian,

> On 1 Jun 2016, at 11:11 AM, Christian Huitema  =
wrote:
>=20
> I think that QUIC really has two layers. There is a bottom layer that =
manages the transmission of encrypted packets, the detection of errors, =
and possibly the forward error correction. Then there is an upper layer =
that manages the multiplexing of streams, and that cooperates with the =
bottom layer to manage retransmissions.=20
>=20
> Currently, the two layers are tied in multiple ways. The encryption =
layer cannot function without passing the stream 1 packets to the TLS =
machinery. The stream management frames share a number space with the =
error management frames. The per connection receive window is managed as =
the aggregate of the per stream receive window. But these are in fact =
simple problems, and it should be possible to disentangle the error =
detection layer and the stream management layer.
>=20
> After that, yes, there are quite a few possible innovations. The =
stream abstraction works well for HTTP 2.0, but I would rather use a =
transaction-based logic for DPRIVE, and maybe something different still =
for real-time multi-media. Or, if we think of multi-path, I could see a =
stream layer being multiplexed over two separate lower layers, managed =
as two separate connections.=20
>=20
> The whole point of defining a user mode transport is to enable this =
kind of innovation!

This makes me wonder if QUIC is anything but a collection of functions =
that can be assembled by an application; as it is, the charter carves =
off crypto into TLS; FEC and congestion control are defined externally; =
multi-path is an extension. If streams are also optional, what's left? =0C=
Loss recovery?

I'm not against such a modular approach, but standardising it IMO will =
present some real challenges. Enough to make me wonder if just defining =
QUIC as HTTP/2-over-UDP is better; other applications could reuse its =
primitives as they like. It might not be as tidy, but it's a lot more =
workable...

Cheers,

--
Mark Nottingham   https://www.mnot.net/


From nobody Tue May 31 23:20:32 2016
Return-Path: 
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 ABF2C12D114 for ; Tue, 31 May 2016 23:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 vvuxzxGesz1i for ; Tue, 31 May 2016 23:20:28 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 4DD9212B02D for ; Tue, 31 May 2016 23:20:28 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id h19so9507507ywc.0 for ; Tue, 31 May 2016 23:20:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+UDEjHdMV/pik169ssh60iCs8qsQB9RGmlh3ggbtd/A=; b=Wt2Rwnx7qVYPFwQDH5yiyUrfHED+50njGcCkuPTBvlkBj0f56+uTEPDNUQxpmTRno/ c1HH8HFxnHQzrMBCBJybHcQgCvDAkPTTlKkNeOjbkE/CLX72Y7znBdX6tK/UFTnBebCy sH8ZrEJoBtbfBSiDkosqQgOU3T3jcMuzlzQ/hpc2l2i+AjxVX0I/h5ZeKdrW62xpxvfB yGjos65EjGRjfbzpSWM1WLi6/cdcX9wgV5Sbj4Wb5nn3OOvnkXr4de3oGwovbASyAI/c meam87ZbmtfRXMv0swy7iwvXYfHSf4c+1FlWuJhzBU2L7w7YofNWCdsnPeZRWWkdRWHu 2tBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+UDEjHdMV/pik169ssh60iCs8qsQB9RGmlh3ggbtd/A=; b=V29cTUPXK3Pc1AywcA3r3Nhwh1pwJGE00/9jTy8Un48Tgb5EQ40kjbB1sat0YYC06B HsnkikwKs4ZIC6CZwGJAb7/Y657QkXYMG/9KY1ZkVHyoHyKQKN3+F7n5Ra3soGlVKdlP pjBYBduLUN7H3rAxnOm4uXt1e3nIwR82pyZuC5mjyg1fjy+lc/FQJIcuM6f+K1r4VAog y/PJXuETtF1q8e7APlp2vIWnKlkQC1gn6wZJyAHJjweYegSX8Kt6ZscRt3U5V7FUZlip fz0w5Wwpom6xQDg6OIZugSYbOL8p43moEjiqWmXyiSFDkVzYPAK238wuvGrZScrnr8XA lwMQ==
X-Gm-Message-State: ALyK8tL5RV6LnmCqhR77G1On2BwCCWRYQ4jCEWMjTdLy8L+5u3Wff33lQDwywZYxSVYwwlhSKgH7xWtKOiodis63
X-Received: by 10.129.121.81 with SMTP id u78mr1176099ywc.239.1464762027004; Tue, 31 May 2016 23:20:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.221.193 with HTTP; Tue, 31 May 2016 23:20:24 -0700 (PDT)
In-Reply-To: <3DC70DE0-FF05-4511-BCE2-2EC6A58C4407@mnot.net>
References:      <3DC70DE0-FF05-4511-BCE2-2EC6A58C4407@mnot.net>
From: Jana Iyengar 
Date: Tue, 31 May 2016 23:20:24 -0700
Message-ID: 
To: Mark Nottingham 
Content-Type: multipart/alternative; boundary=94eb2c0a7b684d3db50534317c2c
Archived-At: 
Cc: Tim Wicinski , Christian Huitema , "quic@ietf.org" 
Subject: Re: [QUIC] Draft charter
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Jun 2016 06:20:32 -0000

--94eb2c0a7b684d3db50534317c2c
Content-Type: text/plain; charset=UTF-8

Christian, Mark,

I'll start off by agreeing with Christian that QUIC is functionally
separable into "layers" (for lack of a better word). But this is not new.
Any transport that tries to separate application semantics from
network-level functions such as loss recovery and congestion control is
bound to be complex enough to be implementing these separable functions.
SCTP, SST, QUIC, are all good examples of this general idea, and that's
because these are all relatively complex transports. They are different
however in the boundaries that they collapse. (From this point of view,
QUIC is actually closer to SST than it is to SCTP.)

Bryan Ford and I did some transport decomposition work a while ago (you may
be familiar with it), and here's a section of an architectural draft we
wrote in 2009 that is relevant here:
https://tools.ietf.org/html/draft-iyengar-ford-tng-00#section-3.
Specifically, it separates the functions you mention into multiple
connection contexts, with multiple streams stacked on top of multiple
connection contexts.

So, it seems architecturally sensible (at least to me) to think about these
functions separately. That said, any protocol instantiation of these
functions will appropriately collapse these layering boundaries for
efficiency. The real question here is whether the particular set of
transport functions that QUIC implements and the set of "layering"
boundaries that QUIC collapses result in something powerful enough to be
useful and general enough to be extensible. In other words, IMO, the
question about QUIC ought to be whether it is specific enough to provide
performance benefits for particular applications, and general enough to
allow more applications to extend it in the future.

The answer to the first question is a resounding yes. We have running
deployed code and we have presented data about the benefits of QUIC for
HTTP traffic. The answer to the second question is something we'll only
know by trying. The charter is currently scoped to pursue the first
question first -- by building QUIC for HTTP as the first application. The
QUIC wg can and should continue chasing more application mappings after
HTTP, to see how general QUIC ends up being. If  QUIC falls short of a next
application that we thought might fit, that's an argument for either
refitting QUIC, or for building a different protocol that collapses these
functional boundaries differently, and maybe even chooses different
functional components. I think this is a perfectly reasonable outcome that
we should anticipate. DPRIVE or DNS may not fit on top of QUIC, and that's
fine (*).

I think this is also exactly how we should pursue new transport work at the
IETF. I would strongly argue against generalizing QUIC too much before
building it for HTTP. I am very wary of building a "kitchen-sink" transport
that tries to satisfy several applications at once. At the same time, I
would not start by strait-jacketing QUIC to be only for HTTP. The core
primitives are not going to be universally useful, but they will be
undoubtedly more generally useful than just for HTTP. The document division
in the charter captures this thinking, and I think that it's workable.

Just my thoughts.

(*) - In principle, I think you can do this though. QUIC, like SST, has
lightweight streams. You can map a transactional app by mapping a stream to
each transaction... and this has some really nice properties for the
application. But I don't want to rathole on designing QUIC for DNS here.

- jana







On Tue, May 31, 2016 at 7:03 PM, Mark Nottingham  wrote:

> Hi Christian,
>
> > On 1 Jun 2016, at 11:11 AM, Christian Huitema 
> wrote:
> >
> > I think that QUIC really has two layers. There is a bottom layer that
> manages the transmission of encrypted packets, the detection of errors, and
> possibly the forward error correction. Then there is an upper layer that
> manages the multiplexing of streams, and that cooperates with the bottom
> layer to manage retransmissions.
> >
> > Currently, the two layers are tied in multiple ways. The encryption
> layer cannot function without passing the stream 1 packets to the TLS
> machinery. The stream management frames share a number space with the error
> management frames. The per connection receive window is managed as the
> aggregate of the per stream receive window. But these are in fact simple
> problems, and it should be possible to disentangle the error detection
> layer and the stream management layer.
> >
> > After that, yes, there are quite a few possible innovations. The stream
> abstraction works well for HTTP 2.0, but I would rather use a
> transaction-based logic for DPRIVE, and maybe something different still for
> real-time multi-media. Or, if we think of multi-path, I could see a stream
> layer being multiplexed over two separate lower layers, managed as two
> separate connections.
> >
> > The whole point of defining a user mode transport is to enable this kind
> of innovation!
>
> This makes me wonder if QUIC is anything but a collection of functions
> that can be assembled by an application; as it is, the charter carves off
> crypto into TLS; FEC and congestion control are defined externally;
> multi-path is an extension. If streams are also optional, what's left? Loss
> recovery?
>
> I'm not against such a modular approach, but standardising it IMO will
> present some real challenges. Enough to make me wonder if just defining
> QUIC as HTTP/2-over-UDP is better; other applications could reuse its
> primitives as they like. It might not be as tidy, but it's a lot more
> workable...
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>

--94eb2c0a7b684d3db50534317c2c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Christian, Mark,

I'll start off by =
agreeing with Christian that QUIC is functionally separable into "laye=
rs" (for lack of a better word). But this is not new. Any transport th=
at tries to separate application semantics from network-level functions suc=
h as loss recovery and congestion control is bound to be complex enough to =
be implementing these separable functions. SCTP, SST, QUIC, are all good ex=
amples of this general idea, and that's because these are all relativel=
y complex transports. They are different however in the boundaries that the=
y collapse. (From this point of view, QUIC is actually closer to SST than i=
t is to SCTP.)

Bryan Ford and I did some transport=
 decomposition work a while ago (you may be familiar with it), and here'=
;s a section of an architectural draft we wrote in 2009 that is relevant he=
re: =C2=A0https://tools.ietf.org/html/draft-iyengar-ford-tng-00#section-3<=
/a>. Specifically, it separates the functions you mention into multiple con=
nection contexts, with multiple streams stacked on top of multiple connecti=
on contexts.


The answer to the first question is a resounding yes. We ha=
ve running deployed code and we have presented data about the benefits of Q=
UIC for HTTP traffic. The answer to the second question is something we'=
;ll only know by trying. The charter is currently scoped to pursue the firs=
t question first -- by building QUIC for HTTP as the first application. The=
 QUIC wg can and should continue chasing more application mappings after HT=
TP, to see how general QUIC ends up being. If =C2=A0QUIC falls short of a n=
ext application that we thought might fit, that's an argument for eithe=
r refitting QUIC, or for building a different protocol that collapses these=
 functional boundaries differently, and maybe even chooses different functi=
onal components. I think this is a perfectly reasonable outcome that we sho=
uld anticipate. DPRIVE or DNS may not fit on top of QUIC, and that's fi=
ne (*).



On Tue, May 31, 201=
6 at 7:03 PM, Mark Nottingham <mnot@mnot.net> wrote:
Hi Christian,



> On 1 Jun 2016, at 11:11 AM, Christian Huitema <huitema@microsoft.com> wrote:

>

> I think that QUIC really has two layers. There is a bottom layer that =
manages the transmission of encrypted packets, the detection of errors, and=
 possibly the forward error correction. Then there is an upper layer that m=
anages the multiplexing of streams, and that cooperates with the bottom lay=
er to manage retransmissions.

>

> Currently, the two layers are tied in multiple ways. The encryption la=
yer cannot function without passing the stream 1 packets to the TLS machine=
ry. The stream management frames share a number space with the error manage=
ment frames. The per connection receive window is managed as the aggregate =
of the per stream receive window. But these are in fact simple problems, an=
d it should be possible to disentangle the error detection layer and the st=
ream management layer.

>

> After that, yes, there are quite a few possible innovations. The strea=
m abstraction works well for HTTP 2.0, but I would rather use a transaction=
-based logic for DPRIVE, and maybe something different still for real-time =
multi-media. Or, if we think of multi-path, I could see a stream layer bein=
g multiplexed over two separate lower layers, managed as two separate conne=
ctions.

>

> The whole point of defining a user mode transport is to enable this ki=
nd of innovation!



This makes me wonder if QUIC is anything but a collection of functio=
ns that can be assembled by an application; as it is, the charter carves of=
f crypto into TLS; FEC and congestion control are defined externally; multi=
-path is an extension. If streams are also optional, what's left? Loss =
recovery?



I'm not against such a modular approach, but standardising it IMO will =
present some real challenges. Enough to make me wonder if just defining QUI=
C as HTTP/2-over-UDP is better; other applications could reuse its primitiv=
es as they like. It might not be as tidy, but it's a lot more workable.=
..



Cheers,



--

Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/




____________________________=
___________________

QUIC mailing list

QUIC@ietf.org

https://www.ietf.org/mailman/listinfo/quic





--94eb2c0a7b684d3db50534317c2c--