From ryan@optimism.us Sat Feb 1 08:15:18 2020 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 8010F120852 for ; Sat, 1 Feb 2020 08:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=optimism-cc.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 8QQpo0dFZ9qT for ; Sat, 1 Feb 2020 08:15:17 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 024851201DC for ; Sat, 1 Feb 2020 08:15:16 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id p23so11236611edr.5 for ; Sat, 01 Feb 2020 08:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=optimism-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NQzskgKOl1FjNVBMBQBhgL1paFLcJi513/lKTbKFS7I=; b=wc7TWV/AS8F3X2/MpN0mIYmWK2qCIfdOFTpLW6a2CpTh7enxKMdxL5R9DbUAr0pRE2 whxfdwHZ8QDmsPyfgLfhwj7X4uBF0EGQiKqR6X3FlmjSIpKy6FyG0dG464CTrFU2xwme yghIwKv4/a3IlDSWsChvt2SFwonODoMk2MpeI0nq5lWOuw3/B9Gch8EIcTXlYryZZCu0 PlowR2NwWxSBV1TzUoLBO2EfZPCYUt0Ok5RvnMwHJGdgSUCGpZgYon4N4ZI2Onhhu27N ayX/cdPUfHqJ+tO8IOZgqCj7fkRbM0psim+gKmb01/4rfAIr9ReWd9u2Nf+IblKI3yjh ztVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NQzskgKOl1FjNVBMBQBhgL1paFLcJi513/lKTbKFS7I=; b=XW9XyhxLohhR5Lqr6MXnMV8EXfXaoRh/hDyHkj9whjb5WcFWuuS0Z/4xQvJDgjWmBH cz0+EFnNjQXRDzLEuNd5F3pmGbUyx0XyLG770wnQrJufZhL2Y0hzYyntEXfugwmXoOXU c82XJzxawFCcLhJK2dj7eX14uNDKnAV4oezbPuNoC/sfBsmd8wfD9yWpZSjIUlu50esM 2rD7LYjdywlhHhdfVo/w255C/JuwmG7OSlJiGa2mDRPsjf7sI118iSXtxNBfrLl+SmHB 7fjep1lZb0RyUuduZO/sHmbZ/qYKEp+98KWZXi7PRbExF8p00yHgta2f5hvNcbPDjLJN eKlg== X-Gm-Message-State: APjAAAV4ZZweUF07R66QiiTyboSGgW03I+t3FjyqqhzXLwprJNdoviDQ ayVxlIkIgWRJvLEuCZtBVjRtDD81nSw32ldFa7msrdTtfu+vYw== X-Google-Smtp-Source: APXvYqyr14Fc9zQ/+OPzLGcohY16SPIeD/7CCcr8/m6OwMBy61Bc0Gea3mQolDMagfKf/dsfPq+4Fr7gZV0K1FzwJUA= X-Received: by 2002:a50:9e63:: with SMTP id z90mr5360994ede.306.1580573715285; Sat, 01 Feb 2020 08:15:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Hamilton Date: Sat, 1 Feb 2020 08:15:04 -0800 Message-ID: Subject: Re: [HTTP/3]Sending reserved frame before SETTINGS To: Renjie Tang Cc: quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000d75c23059d85fee0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 16:25:04 -0000 --000000000000d75c23059d85fee0 Content-Type: text/plain; charset="UTF-8" Wow, interesting question! 6.2.1 requires the SETTINGS frame to be first on the control frame: If the first frame of the control stream is any other frame type, this MUST be treated as a connection error of type H3_MISSING_SETTINGS. Whereas 7.2.9 says reserved frames have no semantic meaning: Frame types of the format "0x1f * N + 0x21" for integer values of N are reserved to exercise the requirement that unknown types be ignored (Section 9 ). These frames have no semantics, and can be sent on any open stream when application-layer padding is desired. This sounds like a conflict since something that has no semantics seems like it should not cause errors! However, looking Section 9 I think we find the resolution: Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. Implementations MUST discard frames and unidirectional streams that have unknown or unsupported types. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. However, where a known frame type is required to be in a specific location, such as the SETTINGS frame as the first frame of the control stream (see Section 6.2.1 ), an unknown frame type does not satisfy that requirement and SHOULD be treated as an error. So it seems that it's illegal to send a GREASED frame before the SETTINGS frame. Does that sound right to you? Cheers, Ryan On Fri, Jan 31, 2020 at 11:10 PM Renjie Tang wrote: > Hi all, > > When I was implementing greasing for HTTP/3 frames, I came across a > potential confusion. > > Presumably, if a non-reserved unknown frame is received before SETTINGS on > a control stream, the connection should be closed. > > But if a reserved frame is received before SETTINGS frame on a control > stream, does it count as an error and close the connection? Or should > it simply be ignored because it has no semantic meaning? > > Thanks! > Renjie > --000000000000d75c23059d85fee0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wow, interesting question!

6.2.1 requires the SETTINGS frame to be first on the control frame:
<= div class=3D"gmail_default" style=3D"font-family:trebuchet ms,sans-serif"><= br>
   If the firs=
t frame of the control stream is any other frame
   type, this MUST be treated as a connection error of type
   H3_MISSING_SETTINGS. 


   Frame types of the format "0=
x1f * N + 0x21" for integer values of N
   are reserved to exercise the requirement that unknown types be
   ignored (Section 9).  These frames have no semantics, and can be sent
   on any open stream when application-layer padding is desired.

This sounds= like a conflict since something that has no semantics seems like it should= not cause errors! However, looking Section 9 I think we find the resolutio= n:
   =
Implementations MUST ignore unknown or unsupported values in all
   extensible protocol elements.  Implementations MUST discard frames
   and unidirectional streams that have unknown or unsupported types.
   This means that any of these extension points can be safely used by
   extensions without prior arrangement or negotiation.  However, where
   a known frame type is required to be in a specific location, such as
   the SETTINGS frame as the first frame of the control stream (see
   Section 6.2.1), an unknown frame type does not satisfy that
   requirement and SHOULD be treated as an error.

So it seems that it's illeg=
al to send a GREASED frame before the SETTINGS frame. Does that sound right=
 to you?

Cheers,

Ryan

On Fri, Jan 31, 2020 at 11:10 PM Renjie Tang= <renjietang=3D40google.c= om@dmarc.ietf.org> wrote:
Hi all,

When I was imp= lementing greasing for HTTP/3 frames, I came across a potential confusion.<= /div>

Presumably, if a non-reserved unknown frame is rec= eived before SETTINGS on a control stream, the connection should be closed.=

But if a reserved frame is received before SETTIN= GS frame on a control stream, does it count as an error and close the conne= ction? Or should it=C2=A0simply be ignored because it has no semantic meani= ng?

Thanks!
Renjie
--000000000000d75c23059d85fee0-- From nobody Sat Feb 1 09:48:45 2020 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 EA3E41201DC for ; Sat, 1 Feb 2020 09:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 uzVVIpzW950l for ; Sat, 1 Feb 2020 09:48:42 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 4C8B2120147 for ; Sat, 1 Feb 2020 09:48:42 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id c9so12503736wrw.8 for ; Sat, 01 Feb 2020 09:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CdooW/xNUHeMGA9mZGD/aqASIkMpNqNTZ4mCL1ZlWnM=; b=t3A1lKQYCXPaqa8+Bl9LbN4+PBMhbE/OzJJvhiDF0GNZ7dMWp7P8Qs4updzpLnDkSG XgxQvzE1dCtZicOAXeDIBQPiPj0hDnL2jv7ya+6RYJXoLiNIVCsYR8155xgiOZB+oqbG vucIwpuWm+c2JUNgt49rw3cfZ8x/dG70MNL1KZF59KpL+adR+eelIqp5inQvnuMNNpio XXX6P6/rEqKugBSnIU3mSQUb/EVikrYVw5Mnnglz9gxfVyzuK+in3AL0a6+D49JbxQyb YGvPMys+wImJgEJ6XBx5Ix89+tUhzkqVaT64SZJh23kY7+vs2AmeKg9mfy81xZj0Gr7x U6+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=CdooW/xNUHeMGA9mZGD/aqASIkMpNqNTZ4mCL1ZlWnM=; b=F6u5M2rt22g+uMfr1FRB4sPQOqk6m6Av9jela+i2hJj1JboGntEjO8ZmN44zAN6oMI eVaYBp0Cz9ATDnO+U1ueCBTR5m7DE4sJ2Vm03UO7jmmNxgqr4AjX1dv0BTitGIjVxBWi snHgXWSdTXVfiY4TFSCOouGiJfMCGVz0LhtfyOUO0kCy74wQ8MnXq1ZF3XciDuUCQ8xt /i0JmYWI2k8DMY2quKgQZ/lBlixH1bg7HXy3kS+hYdYbSlWTIdM8NRUiQFS43DJGFvzn YJ0Rvyd8qG+UOeyq8gpCo+anjzTRsNaCKv5+eg5xnXNrkLCVOij/5L1MshB3bD0KMZ1a Vsww== X-Gm-Message-State: APjAAAV9PXCnnC9jXshIf7unyxPTaA5s2TgYTO0hEawzIcRQLqvYaueB hfHX0FhiOxk7mVg5joiS7OJhqO+kpfIf4+zJY2Y= X-Google-Smtp-Source: APXvYqx+0R+pm4H0JsrQPWBXaogdcEn2r0bTqZ9av0+So5UTHNfc5VOL2T/bctf1j/x3oZfCdFzrZvBkTdNz0Nz06ZU= X-Received: by 2002:adf:fe83:: with SMTP id l3mr675235wrr.41.1580579320822; Sat, 01 Feb 2020 09:48:40 -0800 (PST) MIME-Version: 1.0 References: <158031544568.2815.15754654508005430640.idtracker@ietfa.amsl.com> <20200129164358.GA18661@ubuntu-dmitri> In-Reply-To: From: Martin Duke Date: Sat, 1 Feb 2020 09:48:28 -0800 Message-ID: Subject: Re: Fwd: New Version Notification for draft-ietf-quic-load-balancers-01.txt To: Martin Duke , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000f4fff6059d874c42" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 17:48:44 -0000 --000000000000f4fff6059d874c42 Content-Type: text/plain; charset="UTF-8" Although now that I think about it, some test vectors are probably sufficient. I'll make some. On Wed, Jan 29, 2020, 8:49 AM Martin Duke wrote: > What I have in mind is something like QPACK interop - given a set of > parameters, implementers generate a series of CIDs and other teams try to > successfully extract the server id. But I'm certainly open to other ideas. > > On Wed, Jan 29, 2020 at 8:44 AM Dmitri Tikhonov < > dtikhonov@litespeedtech.com> wrote: > >> On Wed, Jan 29, 2020 at 08:41:16AM -0800, Martin Duke wrote: >> > https://github.com/martinduke/draft-duke-quic-load-balancers >> > >> > I'll be in Zurich if you would like to discuss. I would like to get an >> > interop/hackathon effort going in Vancouver, but would very much like >> > someone to take the lead on it. >> >> What do you think an LB interop/hackathon would look like? >> >> - Dmitri. >> > --000000000000f4fff6059d874c42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Although now that I think about it, some test vectors are= probably sufficient. I'll make some.

On Wed, Jan 29, 2020, 8:49 AM Mart= in Duke <martin.h.duke@gmail.= com> wrote:
What I have in mind is something like QPACK interop - given a set of param= eters, implementers generate a series of CIDs and other teams try to succes= sfully extract the server id. But I'm certainly open to other ideas.

On Wed, Jan 29, 2020 at 8:44 AM Dmitri Tikhonov <dtikhonov@lit= espeedtech.com> wrote:
On Wed, Jan 29, 2020 at 08:41:16AM -0800, Martin Duke wrote:<= br> > https://github.com/marti= nduke/draft-duke-quic-load-balancers
>
> I'll be in Zurich if you would like to discuss. I would like to ge= t an
> interop/hackathon effort going in Vancouver, but would very much like<= br> > someone to take the lead on it.

What do you think an LB interop/hackathon would look like?

=C2=A0 - Dmitri.
--000000000000f4fff6059d874c42-- From nobody Sat Feb 1 11:31:34 2020 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 167F7120180 for ; Sat, 1 Feb 2020 11:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=optimism-cc.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 qHHdniUHRaz7 for ; Sat, 1 Feb 2020 11:31:32 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 224A112007C for ; Sat, 1 Feb 2020 11:31:32 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id dc19so11554023edb.10 for ; Sat, 01 Feb 2020 11:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=optimism-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pUNeHgzsrI54H1VNLZyG3FF4sTIwAXU7aSDDUvJGT60=; b=Wv+1KunkNZ+jDRvGJMp2C+I3oBuwF9sYVkXVhUI5JRtVc1T1knL23WEO1QOAYDXR68 wW/88R3L1JEiQ/XSniPx9/7U2Urws3LUVgmW5g/252AALorEVxpKFckI5LeVCUu5Bls0 7/ObbBAORmqjrLHh21i9rBqQhnx+B79zC+e4jMw8p6LrwcQTmtxo8+fmUPCg+2awjFGB Qpny6s/CijOjH5p+WnTjvE/6WXux241u2VYTWnC0hN8j6UCwU11y9APPxvAbu+37xA8n TCrBl9w5rXip1oQEH3q6iGaO39iWcrd8XYk1Tt62bx9aFOlKPc/I/kMWo8plkpzNsv41 jvjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pUNeHgzsrI54H1VNLZyG3FF4sTIwAXU7aSDDUvJGT60=; b=CrUqh0dIOrpVmY1BbXymz5ptQ1deaLE2WtdT04Q2Mc/xbbAS94fI42CE0bLvFYtfnP WO0TvlRoHpjU6B44h70wbkRypuu8LV1uK7FggZh6o+9dkevDClwCq2EiduxPAgefswBg GkCxrODjcLM0Ug52bLtc3iVpBiomswe6yWhcUBphkjlgGD6PfCrn39CN949qqfnkwR0l SrVP/DWlWeQAtI6khNivKnIE7XTzaSnnpfgmBHS/mWNGTzTUlSz3EHZSijDUGiklwiz9 qb8QKYm3sT/NhvxZ/+Y//BlsXs9PwwAP0JP125V4CJUBz5hfgdSaRlKyal7boFR3Q9h4 FP0g== X-Gm-Message-State: APjAAAXCsv81eUAfMjEWbTNEZ7F106H3hrcxXmhCKsRqMsF2s919qGFF Dxky1l+J5mM+4/UyDe4gm0X7bc9kh1eqX5mcN24jcw== X-Google-Smtp-Source: APXvYqz8yR1oHAKy/kQcg+JJmAOxo42MT5Ej+tIhAkCTn5upnFly8cgh6IJhP5eYfrjtGYBTSCKYsLb+gxoKM3p/Iho= X-Received: by 2002:aa7:d8d6:: with SMTP id k22mr6008624eds.240.1580585490506; Sat, 01 Feb 2020 11:31:30 -0800 (PST) MIME-Version: 1.0 References: <3d2e70c1f581579a97124c31b096f0bda8b053b5.camel@ericsson.com> <269e8e73b792523247587725709c3e1fde7d0645.camel@ericsson.com> In-Reply-To: From: Ryan Hamilton Date: Sat, 1 Feb 2020 11:31:19 -0800 Message-ID: Subject: Re: Proposed Charter Text To: Jana Iyengar Cc: Magnus Westerlund , "ianswett@google.com" , "quic@ietf.org" , "mbishop@evequefou.be" , Mirja Kuehlewind , "fenix@fb.com" Content-Type: multipart/alternative; boundary="000000000000b2fc89059d88bcd9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 19:31:33 -0000 --000000000000b2fc89059d88bcd9 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 31, 2020 at 6:19 PM Jana Iyengar wrote: > Additionally, the Working Group will provide guidance on how to enable load >> balancers to handle QUIC traffic. >> > > SGTM. A minor rephrase: "Additionally, the Working Group will provide > guidance on how load balancers can be enabled to handle QUIC traffic." > That feels a bit clunky to me. What about: Additionally, the Working Group will provide guidance on how to handle QUIC traffic in load balancers. or: Additionally, the Working Group will provide guidance on how load balancers should handle QUIC traffic. --000000000000b2fc89059d88bcd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 31, 2020 at 6:19 PM Jana Iyengar <jri.ietf@gmail.com> wrote:
Additionally, the Working Group will provide = guidance on how to enable load
balancers to handle QUIC traffic.

SGTM. A mi= nor rephrase: "Additionally, the Working Group will provide guidance o= n how load balancers can be enabled to handle QUIC traffic."
=

That feels a bit clunky to me= . What about:


or:

Additionally, the Working Group will provide = guidance on how load balancers should handle QUIC traffic.
--000000000000b2fc89059d88bcd9-- From nobody Sat Feb 1 14:49:07 2020 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 61EEB120104 for ; Sat, 1 Feb 2020 14:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 F9I1Rq76wKkx for ; Sat, 1 Feb 2020 14:49:03 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 B1972120025 for ; Sat, 1 Feb 2020 14:49:02 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id y17so13055532wrh.5 for ; Sat, 01 Feb 2020 14:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gda+xlhfYpMR//DtnlKCWwFXujRvYWAIcdSZZ6RByWE=; b=AxljG8kcOefFKX7+ssTQpZ0PcV74Fkm0EXBSS6MQZU+3TcP+r8v9QlJkqzOb09cdaf 2oxCZyy8TwFQ2IqjjJJXMz4ks+B7bCzrTqMjybPW6UtA8pEKFGmCdLI0RImjMcmjeO3l mtkx2sLequLmMeeiVUXtJ7CFS/1a2ctwjxE4w52lfvN+yYvRTvixMf7k4UqiZ8rrDsWv HeS7rLh2m5DHWDqGfAT6g79XcFAETnYTBn3bhMJYHsPNDeoCXDgn5LJzlIE2+35ERnE7 ON0hWY5zv/QYiSMDEOC5J9aUudICtQpi55EJ9tEDdAuqABgFHJb8RgOwscfeZWJ3gHlS fACQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gda+xlhfYpMR//DtnlKCWwFXujRvYWAIcdSZZ6RByWE=; b=G+4Adlte7eeW5S1P5e/ehVu2ooaOyQwvaWzqPoU0qGQHFgtmrrA5a3FKiqrOijaOgX twG0A7KHLsEnLMW8zD5RXvv4Agkr5DmLubOjiquVqJYhUwlRk7PCT9OiDVBtpmOwXrmo qhSIeQ4jAQqoj1h1H6ouUaLMczlIV9+270fOQBFJZ4Y+iMepOQdizzlzqEy7EWIzYGOr hL2R0Nj8Ec15YzzmkZ9wfRZ4MsWRbGjxGcPgWgZKL+hmkN9lfALaCKKnP7qCkiKlRZO9 wKGvmfvtWOpcld0UCQf/I7czwPhlsl05X7BzABn7MoB1Z18qaR97NqyVH3Sm4WU1530T E5pA== X-Gm-Message-State: APjAAAXolXI6aKqDgB8sIxSKVRGMEdRtzKwF8nUoRmFCcuZ6faCnWjIL iI2g6JQ7P3ozg9XDFOHDRQ0i4B3fEp7kppAzlAfkCA+C X-Google-Smtp-Source: APXvYqxc8M9TRH8o9hVjToDuvioy4VTCUxonSObrhlwP8dqpm5Aatlwb8/4irY/aijzUlUXrH452+J5CR6eJHW/Y5/w= X-Received: by 2002:adf:8b59:: with SMTP id v25mr4498915wra.419.1580597340944; Sat, 01 Feb 2020 14:49:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Sat, 1 Feb 2020 17:48:48 -0500 Message-ID: Subject: Re: [HTTP/3]Sending reserved frame before SETTINGS To: Ryan Hamilton Cc: Renjie Tang , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000000aa531059d8b7fa8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 22:49:06 -0000 --0000000000000aa531059d8b7fa8 Content-Type: text/plain; charset="UTF-8" Thanks for bringing this up Renjie. I agree the subsequent text seems to clarify the answer. However, is that the behavior we want, given it does limit extensibility in some small ways? On Sat, Feb 1, 2020 at 11:25 AM Ryan Hamilton wrote: > Wow, interesting question! > > 6.2.1 requires the SETTINGS frame to be first on the control frame: > > If the first frame of the control stream is any other frame > type, this MUST be treated as a connection error of type > H3_MISSING_SETTINGS. > > > Whereas 7.2.9 says reserved frames have no semantic meaning: > > Frame types of the format "0x1f * N + 0x21" for integer values of N > are reserved to exercise the requirement that unknown types be > ignored (Section 9 ). These frames have no semantics, and can be sent > on any open stream when application-layer padding is desired. > > > This sounds like a conflict since something that has no semantics seems > like it should not cause errors! However, looking Section 9 I think we find > the resolution: > > Implementations MUST ignore unknown or unsupported values in all > extensible protocol elements. Implementations MUST discard frames > and unidirectional streams that have unknown or unsupported types. > This means that any of these extension points can be safely used by > extensions without prior arrangement or negotiation. However, where > a known frame type is required to be in a specific location, such as > the SETTINGS frame as the first frame of the control stream (see > Section 6.2.1 ), an unknown frame type does not satisfy that > requirement and SHOULD be treated as an error. > > > So it seems that it's illegal to send a GREASED frame before the SETTINGS frame. Does that sound right to you? > > > Cheers, > > > Ryan > > > On Fri, Jan 31, 2020 at 11:10 PM Renjie Tang 40google.com@dmarc.ietf.org> wrote: > >> Hi all, >> >> When I was implementing greasing for HTTP/3 frames, I came across a >> potential confusion. >> >> Presumably, if a non-reserved unknown frame is received before SETTINGS >> on a control stream, the connection should be closed. >> >> But if a reserved frame is received before SETTINGS frame on a control >> stream, does it count as an error and close the connection? Or should >> it simply be ignored because it has no semantic meaning? >> >> Thanks! >> Renjie >> > --0000000000000aa531059d8b7fa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for bringing this up Renjie.=C2=A0 I agree the subs= equent text seems to clarify the answer.

However, is tha= t the behavior we want, given it does limit extensibility in some small way= s?

On Sat, Feb 1, 2020 at 11:25 AM Ryan Hamilton <ryan@optimism.cc&= gt; wrote:
Wow, interesting question!

6.2.1 requires the SETTINGS frame to be fir= st on the control frame:

   If the first frame of the control stream is any other =
frame
   type, this MUST be treated as a connection error of type
   H3_MISSING_SETTINGS. 


   Frame =
types of the format "0x1f * N + 0x21" for integer values of N
   are reserved to exercise the requirement that unknown types be
   ignored (Section 9).  These frames have no semantic=
s, and can be sent
   on any open stream when application-layer padding is desired.

This sounds like a conflict since s= omething that has no semantics seems like it should not cause errors! Howev= er, looking Section 9 I think we find the resolution:
Implementations MUST ignore unknown or unsupport= ed values in all extensible protocol elements. Implementations MUST discard frames and unidirectional streams that have unknown or unsupported types. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. However, where a known frame type is required to be in a specific location, such as the SETTINGS frame as the first frame of the control stream (see Section 6.2.1), an unknown frame type does not= satisfy that requirement and SHOULD be treated as an error.

So i=
t seems that it's illegal to send a GREASED frame before the SETTINGS f=
rame. Does that sound right to you?

=

Ryan<=
/span>

On Fri, Jan 31, 2020 at 11:10 PM Renjie Tang <renjietang=3D<= a href=3D"mailto:40google.com@dmarc.ietf.org" target=3D"_blank">40google.co= m@dmarc.ietf.org> wrote:
Hi all,

When I was impl= ementing greasing for HTTP/3 frames, I came across a potential confusion.

Presumably, if a non-reserved unknown frame is rece= ived before SETTINGS on a control stream, the connection should be closed.<= /div>

But if a reserved frame is received before SETTING= S frame on a control stream, does it count as an error and close the connec= tion? Or should it=C2=A0simply be ignored because it has no semantic meanin= g?

Thanks!
Renjie
--0000000000000aa531059d8b7fa8-- From nobody Sat Feb 1 16:05:05 2020 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 BBC6B120137 for ; Sat, 1 Feb 2020 16:05:03 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ovTfUhrjm8KE for ; Sat, 1 Feb 2020 16:05:02 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 0F19B120132 for ; Sat, 1 Feb 2020 16:05:01 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 011Nw6jZ022588; Sun, 2 Feb 2020 00:04:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=Ri0RsPkP8DyDtMgOSv0jggU4dRpk6hCVQ6P6dE33nTc=; b=R2u1oJYbJHsb5a21Ir5aQaWzS/pOr8/eUFxEZOjs1MNV9fIiKpnSiV6LXiAmHg6RDMCG FK+vzY8zOi01E8TTjVHwvoLtzCpjdt5nsu3FxoziK41lIrE/jUsedhjv2ban8E/nr/rF nEJzt92yDbUVTp/3UEhgF9V8qq49mtr6LD5mWzIncjhuur4DIVVFdLPwmyUn/Z8+n9UJ 2D4cpdqBvGZIO4B5wx6p9BFTmV7PEwUwfz+F93/YcZ5e/co+cogcYrMHXriJ7PJ41H2X P9gZVziGgCHwOfafE8Sv5CaBmGEtbqqiuBQ459jr6hRuKuAiFoKV5m/JkP+BdjHILUFS YQ== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2xw79phxjv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 02 Feb 2020 00:04:52 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01202Mit028838; Sat, 1 Feb 2020 19:04:51 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint3.akamai.com with ESMTP id 2xw5j1kay0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 01 Feb 2020 19:04:50 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.165.123) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 1 Feb 2020 18:04:49 -0600 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.165.123]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.165.123]) with mapi id 15.00.1473.005; Sat, 1 Feb 2020 18:04:49 -0600 From: "Lubashev, Igor" To: Ryan Hamilton , Jana Iyengar CC: Magnus Westerlund , "ianswett@google.com" , "fenix@fb.com" , "mbishop@evequefou.be" , Mirja Kuehlewind , "quic@ietf.org" Subject: RE: Proposed Charter Text Thread-Topic: Proposed Charter Text Thread-Index: AQHV1QxjvPDTcWegp0eJWJe1gsp2N6f6YuYAgAQt/wCAACJd4P//zegAgACGTeCAADI6gIACdxsAgAFB+ACAABI8AIABLVcAgAEiloCAALFVgIABIJWA///mNLA= Date: Sun, 2 Feb 2020 00:04:48 +0000 Message-ID: <280f20c36a504d1a9fb7ce651cadd8f7@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <3d2e70c1f581579a97124c31b096f0bda8b053b5.camel@ericsson.com> <269e8e73b792523247587725709c3e1fde7d0645.camel@ericsson.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.80.235] Content-Type: multipart/alternative; boundary="_000_280f20c36a504d1a9fb7ce651cadd8f7ustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-01_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=831 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002010179 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-01_08:2020-01-31, 2020-02-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0 phishscore=0 mlxlogscore=803 mlxscore=0 bulkscore=0 priorityscore=1501 clxscore=1011 malwarescore=0 impostorscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2002010178 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 00:05:04 -0000 --_000_280f20c36a504d1a9fb7ce651cadd8f7ustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogUnlhbiBIYW1pbHRvbiA8cnlhbkBvcHRpbWlzbS5jYz4NCg0KT24gRnJpLCBKYW4gMzEs IDIwMjAgYXQgNjoxOSBQTSBKYW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 anJpLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpBZGRpdGlvbmFsbHksIHRoZSBXb3JraW5nIEdy b3VwIHdpbGwgcHJvdmlkZSBndWlkYW5jZSBvbiBob3cgdG8gZW5hYmxlIGxvYWQNCmJhbGFuY2Vy cyB0byBoYW5kbGUgUVVJQyB0cmFmZmljLg0KDQpTR1RNLiBBIG1pbm9yIHJlcGhyYXNlOiAiQWRk aXRpb25hbGx5LCB0aGUgV29ya2luZyBHcm91cCB3aWxsIHByb3ZpZGUgZ3VpZGFuY2Ugb24gaG93 IGxvYWQgYmFsYW5jZXJzIGNhbiBiZSBlbmFibGVkIHRvIGhhbmRsZSBRVUlDIHRyYWZmaWMuIg0K DQpUaGF0IGZlZWxzIGEgYml0IGNsdW5reSB0byBtZS4uIFdoYXQgYWJvdXQ6DQoNCkFkZGl0aW9u YWxseSwgdGhlIFdvcmtpbmcgR3JvdXAgd2lsbCBwcm92aWRlIGd1aWRhbmNlIG9uIGhvdyB0byBo YW5kbGUgUVVJQyB0cmFmZmljIGluIGxvYWQgYmFsYW5jZXJzLg0KDQpvcjoNCg0KQWRkaXRpb25h bGx5LCB0aGUgV29ya2luZyBHcm91cCB3aWxsIHByb3ZpZGUgZ3VpZGFuY2Ugb24gaG93IGxvYWQg YmFsYW5jZXJzIHNob3VsZCBoYW5kbGUgUVVJQyB0cmFmZmljLg0KDQpPcjoNCkFkZGl0aW9uYWxs eSwgdGhlIFdvcmtpbmcgR3JvdXAgd2lsbCBwcm92aWRlIGd1aWRhbmNlIG9uIGhvdyBsb2FkIGJh bGFuY2VycyBzaG91bGQgaW50ZXJvcGVyYXRlIHdpdGggUVVJQyBzZXJ2ZXJzLg0KDQpPcjoNCkFk ZGl0aW9uYWxseSwgdGhlIFdvcmtpbmcgR3JvdXAgd2lsbCBwcm92aWRlIGd1aWRhbmNlIG9uIGlu dGVyb3BlcmF0aW9uIG9mIGxvYWQgYmFsYW5jZXJzIGFuZCBRVUlDIHNlcnZlcnMuDQoNCg== --_000_280f20c36a504d1a9fb7ce651cadd8f7ustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2Ut MToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFJ5YW4gSGFt aWx0b24gJmx0O3J5YW5Ab3B0aW1pc20uY2MmZ3Q7IDxicj4NCjxicj4NCjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5PbiBGcmksIEphbiAzMSwgMjAyMCBhdCA2 OjE5IFBNIEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaS5pZXRmQGdtYWlsLmNv bSI+anJpLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRkaXRpb25hbGx5LCB0 aGUgV29ya2luZyBHcm91cCB3aWxsIHByb3ZpZGUgZ3VpZGFuY2Ugb24gaG93IHRvIGVuYWJsZSBs b2FkPGJyPg0KYmFsYW5jZXJzIHRvIGhhbmRsZSBRVUlDIHRyYWZmaWMuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNHVE0uIEEgbWlub3IgcmVw aHJhc2U6ICZxdW90O0FkZGl0aW9uYWxseSwgdGhlIFdvcmtpbmcgR3JvdXAgd2lsbCBwcm92aWRl IGd1aWRhbmNlIG9uIGhvdyBsb2FkIGJhbGFuY2VycyBjYW4gYmUgZW5hYmxlZCB0byBoYW5kbGUg UVVJQyB0cmFmZmljLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+VGhhdCBmZWVscyBh IGJpdCBjbHVua3kgdG8gbWUuLiBXaGF0IGFib3V0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVm dDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDss c2Fucy1zZXJpZiI+QWRkaXRpb25hbGx5LCB0aGUgV29ya2luZyBHcm91cCB3aWxsIHByb3ZpZGUg Z3VpZGFuY2Ugb24gaG93IHRvIGhhbmRsZSBRVUlDIHRyYWZmaWMgaW4gbG9hZCBiYWxhbmNlcnMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPm9yOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+QWRkaXRpb25hbGx5LCB0aGUgV29y a2luZyBHcm91cCB3aWxsIHByb3ZpZGUgZ3VpZGFuY2Ugb24gaG93IGxvYWQgYmFsYW5jZXJzIHNo b3VsZCBoYW5kbGUgUVVJQyB0cmFmZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Pcjo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluIj5B ZGRpdGlvbmFsbHksIHRoZSBXb3JraW5nIEdyb3VwIHdpbGwgcHJvdmlkZSBndWlkYW5jZSBvbiBo b3cgbG9hZCBiYWxhbmNlcnMgc2hvdWxkIGludGVyb3BlcmF0ZSB3aXRoIFFVSUMgc2VydmVycy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9yOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4i PkFkZGl0aW9uYWxseSwgdGhlIFdvcmtpbmcgR3JvdXAgd2lsbCBwcm92aWRlIGd1aWRhbmNlIG9u IGludGVyb3BlcmF0aW9uIG9mIGxvYWQgYmFsYW5jZXJzIGFuZCBRVUlDIHNlcnZlcnMuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_280f20c36a504d1a9fb7ce651cadd8f7ustx2exdag1mb5msgcorpak_-- From nobody Sat Feb 1 23:32:34 2020 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 A769E1200FD for ; Sat, 1 Feb 2020 23:32:32 -0800 (PST) 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 (2048-bit key) header.d=mnot.net header.b=RdNV70f8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cb40dCPG 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 O7JYeaQT5stR for ; Sat, 1 Feb 2020 23:32:30 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC20120045 for ; Sat, 1 Feb 2020 23:32:29 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id DBA053AC for ; Sun, 2 Feb 2020 02:32:28 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 02 Feb 2020 02:32:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=ho6LjNt6/lWYJeXnEN4xfeaqYhNrmBhTk4lfKXNwvzQ=; b=RdNV70f8 oRnmb91m4/z+yOimw8dUIQX7jSt7AOAUYIytW2jQRt+XgcmkMnjSh0cqxIjBUgwk jqx4oj5RWOug74jRTgW4J6Ml+OA/6K9OAcFi9gm5VlED1a5nzoAiRLhOEnP/dVuR 2gTEvBm4xvcbTME3P82vzqqzQXMSTA/HhYN4m8xtprLLd7+cOEOWUmo9k2GaP1Z9 LrK7l8iQJ0u3OFermWoML//cHGbDq3GAQKxm5IUk4GzSKyb95zCXtAc23c6KxtB9 +DN0fe+50zlqleufEs7EYgOUFokwQmLTUdCretnsZa6g1IWiCN6E2JwdZY0nxf8i BjoREUxtlF0SGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ho6LjNt6/lWYJeXnEN4xfeaqYhNrm BhTk4lfKXNwvzQ=; b=cb40dCPGU5f2QMS7ATR41IQ1mwx0BRjfpO612zlgDOnUg 1TETSRh/slR62bCN0tTQYoALUPq71Fk5QQP13+JwdSZIWZmHi90R4JMPVDnz6KMa X2z+wki6OdwIHsbkZ5g6RXTf4HbnHnA3rulJR+DTAmPkOTBHGJI4Jqv3UytQG0l+ /rxApFSIOgd166rgAaDnOf/gd+JE1um8/oOvgTP2d9uuWmgZBbIgUOgHU1k5DSEt H36z7HtOkMONariJfhm+DMwWV75kYRjV9PEpKbPC31z1ImED2NI33j9FknSaML3l GdJ97x0VVm7FIoLOu8uU56KWAULtplTzpxTHzY2JA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrgeeggddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppeegtddruddujedrvdefjedrvdegudenucevlhhushht vghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.117.237.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 19ABA3280059 for ; Sun, 2 Feb 2020 02:32:28 -0500 (EST) Content-Type: multipart/alternative; boundary="===============4748211002916092283==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: quic@ietf.org Subject: Weekly github digest (QUIC Activity Summary) Message-Id: <20200202073228.19ABA3280059@mailuser.nyi.internal> Date: Sun, 2 Feb 2020 02:32:28 -0500 (EST) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 07:32:32 -0000 --===============4748211002916092283== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+2/-0/=F0=9F=92=AC18) 2 issues created: - Does minimal encoding apply to extensions? (by dtikhonov) https://github.com/quicwg/base-drafts/issues/3402=20 - Server cannot proceed after invalid Retry token (by dtikhonov) https://github.com/quicwg/base-drafts/issues/3396=20 8 issues received 18 new comments: - #3402 Does minimal frame type encoding apply to extensions? (4 by LPard= ue, MikeBishop, dtikhonov) https://github.com/quicwg/base-drafts/issues/3402=20 - #3396 Server cannot proceed after invalid Retry token (4 by MikeBishop,= kazuho, martinthomson) https://github.com/quicwg/base-drafts/issues/3396 [-transport]=20 - #3357 Only send one immediate ACK after reordering (2 by gorryfair, ian= swett) https://github.com/quicwg/base-drafts/issues/3357 [-transport] [design]= =20 - #3333 Padding outside QUIC packet (2 by Lekensteyn, ekr) https://github.com/quicwg/base-drafts/issues/3333 [-transport]=20 - #3304 ACK generation recommendation (2 by gorryfair, ianswett) https://github.com/quicwg/base-drafts/issues/3304 [-transport] [design]= =20 - #2817 Guidance for propogation of errors between H2 and H3 (1 by LPardu= e) https://github.com/quicwg/base-drafts/issues/2817 [-http] [design]=20 - #2387 Write up our security target against on-path attack (2 by janaiye= ngar, martinthomson) https://github.com/quicwg/base-drafts/issues/2387 [-transport] [design]= [proposal-ready]=20 - #2143 Be more conservative about migration? (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2143 [-transport] [design]= =20 Pull requests ------------- * quicwg/base-drafts (+6/-2/=F0=9F=92=AC4) 6 pull requests submitted: - Clarify that minimal varint encoding applies to ALL frame types (by dti= khonov) https://github.com/quicwg/base-drafts/pull/3403=20 - Add forward references to packet number spaces (by dtikhonov) https://github.com/quicwg/base-drafts/pull/3401=20 - Fix #2719: replace defunct "both conditions" verbiage (by dtikhonov) https://github.com/quicwg/base-drafts/pull/3400=20 - Fix typo in transport draft (by dtikhonov) https://github.com/quicwg/base-drafts/pull/3399=20 - Fix: server cannot proceed to handshake when given an invalid Retry tok= en (by dtikhonov) https://github.com/quicwg/base-drafts/pull/3398=20 - Add PR 3139 to the list of changes in transport-25 (by dtikhonov) https://github.com/quicwg/base-drafts/pull/3397=20 3 pull requests received 4 new comments: - #3398 Fix: server cannot proceed to handshake when given an invalid Ret= ry token (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/3398 [-transport] [design]=20 - #3232 Limit CWND increase in slow start (2 by goelvidhi, janaiyengar) https://github.com/quicwg/base-drafts/pull/3232 [-recovery] [design]=20 - #3129 Clients can send GOAWAY too (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/3129 [-http] [design]=20 2 pull requests merged: - Fix typo in transport draft https://github.com/quicwg/base-drafts/pull/3399=20 - Add PR 3139 to the list of changes in transport-25 https://github.com/quicwg/base-drafts/pull/3397=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============4748211002916092283== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Activity Summary)

Sunday February 02, 2020

Events without label "editorial"

Issues

quicwg/base-drafts (+2/-0/=F0=9F=92=AC18)

2 issues created:

8 issues received 18 new comments:

Pull requests

quicwg/base-drafts (+6/-2/=F0=9F=92=AC4)

6 pull requests submitted:

3 pull requests received 4 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============4748211002916092283==-- From nobody Sun Feb 2 03:34:43 2020 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 93734120044 for ; Sun, 2 Feb 2020 03:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 wUHLnh_53Hos for ; Sun, 2 Feb 2020 03:34:40 -0800 (PST) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 B673312003E for ; Sun, 2 Feb 2020 03:34:40 -0800 (PST) Received: by mail-vk1-xa2d.google.com with SMTP id w67so3355784vkf.1 for ; Sun, 02 Feb 2020 03:34:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZIGIiv8TJ1ZBJ71jDIwJ6lmg+ZlVUII2viEz6MxVUUI=; b=s/QA/GPZ+CJd1AFKi+KRHW44D3v8GicNYUltU7g9i3N3wLJpLDb5jlCFAHPfURQHLB OSxk3X04NR8DMUFBeqZbDGeeYCLEnhrWwm40JDZXDQ/YE10hYkKzN0qLAv92Aae0Qs1M AtN9d12r1jexGFiW+5BiPB41tXkCspmCv+bEWFWk0qSyIqpWyhe3/8wQX3V8nHsApVkI 9pTQbPDFGntocp3w2RFhNO4s4LZzIhKQjudmr5rQ1kse/Jcu6t5neQWfED2U6oT0TStS vEblNhbzq18c7JQVBAKQ8GAIO6qYLREh48t6rmnbBsqf74TWYT8OmEEHf4n3qWkG6czE YdPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZIGIiv8TJ1ZBJ71jDIwJ6lmg+ZlVUII2viEz6MxVUUI=; b=MNQ9X6sPCRVmOVfYmlewOub6GhkDX16uMf7UzyKi6sGTQvvC4OxTZz2xoAUpA+Vx4h Z8GWGIlR8Qc6cD2B//QfIzgZ0fKpGUpNP9B7VZKPGodPisTA2iz8Gpr6L10zla0fEOV0 BAysO9reoFSk0jSFP79lFukdxRiQENJ00RLQQXVXN2/D78Dme0ilmWRpu9Pam7pW2wwF nSzQf+oiixVPw7AhfN07VspKOOelsHLeQa6vmysQms49bLFOpkiDh/rh3MvzKWhIrDZL faZkv/D7I9gMh/mYvFwi+yJuIb92bvel5X97HWuC7KnviEfm8Wt/wy/RZRrliSjBnws3 LSDQ== X-Gm-Message-State: APjAAAUYLeIrF9Wk6KHvBZWphWzkKytPwNZ1tnQr8YABuTmU08tTALv3 OP3z6TtBWra0RUoLY5/g3GazqrodSAjUJi1iLb/vmQ== X-Google-Smtp-Source: APXvYqyK+jbun9M5KJVMW0b2wXETc5x/0zAQNNWIBX1RY/vkW+ePUVTta3v8snZdOc1XEdNynTlvN3LH+UuKUqEej9k= X-Received: by 2002:a1f:7d43:: with SMTP id y64mr11207325vkc.15.1580643279746; Sun, 02 Feb 2020 03:34:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Pardue Date: Sun, 2 Feb 2020 11:34:27 +0000 Message-ID: Subject: Re: [HTTP/3]Sending reserved frame before SETTINGS To: Ian Swett Cc: Ryan Hamilton , IETF QUIC WG , Renjie Tang Content-Type: multipart/alternative; boundary="00000000000034b93d059d9631e5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 11:34:43 -0000 --00000000000034b93d059d9631e5 Content-Type: text/plain; charset="UTF-8" I think the design of this is ok as is. On Sat, 1 Feb 2020, 22:49 Ian Swett, wrote: > Thanks for bringing this up Renjie. I agree the subsequent text seems to > clarify the answer. > > However, is that the behavior we want, given it does limit extensibility > in some small ways? > > On Sat, Feb 1, 2020 at 11:25 AM Ryan Hamilton wrote: > >> Wow, interesting question! >> >> 6.2.1 requires the SETTINGS frame to be first on the control frame: >> >> If the first frame of the control stream is any other frame >> type, this MUST be treated as a connection error of type >> H3_MISSING_SETTINGS. >> >> >> Whereas 7.2.9 says reserved frames have no semantic meaning: >> >> Frame types of the format "0x1f * N + 0x21" for integer values of N >> are reserved to exercise the requirement that unknown types be >> ignored (Section 9 ). These frames have no semantics, and can be sent >> on any open stream when application-layer padding is desired. >> >> >> This sounds like a conflict since something that has no semantics seems >> like it should not cause errors! However, looking Section 9 I think we find >> the resolution: >> >> Implementations MUST ignore unknown or unsupported values in all >> extensible protocol elements. Implementations MUST discard frames >> and unidirectional streams that have unknown or unsupported types. >> This means that any of these extension points can be safely used by >> extensions without prior arrangement or negotiation. However, where >> a known frame type is required to be in a specific location, such as >> the SETTINGS frame as the first frame of the control stream (see >> Section 6.2.1 ), an unknown frame type does not satisfy that >> requirement and SHOULD be treated as an error. >> >> >> So it seems that it's illegal to send a GREASED frame before the SETTINGS frame. Does that sound right to you? >> >> >> Cheers, >> >> >> Ryan >> >> >> On Fri, Jan 31, 2020 at 11:10 PM Renjie Tang > 40google.com@dmarc.ietf.org> wrote: >> >>> Hi all, >>> >>> When I was implementing greasing for HTTP/3 frames, I came across a >>> potential confusion. >>> >>> Presumably, if a non-reserved unknown frame is received before SETTINGS >>> on a control stream, the connection should be closed. >>> >>> But if a reserved frame is received before SETTINGS frame on a control >>> stream, does it count as an error and close the connection? Or should >>> it simply be ignored because it has no semantic meaning? >>> >>> Thanks! >>> Renjie >>> >> --00000000000034b93d059d9631e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the design of this is ok as is.

On Sat, 1 Feb 2020= , 22:49 Ian Swett, <ianswett=3D40google.com@dmarc.ietf.org> wrote:
Thanks for bringing this up Renjie.=C2=A0 I = agree the subsequent text seems to clarify the answer.

H= owever, is that the behavior we want, given it does limit extensibility in = some small ways?

On Sat, Feb 1, 2020 at 11:25 AM Ryan Hamilton <rya= n@optimism.cc> wrote:
Wow, interesting q= uestion!

6.2.1 requires the SETTINGS= frame to be first on the control frame:

   If the first frame of the control strea=
m is any other frame
   type, this MUST be treated as a connection error of type
   H3_MISSING_SETTINGS. 


   Frame =
types of the format "0x1f * N + 0x21" for integer values of N
   are reserved to exercise the requirement that unknown types be
   ignored (Section 9).  These fram=
es have no semantics, and can be sent
   on any open stream when application-layer padding is desired.

This sounds like a conflict since s= omething that has no semantics seems like it should not cause errors! Howev= er, looking Section 9 I think we find the resolution:
Implementations MUST ignore unknown or unsupport= ed values in all extensible protocol elements. Implementations MUST discard frames and unidirectional streams that have unknown or unsupported types. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. However, where a known frame type is required to be in a specific location, such as the SETTINGS frame as the first frame of the control stream (see Section 6.2.1), an unknown= frame type does not satisfy that requirement and SHOULD be treated as an error.

So i=
t seems that it's illegal to send a GREASED frame before the SETTINGS f=
rame. Does that sound right to you?

=

Ryan<=
/span>

On Fri, Jan 31, 2020 at 11:10 PM Renjie Tang <renjietang=3D<= a href=3D"mailto:40google.com@dmarc.ietf.org" target=3D"_blank" rel=3D"nore= ferrer">40google.com@dmarc.ietf.org> wrote:
Hi all,

<= div>When I was implementing greasing for HTTP/3 frames, I came across a pot= ential confusion.

Presumably, if a non-reserved un= known frame is received before SETTINGS on a control stream, the connection= should be closed.

But if a reserved frame is rece= ived before SETTINGS frame on a control stream, does it count as an error a= nd close the connection? Or should it=C2=A0simply be ignored because it has= no semantic meaning?

Thanks!
Renjie
--00000000000034b93d059d9631e5-- From nobody Sun Feb 2 09:59:17 2020 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 52B28120033 for ; Sun, 2 Feb 2020 09:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4NEkWTHwl8G for ; Sun, 2 Feb 2020 09:59:14 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 C3C0812012D for ; Sun, 2 Feb 2020 09:59:13 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id f25so12177349ljg.12 for ; Sun, 02 Feb 2020 09:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N1r28hkvj+idym7UyosuovmlZ1he+7xPqkyC76Rv1CE=; b=rq2g+nSRObTNc8S21A8lgOrYAJPLA+Znq/W2OUNLnGQzyu+IIKTHAzZHbYHQCLs0KP m6tqbJhzf1rpbOdZhsACdsjacqnrs1mlLbFGGFjQ5YkQmEoefdmgq4Jkwv7YVmpWuRnO kW0NQ3AzGyqEcgsTLzODt2Y7A1wPxsWur7tD5KzNvHVwYSTDyn2+7sMr0vgJGrxgFQEt xlYlkkdu+0/r8oXwXCpUgsN+iXwE5yvuUNQ4xwjx7Yv7Hdi3Gvokjn9cLW4Mx9kOs4TG RsDWuVgIiqrMnmGaq+0LdQkQvVMgAO1a+UjxPej5A/DVebM0Uu0TTttKzOfRDYfUapgp eXtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N1r28hkvj+idym7UyosuovmlZ1he+7xPqkyC76Rv1CE=; b=GkhZyAeQwi1ODsI/oFaqGBt7ew/KwVGjqYLm5BnDDn7x8achzLXG4qLrL5WUb+5Ttl ZBc5ewaoTUTjekSUewX3q5/pPxr2rb1BRE06UPa5d7EAYha/ke1dcMz3ZhZhDmzKM3nc cUox5/NcYSgDPCPj82kExaPFmmNEheQ+YtN1velIS3kVdTR91Y4yyovZGDnmuvtLvxtj MvYTMPaTUDWa/DL38fKAsKHF7QYQ51rI4kBrF6hNu66wMYebGTj6sQ9xSLtc6Rm0Jzvl 63FkuIlo9ZaAFczePOQUYt2anVZyqppjokJK3KOQZ+FugqIz7bn1RqKqlpAZZMhe3vyB gztQ== X-Gm-Message-State: APjAAAVn1vhum53C7LReFIPLUxqdU6a5Vn0CovRLceWsb52XutABII4K WQnPxbnPz1lVu/v9Nyz0eH5XV+6pgskZmdxakfs= X-Google-Smtp-Source: APXvYqxIO54eiX+/CmJ0Dlb0mfg51lI5GUoyDZFNVVV2Z6EK8ymB0ulkdVIJJ8iA3xLtAeCavo9HkjSPsvdojxOFjc0= X-Received: by 2002:a2e:9207:: with SMTP id k7mr11620174ljg.175.1580666351918; Sun, 02 Feb 2020 09:59:11 -0800 (PST) MIME-Version: 1.0 References: <3d2e70c1f581579a97124c31b096f0bda8b053b5.camel@ericsson.com> <269e8e73b792523247587725709c3e1fde7d0645.camel@ericsson.com> In-Reply-To: From: Jana Iyengar Date: Sun, 2 Feb 2020 18:59:00 +0100 Message-ID: Subject: Re: Proposed Charter Text To: Ryan Hamilton Cc: Magnus Westerlund , "ianswett@google.com" , "quic@ietf.org" , "mbishop@evequefou.be" , Mirja Kuehlewind , "fenix@fb.com" Content-Type: multipart/alternative; boundary="0000000000006a2398059d9b906b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 17:59:15 -0000 --0000000000006a2398059d9b906b Content-Type: text/plain; charset="UTF-8" On Sat, Feb 1, 2020 at 11:31 AM Ryan Hamilton wrote: > On Fri, Jan 31, 2020 at 6:19 PM Jana Iyengar wrote: > >> Additionally, the Working Group will provide guidance on how to enable >>> load >>> balancers to handle QUIC traffic. >>> >> >> SGTM. A minor rephrase: "Additionally, the Working Group will provide >> guidance on how load balancers can be enabled to handle QUIC traffic." >> > > That feels a bit clunky to me. What about: > > Additionally, the Working Group will provide guidance on how to handle > QUIC traffic in load balancers. > > > or: > > Additionally, the Working Group will provide guidance on how load > balancers should handle QUIC traffic. > > That sounds fine to me too, module the recognition that IETF-weary eyes might read should as a recommendation rather than as solutions. But, this reads fine to me. --0000000000006a2398059d9b906b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Feb 1, 2020 at 11:31 AM Ryan Hami= lton <ryan@optimism.cc> wrote:
On Fri, Jan 31, 2020 at 6:19 PM Jana Iyengar <jri.ietf@gmail.com= > wrote:
Additionally, the Wo= rking Group will provide guidance on how to enable load
balancers to handle QUIC traffic.

SGTM. A mi= nor rephrase: "Additionally, the Working Group will provide guidance o= n how load balancers can be enabled to handle QUIC traffic."
=

That feels a bit clunky to me. What about:

<= blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">
Additionally, the Working Group will provide guidance on how to ha= ndle QUIC traffic in load balancers.

o= r:

=
Additionally, the Working Group will provide guidance= on how load balancers should handle QUIC traffic.
=

That sounds fine to me too, module t= he recognition that IETF-weary eyes might read should as a recommendation r= ather than as solutions. But, this reads fine to me.
=C2=A0
=
--0000000000006a2398059d9b906b-- From nobody Mon Feb 3 04:24:27 2020 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 781D0120071 for ; Mon, 3 Feb 2020 04:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 K2MQTcL8FnPW for ; Mon, 3 Feb 2020 04:24:23 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 6CDDD12001B for ; Mon, 3 Feb 2020 04:24:23 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id b17so16786114wmb.0 for ; Mon, 03 Feb 2020 04:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=fQUUjP/8VWgYj6hWsWekVRiyQqRzr+jWQKbSB3KUsTk=; b=tFHAYLi2r1i5vc2+m5EfyvfvfCvo57pFc+Rk4kKI1ZJFkWqXARMVpu3bLtrgCFxz9A VCYqLxVxotDIx7ql0uanBjUuY5mxp8oGi38BYlX74mo1ZvJ3KvPXRUp3J+7uhWrptG6F LN2+BMfFkgV70sWC6QfTSHuQY00MHZ5u5g0bf3hey8aYlTOrlGuPVDCMwwWRAbQm3zQH bJ6xkECcq0GxpHe6ssvCAOX3ZFy8ydpfWjrP+k+VKd8RDYUVAUJHGfgZZh1+CbA5jDL/ ZjhciPfWFMvyFPNCaZ27dqh42tH5MEmOv2xvTC7fhuN5Y6B7Ipp/j/ukwSlJ4VU3+5OW Vg7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fQUUjP/8VWgYj6hWsWekVRiyQqRzr+jWQKbSB3KUsTk=; b=PwvHJm6yNQZuXUhZISpHSB97pio49pS9L1goXriTuT3CpWMIOuknGkYzhmfPKOpvRC GDfDLLpUf2hlyBy1z3ns5yKnvNkchWgE6XzH8IPdqO6EhUt2GGV+s132bBnhrcgNgTsY epXHug9/GkW3OEcZ65hz/lclzZIeeFdeKZq+UgC7I21ZWYCxCyBvNCGy27rvqwFBEb4X onl60TZEU7LK4LNLkB4Y1VA8MNkkOesrCaWCnxNM/PT0+yejzn2J8WtnUxugPeLcH3Y3 5p8UQsJ/4oCXvlAMNWyf9MNwFXkESX2XInQep75uYEfSz2smjWFJiA9E/uAiu6t/f/uy ZBEw== X-Gm-Message-State: APjAAAUwJDk0ix2kkB3o1pVK4Te7hqV2WloaiXqjrydxHMLvBLctDb5E aCIi+FMaIkhtSnDegL6uUyuWePh+Gg8rSpGrV6TddIwozcU= X-Google-Smtp-Source: APXvYqxg2hyMYbGmBd/8NXNoQcARZpP9s6xfJwMcFyMWXIiojj14f2xx20Gld/QopdMnpd/ltWajkl1jPbhZakf7Vmo= X-Received: by 2002:a05:600c:21ce:: with SMTP id x14mr28488630wmj.120.1580732654066; Mon, 03 Feb 2020 04:24:14 -0800 (PST) MIME-Version: 1.0 From: Ian Swett Date: Mon, 3 Feb 2020 07:24:01 -0500 Message-ID: Subject: An alternate solution to prevent handshake deadlocks To: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000055166c059dab00cc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 12:24:26 -0000 --00000000000055166c059dab00cc Content-Type: text/plain; charset="UTF-8" At the New York interim, there was substantial discussion around how to prevent a handshake deadlock when the server hits the amplification limit.( #1764 ) At the time, the only clear solution was to force the client to continue sending Initial or Handshake packets, even if it had nothing to send in them.(#1862 ) A few months ago, I realized there is an alternate solution which is simpler, at least for my implementation. This is for the server to send a packet only containing a PING when it becomes limited by the amplification factor. This elicits an Initial(always full-sized or Handshake(provides address confirmation) packet from the client, unblocking the server. It does slightly increase network load, but it's less than a single full-sized packet due to exponential backoff. Only a few people looked at this change(#3162 ) closely, with no clear consensus, so I'd like to get more input, so the WG can decide on how to proceed with the design issue I filed(#3161 ), possibly with no action. Thanks, Ian --00000000000055166c059dab00cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At the New York interim, there was substantial discussion= =C2=A0around how to prevent a handshake deadlock when the server hits the a= mplification=C2=A0limit.(#1764)

At the time, the only clear solut= ion was to force the client to continue sending Initial or Handshake packet= s, even if it had nothing to send in them.(#1862)

A few month= s ago, I realized there is an alternate solution which is simpler, at least= for my implementation.=C2=A0 This is for the server to send a packet only = containing a PING when it becomes limited by the amplification=C2=A0factor.= =C2=A0 This elicits an Initial(always full-sized or Handshake(provides addr= ess confirmation) packet from the client, unblocking the server.=C2=A0 It d= oes slightly increase network load, but it's less than a single full-si= zed packet due to exponential backoff.

Only a few = people looked at this change(#3162) closely, with no clear consensus, so I'd lik= e to get more input, so the WG can decide on how to proceed with the design= issue I filed(#3161), possibly with no action.

Thanks, Ian=
--00000000000055166c059dab00cc-- From nobody Mon Feb 3 04:57:14 2020 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 8478F1200C7 for ; Mon, 3 Feb 2020 04:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 J1Odq08I1MJy for ; Mon, 3 Feb 2020 04:57:10 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 1EBBC1200C1 for ; Mon, 3 Feb 2020 04:57:10 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id m30so9603142lfp.8 for ; Mon, 03 Feb 2020 04:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OaYSuWG6Gxa9etJyJiule860qrCzQlv+TOucaHoCy0k=; b=lCeN0765EfblD3a2Q6h/W+T415bSS3VRihW4JIQbLav47rx/W1VLbfJq2A4YfuBQyD 5KxbI5O2mks47tkObulKEOLho1NPpsNyWjn+FHITo21PEqZ0pVZ/v2Md4xglLW4OlFY4 yi0a7buArgDZ4GY7qsQZj7Ncqq6x8GblMuvoYN6Kh6KQ00rstMcV9crfsOKfmNbUJcVy +ybqEeapA8+nR7h9sy4w/H7rW8FztSyRm4dZyG2IezLsltEt3hvqiuwDUanyDogd2Bck RAdYwYcux4qeMe4qxeEnoTbDdbQ3l8hSg06x5s9DyK8raFKIWtQjoJ7KjDJxD0viIBC+ JLOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OaYSuWG6Gxa9etJyJiule860qrCzQlv+TOucaHoCy0k=; b=YipYpZlJy3A7zpB4Va+2tRAc1eTDGWMWEKfvZj6pdHH3xFn0sJERqJx+ltQuf3FsPp bv21fqHPszDAsVVdDFPQxU6r783vPZwHxLnCyC2gnR7/4jvlcsvCywNtOfIp6fl1Rk0W SVQLPQ/YeJo1Bu7Lrp/e+PDZ2bUMXZl751AiQuHUiL7QfHXUvASY7/Gqf0Tp5ct78mI5 CaFXexy1sVyCNxkDkqQTChIqJRGsPRJMMU+QdLddDijfCWpMLTLEKFh7MPSLPtoZgdpP RP40FKblcfXiiNd/M5JfdLOy6wbqJmVh9z5CQYtCcPkB1N5acsrM/2wylILCY60HJWyH SK8Q== X-Gm-Message-State: APjAAAVwVMbSM5iLNAPUMS7k+irktxEumaHYKWV91Ueh6ls9FFU5dRoa 9oR8ar0Abp8DPi9VO4DgShjgxPepEpo4LqKHRWMEdw== X-Google-Smtp-Source: APXvYqxDQ954uy8qlQZSoP3u6stcX0698RrFYO/sjp29urRIK44C7TvVfEAmXusZF/uw1yLjXjL1QToInBfMZ2RG7v4= X-Received: by 2002:ac2:53b9:: with SMTP id j25mr11703955lfh.140.1580734628163; Mon, 03 Feb 2020 04:57:08 -0800 (PST) MIME-Version: 1.0 References: <157288641719.16495.4218503379126128243.idtracker@ietfa.amsl.com> <3F20108D-DEED-4AEF-89D3-55F11058110B@ericsson.com> <65CD80F2-11BF-4D48-A011-17F6E431D209@ericsson.com> In-Reply-To: <65CD80F2-11BF-4D48-A011-17F6E431D209@ericsson.com> From: Eric Rescorla Date: Mon, 3 Feb 2020 04:56:31 -0800 Message-ID: Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt To: Mirja Kuehlewind Cc: Patrick McManus , Lucas Pardue , "quic@ietf.org" , "Su, Chi-Jiun" , Zaheduzzaman Sarker , "masque@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ff05fd059dab7563" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 12:57:13 -0000 --000000000000ff05fd059dab7563 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 22, 2020 at 5:54 AM Mirja Kuehlewind wrote: > Hi Partick, hi Lucus, hi all, > > > > I=E2=80=99m currently updating the discovery draft and therefore looking = at this > email thread. > > > > So looking at WPAD, it also uses DHCP and/or DNS to get a config file. In > the draft we mentioned also the use of Provisioning Domains (PvDs) to get > information about local configuration. This seems to be the more > appropriate and soon to be standardized alternative, so I don=E2=80=99t t= hink > mentioning WPAD will add much. Lucas? > > > > Mentioning WPAD could maybe lead to a discussion about who this > information can be access by an application/browser (if needed because it > could also be the OS that handles the proxying transparently for the app)= , > however, this seems a bit out of scope for this document and probably is > mostly covered by taps for PvDs. > > > > Patrick, you said below that =E2=80=9Cseries of CONNECT tunnels to the pr= oxy are > giving up the end to end security of transport features that QUIC=E2=80= =9C. In > the setup we have in mind for use with MASQUE, we never touch the encrypt= ed > QUIC end-to-end connection and just forward those packets. Other than for > HTTP/TCP proxies, the idea is to always have an outer QUIC connection > between the client and the proxy and an inner QUIC connection between the > client and the server. So I think if you only look for a forwarding servi= ce > (+ address translation/anonymization), it=E2=80=99s actually okay to rely= on > potentially unauthenticated local discovery as you basically only have to > trust the proxy as much as you trust any router on the path. > Well, one of the most common reasons why you would want some sort of tunnel proxy is to conceal your behavior from the local network, which is clearly inconsistent with having the local network supply the proxy information. More generally, I find the whole premise of this draft somewhat confusing. If we look at TLS MITM proxies as a loose analogy, there are two kinds of configuration one might want: 1. To tell the client to trust the proxy 2. To tell the client to connect to the proxy However, as a practical matter, TLS MITM proxies don't do (2) and just rely on network mechanisms to make that work. They only configure trust anchors to let the client trust the proxy. Similarly here, the challenge with QUIC is that you want the client to engage in some behavior that has trust implications, but for this you need some discovery mechanism that is secure, which the ones you propose are not. -Ekr --000000000000ff05fd059dab7563 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 22, 2020 at 5:54 AM Mirja= Kuehlewind <mirja.kuehlewind=3D40ericsson.com@dmarc.ietf.org> wrote:

Hi Partick, hi Lucus, hi all,

=C2=A0

I=E2=80=99m currently updating = the discovery draft and therefore looking at this email thread.

=C2=A0

So looking at WPAD, it also use= s DHCP and/or DNS to get a config file. In the draft we mentioned also the = use of Provisioning Domains (PvDs) to get information about local configura= tion. This seems to be the more appropriate and soon to be standardized alternat= ive, so I don=E2=80=99t think mentioning WPAD will add much. Lucas?<= u>

=C2=A0

Mentioning WPAD could maybe lea= d to a discussion about who this information can be access by an applicatio= n/browser (if needed because it could also be the OS that handles the proxy= ing transparently for the app), however, this seems a bit out of scope for thi= s document and probably is mostly covered by taps for PvDs.

=C2=A0

Patrick, you said below that = =E2=80=9Cseries of CONNECT tunnels to the proxy are giving up the en= d to end security of transport features that QUIC=E2= =80=9C. In the setup we have in mind for use with MASQUE, we never touch the encrypted QUIC end-to= -end connection and just forward those packets. Other than for HTTP/TCP pro= xies, the idea is to always have an outer QUIC connection between the clien= t and the proxy and an inner QUIC connection between the client and the server. So I think if you only look = for a forwarding service (+ address translation/anonymization), it=E2=80=99= s actually okay to rely on potentially unauthenticated local discovery as y= ou basically only have to trust the proxy as much as you trust any router on the path.


Well,=C2=A0 one of the most common reasons why yo= u would want some sort of tunnel proxy is to conceal your behavior from the= local network, which is clearly inconsistent with having the local network= supply the proxy information.

More generally, I f= ind the whole premise of this draft somewhat confusing. If we look at TLS M= ITM proxies as a loose analogy, there are two kinds of configuration one mi= ght want:

1. To tell the client to trust the proxy=
2. To tell the client to connect to the proxy

However, as a practical matter, TLS MITM proxies don't do (2) an= d just rely on network mechanisms to make that work. They only configure tr= ust anchors to let the client trust the proxy. Similarly here, the challeng= e with QUIC is that you want the client to engage in some behavior that has= trust implications, but for this you need some discovery mechanism that is= secure, which the ones you propose are not.

-Ekr<= /div>

--000000000000ff05fd059dab7563-- From nobody Mon Feb 3 06:47:07 2020 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 C07941200C4; Mon, 3 Feb 2020 06:47:03 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 (1024-bit key) header.d=ericsson.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 VfvLZPiwOr73; Mon, 3 Feb 2020 06:47:01 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80055.outbound.protection.outlook.com [40.107.8.55]) (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 B3C55120044; Mon, 3 Feb 2020 06:47:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BnoInmgkez4sqP2aD5elC7uR7JNec79Au5VZx+v4d2cRZ82+am8YwijPOJyraqWEUOQCvAd8XpuqaTncgYnW+pF+KAFKWjTeeMnZ98l7XNH4VL8psh+lSBXodxFEg9amjatla78tIo0ZxSVuGYde9gz0LnU8FSaftkyG381ZsnLsltBZc7jRKB3gAvlsxHxrSdu56PuBbzRn990DWAgNh/LkU2T1H50P3j6vZRDhs/VQ6QNh6HAVXeErHlwhLvYmG/GcprkLqoxKe0EZw+yvssKWOa87p6rFTepHInTczJp645GPvrqkCNq9AvFQZxlljtzHq5geBt3U7EWj4jBEig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SW0AwAY3d2eLe5ALLwbsvyiltI5WEAz5lqEdHtO9S2A=; b=Mg+3l3rJNJO7/rZw+dDCSefEjje1OTJJb+q5IYAK6aKf3wauE2b4W0y+A0PV4oIMSYNPdyrL3BS6tGicETZUiLsyAdq++eHfrsNwsPknFEMXvKeXm156YBrkudBxBuZw/HazGaBcof2RwETiOmihGMxTrormbhVm+pfm3W/GkWc8MBuh2+7+Wj2doGdzQow8D4hYw3sbd48pHjKlpOgWIrxUgelmfItFUO4gQeWRtVTDemxbBS71JRF6I5s8QF+penRbRDfqijPNWYQ4KHdpTJYpxkp8odg/sHcYkyiQG+ZOvUkKAyJ/dwR82Zh0/E1zdHXZM25jpryPxbql0Cbg2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SW0AwAY3d2eLe5ALLwbsvyiltI5WEAz5lqEdHtO9S2A=; b=b/hHJVJBOt78RY6kFQp8Nd5i8T7pkMCanr3vY+FiWmW/NO9TViwVQ9zIg0EJlsQBSRpOAxuj82hKEBXPcHuKUvvUOVv61WK08VIq4urExwEXJVGTnzOGlEGPuGrlJU062pwZN+GM3VxPn1IY7nsUU6GSrniHxgMDo3ordgCBzys= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB5810.eurprd07.prod.outlook.com (20.178.115.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.15; Mon, 3 Feb 2020 14:46:53 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4879:46ae:16e:f5b7]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4879:46ae:16e:f5b7%7]) with mapi id 15.20.2707.018; Mon, 3 Feb 2020 14:46:53 +0000 From: Mirja Kuehlewind To: Eric Rescorla CC: Patrick McManus , Lucas Pardue , "quic@ietf.org" , "Su, Chi-Jiun" , Zaheduzzaman Sarker , "masque@ietf.org" Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt Thread-Topic: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt Thread-Index: AQHVkzBtXqSCGBS1QEWLK0BXXTrwWKd7THMA///xkwCAABGsgP//8OCAgAA2fICAAaTLAIB6JW6AgBK7DoCAAC+ZgA== Date: Mon, 3 Feb 2020 14:46:53 +0000 Message-ID: <9AA1F2AB-AF93-4A28-B258-3A691A4DCDEC@ericsson.com> References: <157288641719.16495.4218503379126128243.idtracker@ietfa.amsl.com> <3F20108D-DEED-4AEF-89D3-55F11058110B@ericsson.com> <65CD80F2-11BF-4D48-A011-17F6E431D209@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; x-originating-ip: [2a00:79e1:abc:301:5816:11c5:461d:3738] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e8c849eb-4ce0-4cd0-f5a8-08d7a8b7e8f0 x-ms-traffictypediagnostic: AM0PR07MB5810:|AM0PR07MB5810: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(366004)(376002)(346002)(189003)(199004)(8936002)(71200400001)(478600001)(54906003)(186003)(81156014)(81166006)(6512007)(6916009)(5660300002)(4326008)(8676002)(86362001)(66574012)(53546011)(6506007)(6486002)(33656002)(316002)(91956017)(44832011)(64756008)(66446008)(36756003)(76116006)(15650500001)(2616005)(66946007)(2906002)(66476007)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5810; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VqtBj1LsvdpWubMJ2P9PKjptjcuI6m0IeYPUnSusQHmtqbvw0nEyKm4P8a7+lHDbO8t/TSKDPDfZT/4M+c4QlGP4WQy9TZQE4L/6Sy5FR/rGyVoNHmf5YjpGNluzsXrU6eNSr8G/W8oAKM7eweFC7AOcpVrj04DmvmPaQYvlqVKKq/rAYLHMqQ2wDZZXIBhnjvC2aKLVDxgbndA4aWv10ypzJR9m7DRwHzXct2rX5mgcTwNT4f8NYrRCRFEDyz6CLoN3/AOqf89nq8mGDh1/bNevMThi0AbTmtR8qQI8msoimabuCCm9rQ1muHKXnaWe9rFO0g+tXARdjgHaMw5qRHG2wbRlRSphKfOubBYaiGYrG4zf7xGFoVA7BDVzJRlVw0hLcfkbpKpzD+GwzasypHF9mre8fqogYZwV8dTAzwxecY+kHxJI6dg2BLkjkyce x-ms-exchange-antispam-messagedata: zl8YFrVvPysNn1CBiXcP4SwOzFxogQWwxKKOVHtO6YudMIbOPJkhEW6eUJyz9C8zNnVuCFVmR4HdTFxcM0dRddqietnPwc1kwZhg3lzAZtD4X5kcexAdeueQs9o7bdSxUyb54LM0gzeHxyg2v7KJVqVygLEIy3rZyd4aen7aWdC7VnoCYe5XJci2NN8uCoNX0KO/egrGnhJvkfBm+/88Xg== Content-Type: multipart/alternative; boundary="_000_9AA1F2ABAF934A28B2583A691A4DCDECericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e8c849eb-4ce0-4cd0-f5a8-08d7a8b7e8f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2020 14:46:53.6072 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: utuPwlJhfcbY8M5UFW/wKh3TAbh6wna915nfx2kHNEA3RxQwO8+chA1frlcCoTglHPNFGbK9OuC9Z9nV76bSYNM/SF/FRM45woX3LSjX+Jg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5810 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 14:47:04 -0000 --_000_9AA1F2ABAF934A28B2583A691A4DCDECericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWtyLA0KDQpUTFMgTUlUTSBpcyBub3QgdGhlIHJpZ2h0IGFuYWxvZ3kgaGVyZS4gQXMgSSBz YWlkIGluIG15IGVtYWlsIGJlbG93IHdlIG9ubHkgbG9vayBhdCBzZXJ2aWNlcyBmb3IgdGhlIHBy b3h5IGNvdWxkIHRvIHByb3ZpZGUgdGhhdCBkbyBub3QgaW50ZXJjZXB0IHRoZSBlbmQtdG8tZW5k IGNvbm5lY3Rpb24uIEluc3RlYWQgdGhlIGNsaWVudCB3b3VsZCBlaXRoZXIgcmVxdWVzdCBhIGNl cnRhaW4gbmV0d29yayBzZXJ2aWNlIGZyb20gdGhlIHByb3h5IChpbiBhbnkgY2FzZSBhdCBsZWFz dCBzaW1wbGUgZm9yd2FyZGluZykgb3IsIHdoYXQgd2UgaGF2ZSBpbiBtaW5kIGZvciBwZXJmb3Jt YW5jZSBvcHRpbWl6YXRpb24sIHRoZSBwcm94eSB3b3VsZCBwcm92aWRlIGFkZGl0aW9uYWwgaW5m b3JtYXRpb24gdG8gdGhlIGNsaWVudCB0aGF0IHRoZW4gY2FuIGJlIHVzZWQgaW4gdGhlIGVuZHBv aW50cyB0byBvcHRpbWl6ZSB0cmFmZmljLg0KDQpGdXJ0aGVyIHlvdSBjYW4gc3RpbGwgY29uZmln dXJlIGEgdHJ1c3QgYW5jaG9yIGluIHlvdXIgY2xpZW50IGFuZCB1c2UgbG9jYWwgcmVjb3Zlcnkg dG8gZHluYW1pY2FsbHkgZmluZCB0aGUgSVAgYWRkcmVzcy4gQW5kIG5vdCBhbGwgbWVjaGFuaXNt cyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0IGFyZSBhY3R1YWxseSBmb3IgbG9jYWwgcmVjb3Zlcnku DQoNCkFuZCBhdCB0aGUgZW5kIGl0IGRlcGVuZHMgb24gdGhlIHNlcnZpY2UgdGhlIHByb3h5IHBy b3ZpZGVzIGlmIGEgbG9jYWwgcHJveHkgbWFrZXMgc2Vuc2Ugb3Igbm90LiBFLmcuIGlmIHlvdSBv bmx5IGxvb2sgYXQgZm9yd2FyZGluZyBhbmQgYWRkcmVzcyB0cmFuc2xhdGlvbiBpbiBvcmRlciB0 byBjb25jZWFsIHRoZSBjbGllbnQgSVAgYWRkcmVzcyBmcm9tIHRoZSBzZXJ2ZXIsIG5vdCB0aGF0 IG11Y2ggdHJ1c3QgaXMgbmVlZGVkIGFuZCBhIGxvY2FsIHByb3h5IGNhbiBtYWtlIGEgbG90IG9m IHNlbnNlIGFzIHlvdXIgYWNjZXNzIHByb3ZpZGVyIGtub3dzIHlvdSBJUCBhZGRyZXNzIGFueXdh eS4NCg0KTWlyamENCg0KDQoNCkZyb206IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NCkRh dGU6IE1vbmRheSwgMy4gRmVicnVhcnkgMjAyMCBhdCAxMzo1Nw0KVG86IE1pcmphIEt1ZWhsZXdp bmQgPG1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPg0KQ2M6IFBhdHJpY2sgTWNNYW51cyA8 bWNtYW51c0BkdWNrc29uZy5jb20+LCBMdWNhcyBQYXJkdWUgPGx1Y2FzcGFyZHVlLjI0LjdAZ21h aWwuY29tPiwgInF1aWNAaWV0Zi5vcmciIDxxdWljQGlldGYub3JnPiwgIlN1LCBDaGktSml1biIg PENoaS1KaXVuLlN1QGh1Z2hlcy5jb20+LCBaYWhlZHV6emFtYW4gU2Fya2VyIDx6YWhlZHV6emFt YW4uc2Fya2VyQGVyaWNzc29uLmNvbT4sICJtYXNxdWVAaWV0Zi5vcmciIDxtYXNxdWVAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW01hc3F1ZV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQta3VlaGxld2luZC1xdWljLXByb3h5LWRpc2NvdmVyeS0wMC50eHQNCg0KDQoNCk9u IFdlZCwgSmFuIDIyLCAyMDIwIGF0IDU6NTQgQU0gTWlyamEgS3VlaGxld2luZCA8bWlyamEua3Vl aGxld2luZD00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBlcmljc3Nvbi5j b21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkhpIFBhcnRpY2ssIGhpIEx1Y3VzLCBoaSBhbGws DQoNCknigJltIGN1cnJlbnRseSB1cGRhdGluZyB0aGUgZGlzY292ZXJ5IGRyYWZ0IGFuZCB0aGVy ZWZvcmUgbG9va2luZyBhdCB0aGlzIGVtYWlsIHRocmVhZC4NCg0KU28gbG9va2luZyBhdCBXUEFE LCBpdCBhbHNvIHVzZXMgREhDUCBhbmQvb3IgRE5TIHRvIGdldCBhIGNvbmZpZyBmaWxlLiBJbiB0 aGUgZHJhZnQgd2UgbWVudGlvbmVkIGFsc28gdGhlIHVzZSBvZiBQcm92aXNpb25pbmcgRG9tYWlu cyAoUHZEcykgdG8gZ2V0IGluZm9ybWF0aW9uIGFib3V0IGxvY2FsIGNvbmZpZ3VyYXRpb24uIFRo aXMgc2VlbXMgdG8gYmUgdGhlIG1vcmUgYXBwcm9wcmlhdGUgYW5kIHNvb24gdG8gYmUgc3RhbmRh cmRpemVkIGFsdGVybmF0aXZlLCBzbyBJIGRvbuKAmXQgdGhpbmsgbWVudGlvbmluZyBXUEFEIHdp bGwgYWRkIG11Y2guIEx1Y2FzPw0KDQpNZW50aW9uaW5nIFdQQUQgY291bGQgbWF5YmUgbGVhZCB0 byBhIGRpc2N1c3Npb24gYWJvdXQgd2hvIHRoaXMgaW5mb3JtYXRpb24gY2FuIGJlIGFjY2VzcyBi eSBhbiBhcHBsaWNhdGlvbi9icm93c2VyIChpZiBuZWVkZWQgYmVjYXVzZSBpdCBjb3VsZCBhbHNv IGJlIHRoZSBPUyB0aGF0IGhhbmRsZXMgdGhlIHByb3h5aW5nIHRyYW5zcGFyZW50bHkgZm9yIHRo ZSBhcHApLCBob3dldmVyLCB0aGlzIHNlZW1zIGEgYml0IG91dCBvZiBzY29wZSBmb3IgdGhpcyBk b2N1bWVudCBhbmQgcHJvYmFibHkgaXMgbW9zdGx5IGNvdmVyZWQgYnkgdGFwcyBmb3IgUHZEcy4N Cg0KUGF0cmljaywgeW91IHNhaWQgYmVsb3cgdGhhdCDigJxzZXJpZXMgb2YgQ09OTkVDVCB0dW5u ZWxzIHRvIHRoZSBwcm94eSBhcmUgZ2l2aW5nIHVwIHRoZSBlbmQgdG8gZW5kIHNlY3VyaXR5IG9m IHRyYW5zcG9ydCBmZWF0dXJlcyB0aGF0IFFVSUPigJwuIEluIHRoZSBzZXR1cCB3ZSBoYXZlIGlu IG1pbmQgZm9yIHVzZSB3aXRoIE1BU1FVRSwgd2UgbmV2ZXIgdG91Y2ggdGhlIGVuY3J5cHRlZCBR VUlDIGVuZC10by1lbmQgY29ubmVjdGlvbiBhbmQganVzdCBmb3J3YXJkIHRob3NlIHBhY2tldHMu IE90aGVyIHRoYW4gZm9yIEhUVFAvVENQIHByb3hpZXMsIHRoZSBpZGVhIGlzIHRvIGFsd2F5cyBo YXZlIGFuIG91dGVyIFFVSUMgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBw cm94eSBhbmQgYW4gaW5uZXIgUVVJQyBjb25uZWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQg dGhlIHNlcnZlci4gU28gSSB0aGluayBpZiB5b3Ugb25seSBsb29rIGZvciBhIGZvcndhcmRpbmcg c2VydmljZSAoKyBhZGRyZXNzIHRyYW5zbGF0aW9uL2Fub255bWl6YXRpb24pLCBpdOKAmXMgYWN0 dWFsbHkgb2theSB0byByZWx5IG9uIHBvdGVudGlhbGx5IHVuYXV0aGVudGljYXRlZCBsb2NhbCBk aXNjb3ZlcnkgYXMgeW91IGJhc2ljYWxseSBvbmx5IGhhdmUgdG8gdHJ1c3QgdGhlIHByb3h5IGFz IG11Y2ggYXMgeW91IHRydXN0IGFueSByb3V0ZXIgb24gdGhlIHBhdGguDQoNCldlbGwsICBvbmUg b2YgdGhlIG1vc3QgY29tbW9uIHJlYXNvbnMgd2h5IHlvdSB3b3VsZCB3YW50IHNvbWUgc29ydCBv ZiB0dW5uZWwgcHJveHkgaXMgdG8gY29uY2VhbCB5b3VyIGJlaGF2aW9yIGZyb20gdGhlIGxvY2Fs IG5ldHdvcmssIHdoaWNoIGlzIGNsZWFybHkgaW5jb25zaXN0ZW50IHdpdGggaGF2aW5nIHRoZSBs b2NhbCBuZXR3b3JrIHN1cHBseSB0aGUgcHJveHkgaW5mb3JtYXRpb24uDQoNCk1vcmUgZ2VuZXJh bGx5LCBJIGZpbmQgdGhlIHdob2xlIHByZW1pc2Ugb2YgdGhpcyBkcmFmdCBzb21ld2hhdCBjb25m dXNpbmcuIElmIHdlIGxvb2sgYXQgVExTIE1JVE0gcHJveGllcyBhcyBhIGxvb3NlIGFuYWxvZ3ks IHRoZXJlIGFyZSB0d28ga2luZHMgb2YgY29uZmlndXJhdGlvbiBvbmUgbWlnaHQgd2FudDoNCg0K MS4gVG8gdGVsbCB0aGUgY2xpZW50IHRvIHRydXN0IHRoZSBwcm94eQ0KMi4gVG8gdGVsbCB0aGUg Y2xpZW50IHRvIGNvbm5lY3QgdG8gdGhlIHByb3h5DQoNCkhvd2V2ZXIsIGFzIGEgcHJhY3RpY2Fs IG1hdHRlciwgVExTIE1JVE0gcHJveGllcyBkb24ndCBkbyAoMikgYW5kIGp1c3QgcmVseSBvbiBu ZXR3b3JrIG1lY2hhbmlzbXMgdG8gbWFrZSB0aGF0IHdvcmsuIFRoZXkgb25seSBjb25maWd1cmUg dHJ1c3QgYW5jaG9ycyB0byBsZXQgdGhlIGNsaWVudCB0cnVzdCB0aGUgcHJveHkuIFNpbWlsYXJs eSBoZXJlLCB0aGUgY2hhbGxlbmdlIHdpdGggUVVJQyBpcyB0aGF0IHlvdSB3YW50IHRoZSBjbGll bnQgdG8gZW5nYWdlIGluIHNvbWUgYmVoYXZpb3IgdGhhdCBoYXMgdHJ1c3QgaW1wbGljYXRpb25z LCBidXQgZm9yIHRoaXMgeW91IG5lZWQgc29tZSBkaXNjb3ZlcnkgbWVjaGFuaXNtIHRoYXQgaXMg c2VjdXJlLCB3aGljaCB0aGUgb25lcyB5b3UgcHJvcG9zZSBhcmUgbm90Lg0KDQotRWtyDQoNCg== --_000_9AA1F2ABAF934A28B2583A691A4DCDECericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <95C8BC2DB538BE4F9F605F3B0FF9B12F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tREUi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkhpIEVrciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UTFMg TUlUTSBpcyBub3QgdGhlIHJpZ2h0IGFuYWxvZ3kgaGVyZS4gQXMgSSBzYWlkIGluIG15IGVtYWls IGJlbG93IHdlIG9ubHkgbG9vayBhdCBzZXJ2aWNlcyBmb3IgdGhlIHByb3h5IGNvdWxkIHRvIHBy b3ZpZGUgdGhhdCBkbyBub3QgaW50ZXJjZXB0IHRoZSBlbmQtdG8tZW5kIGNvbm5lY3Rpb24uIElu c3RlYWQgdGhlDQogY2xpZW50IHdvdWxkIGVpdGhlciByZXF1ZXN0IGEgY2VydGFpbiBuZXR3b3Jr IHNlcnZpY2UgZnJvbSB0aGUgcHJveHkgKGluIGFueSBjYXNlIGF0IGxlYXN0IHNpbXBsZSBmb3J3 YXJkaW5nKSBvciwgd2hhdCB3ZSBoYXZlIGluIG1pbmQgZm9yIHBlcmZvcm1hbmNlIG9wdGltaXph dGlvbiwgdGhlIHByb3h5IHdvdWxkIHByb3ZpZGUgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0byB0 aGUgY2xpZW50IHRoYXQgdGhlbiBjYW4gYmUgdXNlZCBpbiB0aGUgZW5kcG9pbnRzDQogdG8gb3B0 aW1pemUgdHJhZmZpYy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+RnVydGhlciB5 b3UgY2FuIHN0aWxsIGNvbmZpZ3VyZSBhIHRydXN0IGFuY2hvciBpbiB5b3VyIGNsaWVudCBhbmQg dXNlIGxvY2FsIHJlY292ZXJ5IHRvIGR5bmFtaWNhbGx5IGZpbmQgdGhlIElQIGFkZHJlc3MuIEFu ZCBub3QgYWxsIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCBhcmUgYWN0dWFsbHkg Zm9yDQogbG9jYWwgcmVjb3ZlcnkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFu ZCBhdCB0aGUgZW5kIGl0IGRlcGVuZHMgb24gdGhlIHNlcnZpY2UgdGhlIHByb3h5IHByb3ZpZGVz IGlmIGEgbG9jYWwgcHJveHkgbWFrZXMgc2Vuc2Ugb3Igbm90LiBFLmcuIGlmIHlvdSBvbmx5IGxv b2sgYXQgZm9yd2FyZGluZyBhbmQgYWRkcmVzcyB0cmFuc2xhdGlvbiBpbiBvcmRlciB0byBjb25j ZWFsIHRoZSBjbGllbnQNCiBJUCBhZGRyZXNzIGZyb20gdGhlIHNlcnZlciwgbm90IHRoYXQgbXVj aCB0cnVzdCBpcyBuZWVkZWQgYW5kIGEgbG9jYWwgcHJveHkgY2FuIG1ha2UgYSBsb3Qgb2Ygc2Vu c2UgYXMgeW91ciBhY2Nlc3MgcHJvdmlkZXIga25vd3MgeW91IElQIGFkZHJlc3MgYW55d2F5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1pcmphPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPkVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+TW9uZGF5LCAzLiBGZWJydWFyeSAyMDIwIGF0IDEzOjU3PGJyPg0KPGI+VG86 IDwvYj5NaXJqYSBLdWVobGV3aW5kICZsdDttaXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbSZn dDs8YnI+DQo8Yj5DYzogPC9iPlBhdHJpY2sgTWNNYW51cyAmbHQ7bWNtYW51c0BkdWNrc29uZy5j b20mZ3Q7LCBMdWNhcyBQYXJkdWUgJmx0O2x1Y2FzcGFyZHVlLjI0LjdAZ21haWwuY29tJmd0Oywg JnF1b3Q7cXVpY0BpZXRmLm9yZyZxdW90OyAmbHQ7cXVpY0BpZXRmLm9yZyZndDssICZxdW90O1N1 LCBDaGktSml1biZxdW90OyAmbHQ7Q2hpLUppdW4uU3VAaHVnaGVzLmNvbSZndDssIFphaGVkdXp6 YW1hbiBTYXJrZXIgJmx0O3phaGVkdXp6YW1hbi5zYXJrZXJAZXJpY3Nzb24uY29tJmd0OywgJnF1 b3Q7bWFzcXVlQGlldGYub3JnJnF1b3Q7ICZsdDttYXNxdWVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJlOiBbTWFzcXVlXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1rdWVobGV3aW5kLXF1aWMtcHJveHktZGlzY292ZXJ5LTAwLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gV2VkLCBK YW4gMjIsIDIwMjAgYXQgNTo1NCBBTSBNaXJqYSBLdWVobGV3aW5kICZsdDttaXJqYS5rdWVobGV3 aW5kPTxhIGhyZWY9Im1haWx0bzo0MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyI+NDBlcmlj c3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SGkgUGFydGljaywgaGkgTHVj dXMsIGhpIGFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4N CjxzcGFuIGxhbmc9IkVOLVVTIj5J4oCZbSBjdXJyZW50bHkgdXBkYXRpbmcgdGhlIGRpc2NvdmVy eSBkcmFmdCBhbmQgdGhlcmVmb3JlIGxvb2tpbmcgYXQgdGhpcyBlbWFpbCB0aHJlYWQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBw dCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1V UyI+U28gbG9va2luZyBhdCBXUEFELCBpdCBhbHNvIHVzZXMgREhDUCBhbmQvb3IgRE5TIHRvIGdl dCBhIGNvbmZpZyBmaWxlLiBJbiB0aGUgZHJhZnQgd2UgbWVudGlvbmVkIGFsc28gdGhlIHVzZSBv ZiBQcm92aXNpb25pbmcgRG9tYWlucyAoUHZEcykgdG8gZ2V0IGluZm9ybWF0aW9uIGFib3V0IGxv Y2FsIGNvbmZpZ3VyYXRpb24uIFRoaXMgc2VlbXMgdG8gYmUgdGhlIG1vcmUgYXBwcm9wcmlhdGUg YW5kIHNvb24gdG8gYmUNCiBzdGFuZGFyZGl6ZWQgYWx0ZXJuYXRpdmUsIHNvIEkgZG9u4oCZdCB0 aGluayBtZW50aW9uaW5nIFdQQUQgd2lsbCBhZGQgbXVjaC4gTHVjYXM/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+TWVudGlv bmluZyBXUEFEIGNvdWxkIG1heWJlIGxlYWQgdG8gYSBkaXNjdXNzaW9uIGFib3V0IHdobyB0aGlz IGluZm9ybWF0aW9uIGNhbiBiZSBhY2Nlc3MgYnkgYW4gYXBwbGljYXRpb24vYnJvd3NlciAoaWYg bmVlZGVkIGJlY2F1c2UgaXQgY291bGQgYWxzbyBiZSB0aGUgT1MgdGhhdCBoYW5kbGVzIHRoZSBw cm94eWluZyB0cmFuc3BhcmVudGx5IGZvciB0aGUgYXBwKSwgaG93ZXZlciwgdGhpcyBzZWVtcyBh IGJpdA0KIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVudCBhbmQgcHJvYmFibHkgaXMgbW9z dGx5IGNvdmVyZWQgYnkgdGFwcyBmb3IgUHZEcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5QYXRyaWNrLCB5b3Ugc2FpZCBi ZWxvdyB0aGF0IOKAnDwvc3Bhbj5zZXJpZXMgb2YgQ09OTkVDVCB0dW5uZWxzIHRvIHRoZSBwcm94 eSBhcmUgZ2l2aW5nIHVwIHRoZSBlbmQgdG8gZW5kIHNlY3VyaXR5IG9mIHRyYW5zcG9ydCBmZWF0 dXJlcyB0aGF0IFFVSUM8c3BhbiBsYW5nPSJFTi1VUyI+4oCcLiBJbiB0aGUgc2V0dXAgd2UgaGF2 ZSBpbiBtaW5kIGZvciB1c2Ugd2l0aCBNQVNRVUUsIHdlIG5ldmVyIHRvdWNoIHRoZSBlbmNyeXB0 ZWQNCiBRVUlDIGVuZC10by1lbmQgY29ubmVjdGlvbiBhbmQganVzdCBmb3J3YXJkIHRob3NlIHBh Y2tldHMuIE90aGVyIHRoYW4gZm9yIEhUVFAvVENQIHByb3hpZXMsIHRoZSBpZGVhIGlzIHRvIGFs d2F5cyBoYXZlIGFuIG91dGVyIFFVSUMgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5k IHRoZSBwcm94eSBhbmQgYW4gaW5uZXIgUVVJQyBjb25uZWN0aW9uIGJldHdlZW4gdGhlIGNsaWVu dCBhbmQgdGhlIHNlcnZlci4gU28gSSB0aGluayBpZiB5b3UNCiBvbmx5IGxvb2sgZm9yIGEgZm9y d2FyZGluZyBzZXJ2aWNlICgmIzQzOyBhZGRyZXNzIHRyYW5zbGF0aW9uL2Fub255bWl6YXRpb24p LCBpdOKAmXMgYWN0dWFsbHkgb2theSB0byByZWx5IG9uIHBvdGVudGlhbGx5IHVuYXV0aGVudGlj YXRlZCBsb2NhbCBkaXNjb3ZlcnkgYXMgeW91IGJhc2ljYWxseSBvbmx5IGhhdmUgdG8gdHJ1c3Qg dGhlIHByb3h5IGFzIG11Y2ggYXMgeW91IHRydXN0IGFueSByb3V0ZXIgb24gdGhlIHBhdGguPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPldlbGwsJm5ic3A7IG9uZSBvZiB0aGUgbW9zdCBjb21tb24g cmVhc29ucyB3aHkgeW91IHdvdWxkIHdhbnQgc29tZSBzb3J0IG9mIHR1bm5lbCBwcm94eSBpcyB0 byBjb25jZWFsIHlvdXIgYmVoYXZpb3IgZnJvbSB0aGUgbG9jYWwgbmV0d29yaywgd2hpY2ggaXMg Y2xlYXJseSBpbmNvbnNpc3RlbnQgd2l0aCBoYXZpbmcgdGhlIGxvY2FsIG5ldHdvcmsgc3VwcGx5 IHRoZSBwcm94eQ0KIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5Nb3JlIGdlbmVyYWxseSwgSSBmaW5kIHRoZSB3aG9sZSBwcmVt aXNlIG9mIHRoaXMgZHJhZnQgc29tZXdoYXQgY29uZnVzaW5nLiBJZiB3ZSBsb29rIGF0IFRMUyBN SVRNIHByb3hpZXMgYXMgYSBsb29zZSBhbmFsb2d5LCB0aGVyZSBhcmUgdHdvIGtpbmRzIG9mIGNv bmZpZ3VyYXRpb24gb25lIG1pZ2h0IHdhbnQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjEuIFRvIHRlbGwgdGhlIGNsaWVudCB0byB0cnVzdCB0aGUg cHJveHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjIuIFRvIHRlbGwgdGhlIGNsaWVudCB0byBjb25u ZWN0IHRvIHRoZSBwcm94eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5Ib3dldmVyLCBhcyBhIHByYWN0aWNhbCBtYXR0ZXIsIFRMUyBNSVRNIHByb3hp ZXMgZG9uJ3QgZG8gKDIpIGFuZCBqdXN0IHJlbHkgb24gbmV0d29yayBtZWNoYW5pc21zIHRvIG1h a2UgdGhhdCB3b3JrLiBUaGV5IG9ubHkgY29uZmlndXJlIHRydXN0IGFuY2hvcnMgdG8gbGV0IHRo ZSBjbGllbnQgdHJ1c3QgdGhlIHByb3h5LiBTaW1pbGFybHkgaGVyZSwgdGhlIGNoYWxsZW5nZQ0K IHdpdGggUVVJQyBpcyB0aGF0IHlvdSB3YW50IHRoZSBjbGllbnQgdG8gZW5nYWdlIGluIHNvbWUg YmVoYXZpb3IgdGhhdCBoYXMgdHJ1c3QgaW1wbGljYXRpb25zLCBidXQgZm9yIHRoaXMgeW91IG5l ZWQgc29tZSBkaXNjb3ZlcnkgbWVjaGFuaXNtIHRoYXQgaXMgc2VjdXJlLCB3aGljaCB0aGUgb25l cyB5b3UgcHJvcG9zZSBhcmUgbm90LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_9AA1F2ABAF934A28B2583A691A4DCDECericssoncom_-- From nobody Mon Feb 3 07:11:07 2020 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 5BC961200CC for ; Mon, 3 Feb 2020 07:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 wLnNfknoNbzA for ; Mon, 3 Feb 2020 07:11:00 -0800 (PST) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (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 0EF40120098 for ; Mon, 3 Feb 2020 07:11:00 -0800 (PST) Received: by mail-lf1-x144.google.com with SMTP id v201so9930620lfa.11 for ; Mon, 03 Feb 2020 07:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8ICAaytpjL3rbJM3nO+YfQq36YneRJDur6CUwKUHotE=; b=rYQzbudqs/ui+bRC66hDkvW83iaFL0y8oRZlNdDfAYObl0aCEh5WFkpYGUjcxqPJ8Z vGOkg+8VR+lBg6MG9TeXQlMjGBjVh9IC7rDr13FueImwoe53dMhIavZUR3bpOkM/LerV Dbtxl57reLceEGrxdq+fr84ITMDukmulZxCYhA+zEALbsLC0KbrldjWu9Mhc4CV0LGXr QKkqL2HBuVp//LPlcslrJIYwg6a7fpTdaFNmAgu2+ygFZ6S7IZLUyQ6r7C6ku+5+cx6V iaxiz9HPyGbEOOCmaUhXTFg6Cgv8/2Uz5sWQaH8me3QOwcSCamVzEEd+CHZyYNDKTrzx KIEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8ICAaytpjL3rbJM3nO+YfQq36YneRJDur6CUwKUHotE=; b=WmJrHuI4adaUvtZCxQLqemLMbPnYmHkoDUoA+4l86BYBrm8eJrjxqTR/XM2KAagwLV ujUPjSJsr/45dfw2QfPAwFSzGkCsORx48aU9IcVILI4N9fC9jWr0VraOg0JgZLYduAXm jpdyGru8FBmHUGgvlT+AzvBCWrib8AXhK7n+OVOxoxu1H7wTQLUGO9A+bZ18pV+aEh4+ k5EZCa6S3bFGIBkq3HajGUx6ge1L5yHJaPhPpUeJJjTCvOb1mnWpxpV8mkPsQyu35sq3 Uri5PjPBgcbpbYDWIXaXgnEubmPoAc55rxMUJUicVgi0oBAvlR3PJgsHxHEocTJdueI+ RaRg== X-Gm-Message-State: APjAAAWaneRDPQbZYPGg7GxgqxNs9Brrxft3nqvimow8PmS4SGWJwiDu ZOgs+oymoTV9SRzkw/ocgW0OH+50rLlbmi6f976djw== X-Google-Smtp-Source: APXvYqyFnH2DUCguDOv7xSlulVJ90EY2+0XhMH6f9uZMQVMbhmoEgv+rMJoYKrOfwawqDSPG52tLhuv03BBQlV3M1FM= X-Received: by 2002:a19:8b89:: with SMTP id n131mr12300108lfd.14.1580742658290; Mon, 03 Feb 2020 07:10:58 -0800 (PST) MIME-Version: 1.0 References: <157288641719.16495.4218503379126128243.idtracker@ietfa.amsl.com> <3F20108D-DEED-4AEF-89D3-55F11058110B@ericsson.com> <65CD80F2-11BF-4D48-A011-17F6E431D209@ericsson.com> <9AA1F2AB-AF93-4A28-B258-3A691A4DCDEC@ericsson.com> In-Reply-To: <9AA1F2AB-AF93-4A28-B258-3A691A4DCDEC@ericsson.com> From: Eric Rescorla Date: Mon, 3 Feb 2020 07:10:21 -0800 Message-ID: Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt To: Mirja Kuehlewind Cc: Patrick McManus , Lucas Pardue , "quic@ietf.org" , "Su, Chi-Jiun" , Zaheduzzaman Sarker , "masque@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a1061b059dad543a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 15:11:03 -0000 --000000000000a1061b059dad543a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 3, 2020 at 6:46 AM Mirja Kuehlewind < mirja.kuehlewind@ericsson.com> wrote: > Hi Ekr, > > > > TLS MITM is not the right analogy here. As I said in my email below we > only look at services for the proxy could to provide that do not intercep= t > the end-to-end connection. > Hence the phrase "loose analogy". Those service still require authorization and the only authorization you are providing is network topology. -Ekr Instead the client would either request a certain network service from the > proxy (in any case at least simple forwarding) or, what we have in mind f= or > performance optimization, the proxy would provide additional information = to > the client that then can be used in the endpoints to optimize traffic. > > > > Further you can still configure a trust anchor in your client and use > local recovery to dynamically find the IP address. And not all mechanisms > described in the draft are actually for local recovery. > > > > And at the end it depends on the service the proxy provides if a local > proxy makes sense or not. E.g. if you only look at forwarding and address > translation in order to conceal the client IP address from the server, no= t > that much trust is needed and a local proxy can make a lot of sense as yo= ur > access provider knows you IP address anyway. > > > Mirja > > > > > > > > *From: *Eric Rescorla > *Date: *Monday, 3. February 2020 at 13:57 > *To: *Mirja Kuehlewind > *Cc: *Patrick McManus , Lucas Pardue < > lucaspardue.24.7@gmail.com>, "quic@ietf.org" , "Su, > Chi-Jiun" , Zaheduzzaman Sarker < > zaheduzzaman.sarker@ericsson.com>, "masque@ietf.org" > *Subject: *Re: [Masque] FW: New Version Notification for > draft-kuehlewind-quic-proxy-discovery-00.txt > > > > > > > > On Wed, Jan 22, 2020 at 5:54 AM Mirja Kuehlewind 40ericsson.com@dmarc.ietf.org> wrote: > > Hi Partick, hi Lucus, hi all, > > > > I=E2=80=99m currently updating the discovery draft and therefore looking = at this > email thread. > > > > So looking at WPAD, it also uses DHCP and/or DNS to get a config file. In > the draft we mentioned also the use of Provisioning Domains (PvDs) to get > information about local configuration. This seems to be the more > appropriate and soon to be standardized alternative, so I don=E2=80=99t t= hink > mentioning WPAD will add much. Lucas? > > > > Mentioning WPAD could maybe lead to a discussion about who this > information can be access by an application/browser (if needed because it > could also be the OS that handles the proxying transparently for the app)= , > however, this seems a bit out of scope for this document and probably is > mostly covered by taps for PvDs. > > > > Patrick, you said below that =E2=80=9Cseries of CONNECT tunnels to the pr= oxy are > giving up the end to end security of transport features that QUIC=E2=80= =9C. In > the setup we have in mind for use with MASQUE, we never touch the encrypt= ed > QUIC end-to-end connection and just forward those packets. Other than for > HTTP/TCP proxies, the idea is to always have an outer QUIC connection > between the client and the proxy and an inner QUIC connection between the > client and the server. So I think if you only look for a forwarding servi= ce > (+ address translation/anonymization), it=E2=80=99s actually okay to rely= on > potentially unauthenticated local discovery as you basically only have to > trust the proxy as much as you trust any router on the path. > > > > Well, one of the most common reasons why you would want some sort of > tunnel proxy is to conceal your behavior from the local network, which is > clearly inconsistent with having the local network supply the proxy > information. > > > > More generally, I find the whole premise of this draft somewhat confusing= . > If we look at TLS MITM proxies as a loose analogy, there are two kinds of > configuration one might want: > > > > 1. To tell the client to trust the proxy > > 2. To tell the client to connect to the proxy > > > > However, as a practical matter, TLS MITM proxies don't do (2) and just > rely on network mechanisms to make that work. They only configure trust > anchors to let the client trust the proxy. Similarly here, the challenge > with QUIC is that you want the client to engage in some behavior that has > trust implications, but for this you need some discovery mechanism that i= s > secure, which the ones you propose are not. > > > > -Ekr > > > --000000000000a1061b059dad543a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Feb 3, 2020 at 6:46 AM Mirja = Kuehlewind <mirja.kuehl= ewind@ericsson.com> wrote:

Hi Ekr,

=C2=A0

TLS MITM is not the right analo= gy here. As I said in my email below we only look at services for the proxy= could to provide that do not intercept the end-to-end connection. <= /p>


Hence the phrase "loos= e analogy". Those service still require authorization and the only aut= horization you are providing is network topology.

= -Ekr



In= stead the client would either request a certain network service from the proxy (in a= ny case at least simple forwarding) or, what we have in mind for performanc= e optimization, the proxy would provide additional information to the clien= t that then can be used in the endpoints to optimize traffic.

=C2=A0

Further you can still configure= a trust anchor in your client and use local recovery to dynamically find t= he IP address. And not all mechanisms described in the draft are actually f= or local recovery.

=C2=A0

And at the end it depends on th= e service the proxy provides if a local proxy makes sense or not. E.g. if y= ou only look at forwarding and address translation in order to conceal the = client IP address from the server, not that much trust is needed and a local prox= y can make a lot of sense as your access provider knows you IP address anyw= ay.

=C2=A0

Mirja

=C2=A0

=C2=A0

=C2=A0

From: Eric Rescorla <ekr@rtfm.com>
Date: Monday, 3. February 2020 at 13:57
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, Lucas Pardue <lucaspardue.24.7@gmail.co= m>, "quic@ie= tf.org" <qui= c@ietf.org>, "Su, Chi-Jiun" <Chi-Jiun.Su@hughes.com>, Zaheduzza= man Sarker <zaheduzzaman.sarker@ericsson.com>, "masque@ietf.org" <masque@ietf.org>
Subject: Re: [Masque] FW: New Version Notification for draft-kuehlew= ind-quic-proxy-discovery-00.txt

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 22, 2020 at 5= :54 AM Mirja Kuehlewind <mirja.kuehlewind=3D40ericsson.com@dmarc.ietf.org>= ; wrote:

Hi Partick, hi Lucus, hi all,

=C2=A0

I=E2=80=99m currently updating the discovery draft and= therefore looking at this email thread.

=C2=A0

So looking at WPAD, it also uses DHCP and/or DNS to ge= t a config file. In the draft we mentioned also the use of Provisioning Dom= ains (PvDs) to get information about local configuration. This seems to be = the more appropriate and soon to be standardized alternative, so I don=E2=80=99t think mentioning WPAD will ad= d much. Lucas?

=C2=A0

Mentioning WPAD could maybe lead to a discussion about= who this information can be access by an application/browser (if needed be= cause it could also be the OS that handles the proxying transparently for t= he app), however, this seems a bit out of scope for this document and probably is mostly covered by taps for = PvDs.

=C2=A0

Patrick, you said below that =E2=80=9Cseries of= CONNECT tunnels to the proxy are giving up the end to end security of tran= sport features that QUIC=E2=80=9C. In the setup we hav= e in mind for use with MASQUE, we never touch the encrypted QUIC end-to-end connection and just forward those packets. Other than for = HTTP/TCP proxies, the idea is to always have an outer QUIC connection betwe= en the client and the proxy and an inner QUIC connection between the client= and the server. So I think if you only look for a forwarding service (+ address translation/anonymization), = it=E2=80=99s actually okay to rely on potentially unauthenticated local dis= covery as you basically only have to trust the proxy as much as you trust a= ny router on the path.

=C2=A0

Well,=C2=A0 one of the mo= st common reasons why you would want some sort of tunnel proxy is to concea= l your behavior from the local network, which is clearly inconsistent with = having the local network supply the proxy information.

=C2=A0

More generally, I find th= e whole premise of this draft somewhat confusing. If we look at TLS MITM pr= oxies as a loose analogy, there are two kinds of configuration one might wa= nt:

=C2=A0

1. To tell the client to = trust the proxy

2. To tell the client to = connect to the proxy

=C2=A0

However, as a practical m= atter, TLS MITM proxies don't do (2) and just rely on network mechanism= s to make that work. They only configure trust anchors to let the client tr= ust the proxy. Similarly here, the challenge with QUIC is that you want the client to engage in some behavior that has = trust implications, but for this you need some discovery mechanism that is = secure, which the ones you propose are not.

=C2=A0

-Ekr

=C2=A0

--000000000000a1061b059dad543a-- From nobody Mon Feb 3 08:28:07 2020 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 BA535120B09 for ; Mon, 3 Feb 2020 08:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 2nzTVC7YZmYK for ; Mon, 3 Feb 2020 08:28:00 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 17431120B01 for ; Mon, 3 Feb 2020 08:28:00 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id a6so18992964wrx.12 for ; Mon, 03 Feb 2020 08:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PW9DA99TebXuKVd17Y9F0EMNNVs4lYZF7jjblH/3Q3M=; b=cnkH8OhpL79WHt8JXDlHgXvmu2MYsRinPnAFdICyR9o+uT+LiwMbn4gFwBjiLDyIzB gXMDd4uYA+nS3jVXiuE755ctUhJdYNgE1VGlGk0+mdWszWs/Ff5nzrCoqF5u4x/hQ4yT WXqwR8sXKNxD+qWSLTC7cSJ3/kxzW7EiT5qplJYYapaETGYQkqgCG6Mtep83Q6WjvjCZ x0jsdIYbfHPi7fKk9FFKsfPMYw3RYbpI2AxV2hbRuwu93t0MZfy1gc8BZCTLHRMxt8u7 3Db+jmK5cCaiA1yMiJ3mJVHQu4JXQch8woSqTuOwZzlotEOhtHjnjxTWVh2j51yQXbnn hdKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PW9DA99TebXuKVd17Y9F0EMNNVs4lYZF7jjblH/3Q3M=; b=mR36kAUKdqIMoO5MqFWo3NC1KX58C70+ioa/yzvCdMXr0qd5ZFkT7WxAcPo21XKHQz 9uA2rj/txuN9yl9sEspexBuQxTTImxT/Txrf1nBcp8gwLYrQXtd6U5bmvCo0A/iXwehN r5Qjfd37EG7Wpg9qVPNNIL2CnAKY7pbv3ANSWfF0EzC5I1J/X7n3uor61i5+C8xpTdS6 2sgHDqB7v2ShGEO+JbH659Q3GA85EybaYd9Esyy7ftc1YHRKGSv1UgZv/7ydkvv9irs4 Gxf4koAAiMnW/zLgXvy0SDn24jTtYx+OVtnnubsGGmGVA1rP7qk0qDarsNiR91/ISnJU F1rA== X-Gm-Message-State: APjAAAUJEdjcMnmVtFsKLR9VwWJRcnoAGGoGrIUkQI6NHhgb/J7arNze yH1UbxGhaaRd2w7yupQ1Mk0Y5sWvl0YvPpa+tHL6nw== X-Google-Smtp-Source: APXvYqw6zSZhRGKFoloJEh9eThWWu2Y7DZxbMw5Ha010ig3VWSNbxwF2BX/LipaMllkkfcYEa1LgGGaHCX38iUJXe+M= X-Received: by 2002:adf:ffc7:: with SMTP id x7mr16163682wrs.159.1580747277706; Mon, 03 Feb 2020 08:27:57 -0800 (PST) MIME-Version: 1.0 References: <157288641719.16495.4218503379126128243.idtracker@ietfa.amsl.com> <3F20108D-DEED-4AEF-89D3-55F11058110B@ericsson.com> <65CD80F2-11BF-4D48-A011-17F6E431D209@ericsson.com> <9AA1F2AB-AF93-4A28-B258-3A691A4DCDEC@ericsson.com> In-Reply-To: From: Ben Schwartz Date: Mon, 3 Feb 2020 11:27:46 -0500 Message-ID: Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt To: Eric Rescorla Cc: Mirja Kuehlewind , Zaheduzzaman Sarker , "Su, Chi-Jiun" , "masque@ietf.org" , Patrick McManus , Lucas Pardue , "quic@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000000219ea059dae68e1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 16:28:04 -0000 --0000000000000219ea059dae68e1 Content-Type: multipart/alternative; boundary="000000000000f7fd82059dae6714" --000000000000f7fd82059dae6714 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think topology-as-authorization is typically appropriate when the authorization doesn't reveal additional information to the network. Otherwise, it is likely not appropriate. Some of the protocol proposals that have been discussed on this list (e.g. IP over QUIC) likely meet this requirement, and some (e.g. connection ID negotiation) might not. I would suggest clarifying that our program of work is: 1. Define a tunnel protocol with good, clear privacy properties, providing no more information to the proxy than the local network would otherwise have. 2. Analyze and optimize its performance. 3. If performance is better with the tunnel than without in some sufficiently common scenario, define a discovery mechanism (like this draft) for PEP use. On Mon, Feb 3, 2020 at 10:11 AM Eric Rescorla wrote: > > > On Mon, Feb 3, 2020 at 6:46 AM Mirja Kuehlewind < > mirja.kuehlewind@ericsson.com> wrote: > >> Hi Ekr, >> >> >> >> TLS MITM is not the right analogy here. As I said in my email below we >> only look at services for the proxy could to provide that do not interce= pt >> the end-to-end connection. >> > > Hence the phrase "loose analogy". Those service still require > authorization and the only authorization you are providing is network > topology. > > -Ekr > > > > Instead the client would either request a certain network service from th= e >> proxy (in any case at least simple forwarding) or, what we have in mind = for >> performance optimization, the proxy would provide additional information= to >> the client that then can be used in the endpoints to optimize traffic. >> >> >> >> Further you can still configure a trust anchor in your client and use >> local recovery to dynamically find the IP address. And not all mechanism= s >> described in the draft are actually for local recovery. >> >> >> >> And at the end it depends on the service the proxy provides if a local >> proxy makes sense or not. E.g. if you only look at forwarding and addres= s >> translation in order to conceal the client IP address from the server, n= ot >> that much trust is needed and a local proxy can make a lot of sense as y= our >> access provider knows you IP address anyway. >> > >> >> Mirja >> >> >> >> >> >> >> >> *From: *Eric Rescorla >> *Date: *Monday, 3. February 2020 at 13:57 >> *To: *Mirja Kuehlewind > > >> *Cc: *Patrick McManus , Lucas Pardue < >> lucaspardue.24.7@gmail.com>, "quic@ietf.org" , "Su, >> Chi-Jiun" >, >> Zaheduzzaman Sarker , "masque@ietf.org= " >> >> *Subject: *Re: [Masque] FW: New Version Notification for >> draft-kuehlewind-quic-proxy-discovery-00.txt >> >> >> >> >> >> >> >> On Wed, Jan 22, 2020 at 5:54 AM Mirja Kuehlewind > 40ericsson.com@dmarc.ietf.org <40ericsson..com@dmarc.ietf.org>> wrote: >> >> Hi Partick, hi Lucus, hi all, >> >> >> >> I=E2=80=99m currently updating the discovery draft and therefore looking= at this >> email thread. >> >> >> >> So looking at WPAD, it also uses DHCP and/or DNS to get a config file. I= n >> the draft we mentioned also the use of Provisioning Domains (PvDs) to ge= t >> information about local configuration. This seems to be the more >> appropriate and soon to be standardized alternative, so I don=E2=80=99t = think >> mentioning WPAD will add much. Lucas? >> >> >> >> Mentioning WPAD could maybe lead to a discussion about who this >> information can be access by an application/browser (if needed because i= t >> could also be the OS that handles the proxying transparently for the app= ), >> however, this seems a bit out of scope for this document and probably is >> mostly covered by taps for PvDs. >> >> >> >> Patrick, you said below that =E2=80=9Cseries of CONNECT tunnels to the p= roxy are >> giving up the end to end security of transport features that QUIC=E2=80= =9C. In >> the setup we have in mind for use with MASQUE, we never touch the encryp= ted >> QUIC end-to-end connection and just forward those packets. Other than fo= r >> HTTP/TCP proxies, the idea is to always have an outer QUIC connection >> between the client and the proxy and an inner QUIC connection between th= e >> client and the server. So I think if you only look for a forwarding serv= ice >> (+ address translation/anonymization), it=E2=80=99s actually okay to rel= y on >> potentially unauthenticated local discovery as you basically only have t= o >> trust the proxy as much as you trust any router on the path. >> >> >> >> Well, one of the most common reasons why you would want some sort of >> tunnel proxy is to conceal your behavior from the local network, which i= s >> clearly inconsistent with having the local network supply the proxy >> information. >> >> >> >> More generally, I find the whole premise of this draft somewhat >> confusing. If we look at TLS MITM proxies as a loose analogy, there are = two >> kinds of configuration one might want: >> >> >> >> 1. To tell the client to trust the proxy >> >> 2. To tell the client to connect to the proxy >> >> >> >> However, as a practical matter, TLS MITM proxies don't do (2) and just >> rely on network mechanisms to make that work. They only configure trust >> anchors to let the client trust the proxy. Similarly here, the challenge >> with QUIC is that you want the client to engage in some behavior that ha= s >> trust implications, but for this you need some discovery mechanism that = is >> secure, which the ones you propose are not. >> >> >> >> -Ekr >> >> >> > -- > Masque mailing list > Masque@ietf.org > https://www.ietf.org/mailman/listinfo/masque > --000000000000f7fd82059dae6714 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think topology-as-authorization is typically=C2=A0a= ppropriate when the authorization doesn't reveal additional information= to the network.=C2=A0 Otherwise, it is likely not appropriate.=C2=A0 Some = of the protocol proposals that have been discussed on this list (e.g. IP ov= er QUIC) likely meet this requirement, and some (e.g. connection ID negotia= tion) might not.

I would suggest clarifying th= at our program of work is:
1. Define a tunnel protocol with good,= clear privacy properties, providing no more information to the proxy than = the local network would otherwise have.
2. Analyze and optimize i= ts performance.
3. If performance is better with the tunnel than = without in some sufficiently common scenario, define a discovery mechanism = (like this draft) for PEP use.

On Mon, Feb 3, 2020 at 10:11 AM Eric Re= scorla <ekr@rtfm.com> wrote:
<= /div>


On Mon, Feb 3, 2020 at 6:46 AM Mirja Kuehlewind <mirja.kuehlew= ind@ericsson.com> wrote:

Hi Ekr,

=C2=A0

TLS MITM is not the right analo= gy here. As I said in my email below we only look at services for the proxy= could to provide that do not intercept the end-to-end connection. <= /p>


Hence the phrase "loos= e analogy". Those service still require authorization and the only aut= horization you are providing is network topology.

= -Ekr



Instead the client would either request a certain network service from the proxy (in a= ny case at least simple forwarding) or, what we have in mind for performanc= e optimization, the proxy would provide additional information to the clien= t that then can be used in the endpoints to optimize traffic.

=C2=A0

Further you can still configure= a trust anchor in your client and use local recovery to dynamically find t= he IP address. And not all mechanisms described in the draft are actually f= or local recovery.

=C2=A0

And at the end it depends on th= e service the proxy provides if a local proxy makes sense or not. E.g. if y= ou only look at forwarding and address translation in order to conceal the = client IP address from the server, not that much trust is needed and a local prox= y can make a lot of sense as your access provider knows you IP address anyw= ay.

=C2=A0

Mirja

=C2=A0

=C2=A0

=C2=A0

From: Eric Rescorla <ekr@rtfm.com>
Date: Monday, 3. February 2020 at 13:57
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, Lucas Pardue <lucaspardue.24.7@gmail.co= m>, "quic@ie= tf.org" <qui= c@ietf.org>, "Su, Chi-Jiun" <Chi-Jiun.Su@hughes.com>, Zaheduzz= aman Sarker <zaheduzzaman.sarker@ericsson.com>, "masque@ietf.org" <masque@ietf.org>
Subject: Re: [Masque] FW: New Version Notification for draft-kuehlew= ind-quic-proxy-discovery-00.txt

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 22, 2020 at 5= :54 AM Mirja Kuehlewind <mirja.kuehlewind=3D40ericsson.com@dmarc.ietf.org&g= t; wrote:

Hi Partick, hi Lucus, hi all,

=C2=A0

I=E2=80=99m currently updating the discovery draft and= therefore looking at this email thread.

=C2=A0

So looking at WPAD, it also uses DHCP and/or DNS to ge= t a config file. In the draft we mentioned also the use of Provisioning Dom= ains (PvDs) to get information about local configuration. This seems to be = the more appropriate and soon to be standardized alternative, so I don=E2=80=99t think mentioning WPAD will ad= d much. Lucas?

=C2=A0

Mentioning WPAD could maybe lead to a discussion about= who this information can be access by an application/browser (if needed be= cause it could also be the OS that handles the proxying transparently for t= he app), however, this seems a bit out of scope for this document and probably is mostly covered by taps for = PvDs.

=C2=A0

Patrick, you said below that =E2=80=9Cseries of= CONNECT tunnels to the proxy are giving up the end to end security of tran= sport features that QUIC=E2=80=9C. In the setup we hav= e in mind for use with MASQUE, we never touch the encrypted QUIC end-to-end connection and just forward those packets. Other than for = HTTP/TCP proxies, the idea is to always have an outer QUIC connection betwe= en the client and the proxy and an inner QUIC connection between the client= and the server. So I think if you only look for a forwarding service (+ address translation/anonymization), = it=E2=80=99s actually okay to rely on potentially unauthenticated local dis= covery as you basically only have to trust the proxy as much as you trust a= ny router on the path.

=C2=A0

Well,=C2=A0 one of the mo= st common reasons why you would want some sort of tunnel proxy is to concea= l your behavior from the local network, which is clearly inconsistent with = having the local network supply the proxy information.

=C2=A0

More generally, I find th= e whole premise of this draft somewhat confusing. If we look at TLS MITM pr= oxies as a loose analogy, there are two kinds of configuration one might wa= nt:

=C2=A0

1. To tell the client to = trust the proxy

2. To tell the client to = connect to the proxy

=C2=A0

However, as a practical m= atter, TLS MITM proxies don't do (2) and just rely on network mechanism= s to make that work. They only configure trust anchors to let the client tr= ust the proxy. Similarly here, the challenge with QUIC is that you want the client to engage in some behavior that has = trust implications, but for this you need some discovery mechanism that is = secure, which the ones you propose are not.

=C2=A0

-Ekr

=C2=A0

--
Masque mailing list
Masque@ietf.org https://www.ietf.org/mailman/listinfo/masque
--000000000000f7fd82059dae6714-- --0000000000000219ea059dae68e1 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCDKYNWgLm4wjaFt0xAhEemQHKStceHL1mJkyZd5QPm/9jAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAyMDMxNjI3NThaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAtGJfkh4cspSH98+W7aiIx51C0hTqIAIMQjnkeFrxED/jqxhHNA/lyCUw6ZFUgXZMzY3nbYn+ Ax4Tfu8BxbFQop0PV01HHlEYVand66hLiVA492zzX9Cnfc/GkfQbq6aePhWC2gUA/eW8Id9r7JMl t+EBdMYpnNRXliv8r8wYLmPqP4g43hYQ7qKOq/XsEc1+F9IxwVWlYy575QuPfFKUYcVB2NRVqUeK Agq6zHjuCZy81cUKmxMvxYN1gjs0TH8phLJx3q27ZvyVegoF8c8BWAzVCzDri9uDYZS619oYa3wv I4gpBaHRMBAgR/5mycSEtYJ1v4UB6m/xeDxMEPLS2A== --0000000000000219ea059dae68e1-- From nobody Tue Feb 4 01:44:55 2020 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 3207F12012A for ; Tue, 4 Feb 2020 01:44:54 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 0YyN8SKkM73G for ; Tue, 4 Feb 2020 01:44:51 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2094.outbound.protection.outlook.com [40.107.92.94]) (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 952C8120099 for ; Tue, 4 Feb 2020 01:44:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k0QKKQ/DkUwtbNWy8fxjb5VbZPz+n5e8TMZSjR2Elwzx1gvd7IjV+LWDgHSs3qdFgEqY6YY/Z+jL/b4V2Ob30g7dLuzpZIcBhKc6Wi+yRMd1YXzZ6yFnOGO6hb8nZlMqPYmVFu74QnDi5/l5Foc1J7FDlAj1/Wgj0w3pffXbLZjt5mcAD/mX6SZN8ixVVOQ1cijRT20Gc6XDPimL9BmvNRPxfiV9SH/rejMKPAQ6zOumtURVHz5EopRtibq/yoLL8AWJOiWkVCzwje1gVFGl7jsoTryzCJOgwu1fbnuwrdihHzx7VScvW+PUOr6ubzMNYwnQehcXSLBOR7Qyowt34g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YoRF28FXZfhL3Iah4DGN0tzBhGSeQWVvgGrowbXPP2c=; b=QKYWJriSjEXGlfMsKgdfY5CPnG9+aprdPUL4aAQtBWHs2/XsYs8ofLKEJ1niIMfgdxtd/8g3VSTRyW4BklfLqpn4UkpvGb1/6NlIrwxM9XSxzYZoZFO7ONc8Qp+hUPInRyOrL4L0hrM1wR05gaXts6YypvuLbzlgVQgdhKtMKHDFShUeG6SinNSgdkYKAyiZ8AXl4Vh2742Kb2I0B5eqL8s94xyro6xCf6148zkSNP9/rk/exBuQgUfT8Qw1xO3IdcQalOygV+zmmuc2KFr6yE71Ee+OyF9a2R6NY2V4El0dosjcPpkYdHBcEfG0RURLP+JP08lcftiugc47UKiJ8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YoRF28FXZfhL3Iah4DGN0tzBhGSeQWVvgGrowbXPP2c=; b=rrk/5sC9Z7JnVFkGIxWXE8CG0Q+JyC2CBURCS1IGMEpSy6uZEqQfRNbTCtDzk2ihyl0bP+WjcVsU9dOsNSDbLMwFQNw9MeGvbvcblJ5EGTSAz1sRI/cFyuD8MrXMPdEXOeEMVgGt9x3hH5ykCvzS2/h4gYjxZTve/qYmcZZQ0sU= Received: from CH2PR22MB2086.namprd22.prod.outlook.com (20.180.11.136) by CH2PR22MB1880.namprd22.prod.outlook.com (10.141.57.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Tue, 4 Feb 2020 09:44:44 +0000 Received: from CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::fc4c:de9:3fcd:96dd]) by CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::fc4c:de9:3fcd:96dd%7]) with mapi id 15.20.2686.031; Tue, 4 Feb 2020 09:44:44 +0000 From: Mike Bishop To: Lucas Pardue , Ian Swett CC: IETF QUIC WG , Ryan Hamilton , Renjie Tang Subject: RE: [HTTP/3]Sending reserved frame before SETTINGS Thread-Topic: [HTTP/3]Sending reserved frame before SETTINGS Thread-Index: AQHV2M65W8Z0mPI6iUGx1UM4nN84tagGg+gAgABuAgCAANXrgIADBSFQ Date: Tue, 4 Feb 2020 09:44:44 +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: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2a00:79e1:abc:301:f1e8:a9fb:e811:10f3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8ce5b8b2-f302-4eea-08d7-08d7a956ddb3 x-ms-traffictypediagnostic: CH2PR22MB1880: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39830400003)(346002)(396003)(136003)(199004)(189003)(5660300002)(186003)(316002)(33656002)(52536014)(8936002)(110136005)(9686003)(4326008)(66476007)(54906003)(55016002)(2906002)(66556008)(66446008)(64756008)(508600001)(76116006)(7696005)(71200400001)(81156014)(81166006)(66946007)(8676002)(6506007)(86362001)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR22MB1880; H:CH2PR22MB2086.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: t5bjfN+MOauvOCLZpmsJwhW16K3KBzHB81tj70tt3gm3pEk/DD86svXoCizWY0HIu3f1wMO8bGq91jZCNwdBmMy/T/2+QDvoiMiYIrvCqgiTidmUtLJL28VLLoHEJZUpb6Akt3ldFq9Q/Ox6CFiLiWeuTufYewEjqdOovqK/BQ54g09Wta6ASC1eSmfAA87xaNBKUfUR6SXk9pXemCtDOuNTX3RQ4GSaKhUxuu7dgSkhTo+z9ZqAMduYbgr3ON21Igqsh3YRU8ONVgIGub16QKMHMdErNZCsDNWNNofWTc3Ex0HTqfwwgeh1bBrextr/CMQzlyluvLp2qIsCrHtEelZHoNH9XxGdfSemMX0e+1ZHN7y6sT0pwnSWt/uVUWk3KW5qyhU7yEe/DciHmqT9telhpyP+YcO1AvgBv9HCzNiOwWbY6Uj5KyublWJP1tuJBb2rIYVrBrk+LgGytkzNAOZFlMLPghIggef0Vf7qhqY/Ayel4XGZPjXsY2im79kMnXK7T9PK8qg7cuM7i9GM3A== x-ms-exchange-antispam-messagedata: 8J5oC2M0r4eO+6g2sKa2gnyMQUdhxgq++cqmv0baxkO92b4K50fu4ICifbQYuKytYWcEvJKp/2csLenNOPHKo+tpZMQaN0WCYWdZ/BtbmfC6ci7w5b5E/2f4AMYyB6HGDlfoimeXiHPbJ12mPzJaZMGWRbia3g0I7E8yRzXZ/rq+f9pviLLceBFI4zBPQOP77e+8gFGjOhdneOADb0L+hQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR22MB2086773FDD645B90E5C98B43DA030CH2PR22MB2086namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 8ce5b8b2-f302-4eea-08d7-08d7a956ddb3 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 09:44:44.6271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9alAPYcYC8vq7j2/GQBo1HL1F1vbggEP80PVoRgDaO18+d32W9T4P+Xij6uXX0EByMXRIE5pxe9r7hWE8MZ+fA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR22MB1880 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 09:44:54 -0000 --_000_CH2PR22MB2086773FDD645B90E5C98B43DA030CH2PR22MB2086namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGlzIHRleHQgd2FzIGFkZGVkIHRvIHJlY29yZCBvdXIgZGVjaXNpb24gd2hlbiB0aGlz IHF1ZXN0aW9uIGNhbWUgdXAgYmVmb3JlLiAgQW4gdW5rbm93biBmcmFtZSBpcyBub3QgU0VUVElO R1MuICBJZiB5b3UgZGVmaW5lIHNvbWV0aGluZyBuZXcgKEVYVEVOREVEX1NFVFRJTkdTX1JFQk9S TiksIHlvdSBjYW4gdmVyeSB3ZWxsIG1hbmRhdGUgdGhhdCBpdCBiZSB0aGUgbmV4dCBmcmFtZSBh ZnRlciBTRVRUSU5HUywgYnV0IGl0IGlzIG5vdCBhIFNFVFRJTkdTIGZyYW1lIGFuZCBkb2VzbuKA mXQgc2F0aXNmeSB0aGUgZXhwZWN0YXRpb24gdG8gc2VlIGEgU0VUVElOR1MgZnJhbWUgdGhlcmUu DQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEx1Y2Fz IFBhcmR1ZQ0KU2VudDogU3VuZGF5LCBGZWJydWFyeSAyLCAyMDIwIDEyOjM0IFBNDQpUbzogSWFu IFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogSUVURiBR VUlDIFdHIDxxdWljQGlldGYub3JnPjsgUnlhbiBIYW1pbHRvbiA8cnlhbkBvcHRpbWlzbS5jYz47 IFJlbmppZSBUYW5nIDxyZW5qaWV0YW5nPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbSFRUUC8zXVNlbmRpbmcgcmVzZXJ2ZWQgZnJhbWUgYmVmb3JlIFNFVFRJTkdT DQoNCkkgdGhpbmsgdGhlIGRlc2lnbiBvZiB0aGlzIGlzIG9rIGFzIGlzLg0KDQpPbiBTYXQsIDEg RmViIDIwMjAsIDIyOjQ5IElhbiBTd2V0dCwgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5p ZXRmLm9yZzxtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYuLm9yZz4+IHdyb3RlOg0KVGhh bmtzIGZvciBicmluZ2luZyB0aGlzIHVwIFJlbmppZS4gIEkgYWdyZWUgdGhlIHN1YnNlcXVlbnQg dGV4dCBzZWVtcyB0byBjbGFyaWZ5IHRoZSBhbnN3ZXIuDQoNCkhvd2V2ZXIsIGlzIHRoYXQgdGhl IGJlaGF2aW9yIHdlIHdhbnQsIGdpdmVuIGl0IGRvZXMgbGltaXQgZXh0ZW5zaWJpbGl0eSBpbiBz b21lIHNtYWxsIHdheXM/DQoNCk9uIFNhdCwgRmViIDEsIDIwMjAgYXQgMTE6MjUgQU0gUnlhbiBI YW1pbHRvbiA8cnlhbkBvcHRpbWlzbS5jYzxtYWlsdG86cnlhbkBvcHRpbWlzbS5jYz4+IHdyb3Rl Og0KV293LCBpbnRlcmVzdGluZyBxdWVzdGlvbiENCg0KNi4yLjEgcmVxdWlyZXMgdGhlIFNFVFRJ TkdTIGZyYW1lIHRvIGJlIGZpcnN0IG9uIHRoZSBjb250cm9sIGZyYW1lOg0KDQoNCiAgIElmIHRo ZSBmaXJzdCBmcmFtZSBvZiB0aGUgY29udHJvbCBzdHJlYW0gaXMgYW55IG90aGVyIGZyYW1lDQoN CiAgIHR5cGUsIHRoaXMgTVVTVCBiZSB0cmVhdGVkIGFzIGEgY29ubmVjdGlvbiBlcnJvciBvZiB0 eXBlDQoNCiAgIEgzX01JU1NJTkdfU0VUVElOR1MuDQoNCldoZXJlYXMgNy4yLjkgc2F5cyByZXNl cnZlZCBmcmFtZXMgaGF2ZSBubyBzZW1hbnRpYyBtZWFuaW5nOg0KDQoNCiAgIEZyYW1lIHR5cGVz IG9mIHRoZSBmb3JtYXQgIjB4MWYgKiBOICsgMHgyMSIgZm9yIGludGVnZXIgdmFsdWVzIG9mIE4N Cg0KICAgYXJlIHJlc2VydmVkIHRvIGV4ZXJjaXNlIHRoZSByZXF1aXJlbWVudCB0aGF0IHVua25v d24gdHlwZXMgYmUNCg0KICAgaWdub3JlZCAoU2VjdGlvbiA5PGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXF1aWMtaHR0cC0yNSNzZWN0aW9uLTk+KS4gIFRoZXNlIGZyYW1l cyBoYXZlIG5vIHNlbWFudGljcywgYW5kIGNhbiBiZSBzZW50DQoNCiAgIG9uIGFueSBvcGVuIHN0 cmVhbSB3aGVuIGFwcGxpY2F0aW9uLWxheWVyIHBhZGRpbmcgaXMgZGVzaXJlZC4NCg0KDQpUaGlz IHNvdW5kcyBsaWtlIGEgY29uZmxpY3Qgc2luY2Ugc29tZXRoaW5nIHRoYXQgaGFzIG5vIHNlbWFu dGljcyBzZWVtcyBsaWtlIGl0IHNob3VsZCBub3QgY2F1c2UgZXJyb3JzISBIb3dldmVyLCBsb29r aW5nIFNlY3Rpb24gOSBJIHRoaW5rIHdlIGZpbmQgdGhlIHJlc29sdXRpb246DQoNCiAgIEltcGxl bWVudGF0aW9ucyBNVVNUIGlnbm9yZSB1bmtub3duIG9yIHVuc3VwcG9ydGVkIHZhbHVlcyBpbiBh bGwNCg0KICAgZXh0ZW5zaWJsZSBwcm90b2NvbCBlbGVtZW50cy4gIEltcGxlbWVudGF0aW9ucyBN VVNUIGRpc2NhcmQgZnJhbWVzDQoNCiAgIGFuZCB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIHRoYXQg aGF2ZSB1bmtub3duIG9yIHVuc3VwcG9ydGVkIHR5cGVzLg0KDQogICBUaGlzIG1lYW5zIHRoYXQg YW55IG9mIHRoZXNlIGV4dGVuc2lvbiBwb2ludHMgY2FuIGJlIHNhZmVseSB1c2VkIGJ5DQoNCiAg IGV4dGVuc2lvbnMgd2l0aG91dCBwcmlvciBhcnJhbmdlbWVudCBvciBuZWdvdGlhdGlvbi4gIEhv d2V2ZXIsIHdoZXJlDQoNCiAgIGEga25vd24gZnJhbWUgdHlwZSBpcyByZXF1aXJlZCB0byBiZSBp biBhIHNwZWNpZmljIGxvY2F0aW9uLCBzdWNoIGFzDQoNCiAgIHRoZSBTRVRUSU5HUyBmcmFtZSBh cyB0aGUgZmlyc3QgZnJhbWUgb2YgdGhlIGNvbnRyb2wgc3RyZWFtIChzZWUNCg0KICAgU2VjdGlv biA2LjIuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWljLWh0dHAt MjUjc2VjdGlvbi02Li4uLjIuMT4pLCBhbiB1bmtub3duIGZyYW1lIHR5cGUgZG9lcyBub3Qgc2F0 aXNmeSB0aGF0DQoNCiAgIHJlcXVpcmVtZW50IGFuZCBTSE9VTEQgYmUgdHJlYXRlZCBhcyBhbiBl cnJvci4NCg0KDQoNClNvIGl0IHNlZW1zIHRoYXQgaXQncyBpbGxlZ2FsIHRvIHNlbmQgYSBHUkVB U0VEIGZyYW1lIGJlZm9yZSB0aGUgU0VUVElOR1MgZnJhbWUuIERvZXMgdGhhdCBzb3VuZCByaWdo dCB0byB5b3U/DQoNCg0KDQpDaGVlcnMsDQoNCg0KDQpSeWFuDQoNCk9uIEZyaSwgSmFuIDMxLCAy MDIwIGF0IDExOjEwIFBNIFJlbmppZSBUYW5nIDxyZW5qaWV0YW5nPTQwZ29vZ2xlLmNvbUBkbWFy Yy5pZXRmLm9yZzxtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpI aSBhbGwsDQoNCldoZW4gSSB3YXMgaW1wbGVtZW50aW5nIGdyZWFzaW5nIGZvciBIVFRQLzMgZnJh bWVzLCBJIGNhbWUgYWNyb3NzIGEgcG90ZW50aWFsIGNvbmZ1c2lvbi4NCg0KUHJlc3VtYWJseSwg aWYgYSBub24tcmVzZXJ2ZWQgdW5rbm93biBmcmFtZSBpcyByZWNlaXZlZCBiZWZvcmUgU0VUVElO R1Mgb24gYSBjb250cm9sIHN0cmVhbSwgdGhlIGNvbm5lY3Rpb24gc2hvdWxkIGJlIGNsb3NlZC4N Cg0KQnV0IGlmIGEgcmVzZXJ2ZWQgZnJhbWUgaXMgcmVjZWl2ZWQgYmVmb3JlIFNFVFRJTkdTIGZy YW1lIG9uIGEgY29udHJvbCBzdHJlYW0sIGRvZXMgaXQgY291bnQgYXMgYW4gZXJyb3IgYW5kIGNs b3NlIHRoZSBjb25uZWN0aW9uPyBPciBzaG91bGQgaXQgc2ltcGx5IGJlIGlnbm9yZWQgYmVjYXVz ZSBpdCBoYXMgbm8gc2VtYW50aWMgbWVhbmluZz8NCg0KVGhhbmtzIQ0KUmVuamllDQo= --_000_CH2PR22MB2086773FDD645B90E5C98B43DA030CH2PR22MB2086namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQg TVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB0aGlzIHRleHQgd2FzIGFkZGVkIHRvIHJlY29yZCBvdXIg ZGVjaXNpb24gd2hlbiB0aGlzIHF1ZXN0aW9uIGNhbWUgdXAgYmVmb3JlLiZuYnNwOyBBbiB1bmtu b3duIGZyYW1lIGlzIG5vdCBTRVRUSU5HUy4mbmJzcDsgSWYgeW91IGRlZmluZSBzb21ldGhpbmcg bmV3IChFWFRFTkRFRF9TRVRUSU5HU19SRUJPUk4pLCB5b3UgY2FuIHZlcnkgd2VsbCBtYW5kYXRl IHRoYXQgaXQgYmUgdGhlIG5leHQgZnJhbWUNCjxpPmFmdGVyPC9pPiBTRVRUSU5HUywgYnV0IGl0 IGlzIG5vdCBhIFNFVFRJTkdTIGZyYW1lIGFuZCBkb2VzbuKAmXQgc2F0aXNmeSB0aGUgZXhwZWN0 YXRpb24gdG8gc2VlIGEgU0VUVElOR1MgZnJhbWUgdGhlcmUuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPkZyb206PC9iPiBRVUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9u IEJlaGFsZiBPZiA8L2I+DQpMdWNhcyBQYXJkdWU8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBG ZWJydWFyeSAyLCAyMDIwIDEyOjM0IFBNPGJyPg0KPGI+VG86PC9iPiBJYW4gU3dldHQgJmx0O2lh bnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IElF VEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IFJ5YW4gSGFtaWx0b24gJmx0O3J5YW5A b3B0aW1pc20uY2MmZ3Q7OyBSZW5qaWUgVGFuZyAmbHQ7cmVuamlldGFuZz00MGdvb2dsZS5jb21A ZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSFRUUC8zXVNlbmRp bmcgcmVzZXJ2ZWQgZnJhbWUgYmVmb3JlIFNFVFRJTkdTPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHRoaW5rIHRoZSBkZXNpZ24gb2YgdGhpcyBpcyBvayBhcyBpcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgMSBGZWIgMjAyMCwg MjI6NDkgSWFuIFN3ZXR0LCAmbHQ7aWFuc3dldHQ9PGEgaHJlZj0ibWFpbHRvOjQwZ29vZ2xlLmNv bUBkbWFyYy5pZXRmLi5vcmciPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgYnJpbmdpbmcgdGhpcyB1cCBSZW5qaWUuJm5ic3A7IEkg YWdyZWUgdGhlIHN1YnNlcXVlbnQgdGV4dCBzZWVtcyB0byBjbGFyaWZ5IHRoZSBhbnN3ZXIuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCBpcyB0 aGF0IHRoZSBiZWhhdmlvciB3ZSB3YW50LCBnaXZlbiBpdCBkb2VzIGxpbWl0IGV4dGVuc2liaWxp dHkgaW4gc29tZSBzbWFsbCB3YXlzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIEZlYiAxLCAyMDIwIGF0IDExOjI1IEFNIFJ5YW4g SGFtaWx0b24gJmx0OzxhIGhyZWY9Im1haWx0bzpyeWFuQG9wdGltaXNtLmNjIj5yeWFuQG9wdGlt aXNtLmNjPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPldvdywgaW50 ZXJlc3RpbmcgcXVlc3Rpb24hPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1 Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPjYuMi4xIHJlcXVpcmVzIHRo ZSBTRVRUSU5HUyBmcmFtZSB0byBiZSBmaXJzdCBvbiB0aGUgY29udHJvbCBmcmFtZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9 ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBJZiB0aGUgZmlyc3QgZnJhbWUgb2YgdGhlIGNvbnRyb2wgc3RyZWFtIGlzIGFueSBvdGhlciBm cmFtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyB0eXBlLCB0aGlzIE1VU1QgYmUgdHJlYXRlZCBhcyBhIGNvbm5lY3Rp b24gZXJyb3Igb2YgdHlwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBIM19NSVNTSU5HX1NFVFRJTkdTLiA8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj aGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPldoZXJlYXMgNy4yLjkgc2F5cyByZXNlcnZlZCBmcmFt ZXMgaGF2ZSBubyBzZW1hbnRpYyBtZWFuaW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEZyYW1lIHR5cGVzIG9mIHRoZSBm b3JtYXQgJnF1b3Q7MHgxZiAqIE4gJiM0MzsgMHgyMSZxdW90OyBmb3IgaW50ZWdlciB2YWx1ZXMg b2YgTjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBhcmUgcmVzZXJ2ZWQgdG8gZXhlcmNpc2UgdGhlIHJlcXVpcmVtZW50 IHRoYXQgdW5rbm93biB0eXBlcyBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpZ25vcmVkICg8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWljLWh0dHAtMjUjc2VjdGlvbi05 IiB0YXJnZXQ9Il9ibGFuayI+U2VjdGlvbiA5PC9hPikuJm5ic3A7IFRoZXNlIGZyYW1lcyBoYXZl IG5vIHNlbWFudGljcywgYW5kIGNhbiBiZSBzZW50PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG9uIGFueSBvcGVuIHN0 cmVhbSB3aGVuIGFwcGxpY2F0aW9uLWxheWVyIHBhZGRpbmcgaXMgZGVzaXJlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIHNvdW5kcyBsaWtlIGEgY29uZmxp Y3Qgc2luY2Ugc29tZXRoaW5nIHRoYXQgaGFzIG5vIHNlbWFudGljcyBzZWVtcyBsaWtlIGl0IHNo b3VsZCBub3QgY2F1c2UgZXJyb3JzISBIb3dldmVyLCBsb29raW5nIFNlY3Rpb24gOSBJIHRoaW5r IHdlIGZpbmQgdGhlIHJlc29sdXRpb246PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IEltcGxlbWVudGF0aW9ucyBNVVNUIGlnbm9yZSB1bmtub3duIG9y IHVuc3VwcG9ydGVkIHZhbHVlcyBpbiBhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZXh0ZW5zaWJsZSBwcm90b2Nv bCBlbGVtZW50cy4mbmJzcDsgSW1wbGVtZW50YXRpb25zIE1VU1QgZGlzY2FyZCBmcmFtZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgYW5kIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgdGhhdCBoYXZlIHVua25vd24gb3Ig dW5zdXBwb3J0ZWQgdHlwZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoaXMgbWVhbnMgdGhhdCBhbnkgb2YgdGhl c2UgZXh0ZW5zaW9uIHBvaW50cyBjYW4gYmUgc2FmZWx5IHVzZWQgYnk8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZXh0 ZW5zaW9ucyB3aXRob3V0IHByaW9yIGFycmFuZ2VtZW50IG9yIG5lZ290aWF0aW9uLiZuYnNwOyBI b3dldmVyLCB3aGVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhIGtub3duIGZyYW1lIHR5cGUgaXMgcmVxdWlyZWQg dG8gYmUgaW4gYSBzcGVjaWZpYyBsb2NhdGlvbiwgc3VjaCBhczxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aGUgU0VU VElOR1MgZnJhbWUgYXMgdGhlIGZpcnN0IGZyYW1lIG9mIHRoZSBjb250cm9sIHN0cmVhbSAoc2Vl PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXF1aWMtaHR0cC0yNSNzZWN0aW9uLTYuLi4uMi4xIiB0YXJnZXQ9Il9ibGFuayI+U2VjdGlv biA2LjIuMTwvYT4pLCBhbiB1bmtub3duIGZyYW1lIHR5cGUgZG9lcyBub3Qgc2F0aXNmeSB0aGF0 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IHJlcXVpcmVtZW50IGFuZCBTSE9VTEQgYmUgdHJlYXRlZCBhcyBhbiBlcnJv ci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdl Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMyMjIyMjIiPlNvIGl0IHNlZW1zIHRoYXQgaXQncyBpbGxlZ2FsIHRvIHNlbmQgYSBHUkVB U0VEIGZyYW1lIGJlZm9yZSB0aGUgU0VUVElOR1MgZnJhbWUuIERvZXMgdGhhdCBzb3VuZCByaWdo dCB0byB5b3U/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVh ay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+Q2hlZXJz LDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZv cmU6cGFnZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+Unlhbjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKYW4gMzEsIDIwMjAgYXQgMTE6MTAgUE0g UmVuamllIFRhbmcgJmx0O3JlbmppZXRhbmc9PGEgaHJlZj0ibWFpbHRvOjQwZ29vZ2xlLmNvbUBk bWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9y ZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4gSSB3YXMgaW1wbGVtZW50aW5nIGdyZWFzaW5nIGZv ciBIVFRQLzMgZnJhbWVzLCBJIGNhbWUgYWNyb3NzIGEgcG90ZW50aWFsIGNvbmZ1c2lvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJlc3Vt YWJseSwgaWYgYSBub24tcmVzZXJ2ZWQgdW5rbm93biBmcmFtZSBpcyByZWNlaXZlZCBiZWZvcmUg U0VUVElOR1Mgb24gYSBjb250cm9sIHN0cmVhbSwgdGhlIGNvbm5lY3Rpb24gc2hvdWxkIGJlIGNs b3NlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QnV0IGlmIGEgcmVzZXJ2ZWQgZnJhbWUgaXMgcmVjZWl2ZWQgYmVmb3JlIFNFVFRJTkdTIGZy YW1lIG9uIGEgY29udHJvbCBzdHJlYW0sIGRvZXMgaXQgY291bnQgYXMgYW4gZXJyb3IgYW5kIGNs b3NlIHRoZSBjb25uZWN0aW9uPyBPciBzaG91bGQgaXQmbmJzcDtzaW1wbHkgYmUgaWdub3JlZCBi ZWNhdXNlIGl0IGhhcyBubyBzZW1hbnRpYyBtZWFuaW5nPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MhPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZW5qaWU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_CH2PR22MB2086773FDD645B90E5C98B43DA030CH2PR22MB2086namp_-- From nobody Tue Feb 4 03:12:07 2020 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 67975120108 for ; Tue, 4 Feb 2020 03:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 125lMSsh7jxQ for ; Tue, 4 Feb 2020 03:12:03 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 089C8120130 for ; Tue, 4 Feb 2020 03:12:03 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id m16so22441896wrx.11 for ; Tue, 04 Feb 2020 03:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pIPrcJqCNHHYxEKCPQ5LY6Pc5NkgICEw6m/GwKalnlM=; b=kRWw+6g60o4Y8O83m800iksat2n/9keaKcENeAX1gzt/IX3xbU/priCyl3HGyRMfjD lxPjqjbm7ltakUfs28xteFxlklKbJZROfO8WxeA1+R3CRTm8QUIWGSshJgaJo5qeYWrb +SGxNu5ozikepz/nHFKBcoNPD0GEz0rePS8AiQdgQRcM3Wb/tfotO0TcirA/jb+MCaBT MEsi9Br3D5FFoSUNGmjPKzRVU00To613zhBjI2zjK4IffntVJrHjuBX4PdBUIEGEmiRt OkRMeSSz7Cycj9/JnPa31jutgMQBVdt+pbu/6Rski9wFY/ZAibGDHySelz6ao3b/z5ce JxIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pIPrcJqCNHHYxEKCPQ5LY6Pc5NkgICEw6m/GwKalnlM=; b=Xw2jzGkxKQqgk18TDIpWg6t/JPuJRaQsWaqTFmG+8O9T/5/20Lzd1j82U3IvNS/AMJ Jy4CkJUWgbm7+DDhgkG1iMQBA4UcC2FKGJsTQcHFC5CwwVwoyuokLlMuhIYMr2yAU46F TQ3aDrXCIFeFynVcmpOwtaFmf8bHgI0n45A91AlaXBZA3Nxtr1Q+8WFbfz9tkUYqjHe1 Yj3oJU7KaUH4Lo9qIJyzG53RSySTOxfxT6yWTB+tY4BYfvCPHtFSqX3hkGakGKPPAdMh 8GKNuxrY4XcEyHjeXgnPAFnQW20oDmBwFc+ZWy0lDh83/sb5Vzbg5Fx5YEEzKC0whfcQ IwTQ== X-Gm-Message-State: APjAAAUDAOkc4PvAyjld7RqwRDf2BhjgQc2HznL+rFI4TJ5nkRTuBjuK vGnkVPU2UdwgB9y2U4ri0iFjRUhqLnYsGJZjeIAN6g== X-Google-Smtp-Source: APXvYqxELIL6olDksXT+rEzc6zriKezI0obuSw8eegsqi1FvQfM6v98eAlWLZK7Sd4j/w1Ow2LKU0VRSqPQukG0Nxjg= X-Received: by 2002:adf:e8ca:: with SMTP id k10mr20467930wrn.50.1580814721233; Tue, 04 Feb 2020 03:12:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Tue, 4 Feb 2020 06:11:49 -0500 Message-ID: Subject: Re: [HTTP/3]Sending reserved frame before SETTINGS To: Mike Bishop Cc: Lucas Pardue , IETF QUIC WG , Ryan Hamilton , Renjie Tang Content-Type: multipart/alternative; boundary="000000000000ea9bdf059dbe1b69" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 11:12:06 -0000 --000000000000ea9bdf059dbe1b69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thinking more, I don't think we're losing much with this restriction, so I'm fine with it as is. On Tue, Feb 4, 2020 at 4:44 AM Mike Bishop wrote: > Yes, this text was added to record our decision when this question came u= p > before. An unknown frame is not SETTINGS. If you define something new > (EXTENDED_SETTINGS_REBORN), you can very well mandate that it be the next > frame *after* SETTINGS, but it is not a SETTINGS frame and doesn=E2=80=99= t > satisfy the expectation to see a SETTINGS frame there. > > > > *From:* QUIC *On Behalf Of * Lucas Pardue > *Sent:* Sunday, February 2, 2020 12:34 PM > *To:* Ian Swett > *Cc:* IETF QUIC WG ; Ryan Hamilton ; > Renjie Tang > *Subject:* Re: [HTTP/3]Sending reserved frame before SETTINGS > > > > I think the design of this is ok as is. > > > > On Sat, 1 Feb 2020, 22:49 Ian Swett, <40google.com@dmarc.ietf..org>> wrote: > > Thanks for bringing this up Renjie. I agree the subsequent text seems to > clarify the answer. > > > > However, is that the behavior we want, given it does limit extensibility > in some small ways? > > > > On Sat, Feb 1, 2020 at 11:25 AM Ryan Hamilton wrote: > > Wow, interesting question! > > > > 6.2.1 requires the SETTINGS frame to be first on the control frame: > > > > If the first frame of the control stream is any other frame > > type, this MUST be treated as a connection error of type > > H3_MISSING_SETTINGS. > > > > Whereas 7.2.9 says reserved frames have no semantic meaning: > > > > Frame types of the format "0x1f * N + 0x21" for integer values of N > > are reserved to exercise the requirement that unknown types be > > ignored (Section 9 ). These frames have no semantics, and can be sent > > on any open stream when application-layer padding is desired. > > > > This sounds like a conflict since something that has no semantics seems > like it should not cause errors! However, looking Section 9 I think we fi= nd > the resolution: > > Implementations MUST ignore unknown or unsupported values in all > > extensible protocol elements. Implementations MUST discard frames > > and unidirectional streams that have unknown or unsupported types. > > This means that any of these extension points can be safely used by > > extensions without prior arrangement or negotiation. However, where > > a known frame type is required to be in a specific location, such as > > the SETTINGS frame as the first frame of the control stream (see > > Section 6.2.1 ), an unknown frame type does not satisfy that > > requirement and SHOULD be treated as an error. > > > > So it seems that it's illegal to send a GREASED frame before the SETTINGS= frame. Does that sound right to you? > > > > Cheers, > > > > Ryan > > > > On Fri, Jan 31, 2020 at 11:10 PM Renjie Tang 40google.com@dmarc.ietf.org> wrote: > > Hi all, > > > > When I was implementing greasing for HTTP/3 frames, I came across a > potential confusion. > > > > Presumably, if a non-reserved unknown frame is received before SETTINGS o= n > a control stream, the connection should be closed. > > > > But if a reserved frame is received before SETTINGS frame on a control > stream, does it count as an error and close the connection? Or should > it simply be ignored because it has no semantic meaning? > > > > Thanks! > > Renjie > > --000000000000ea9bdf059dbe1b69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thinking more, I don't think we're losing much wit= h this restriction, so I'm fine with it as is.

On Tue, Feb 4, 2020 at 4:= 44 AM Mike Bishop <mbishop@evequefou.be> wrote:

Yes, this text was added to record our decision when= this question came up before.=C2=A0 An unknown frame is not SETTINGS.=C2= =A0 If you define something new (EXTENDED_SETTINGS_REBORN), you can very we= ll mandate that it be the next frame after SETTINGS, but it is not a SETTINGS frame and doesn=E2=80=99t s= atisfy the expectation to see a SETTINGS frame there.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = Lucas Pardue
Sent: Sunday, February 2, 2020 12:34 PM
To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
Cc: IETF QUIC WG <quic@ietf.org>; Ryan Hamilton <ryan@optimism.cc>; Renjie T= ang <renjietang=3D40google.com@dmarc.ietf.org>
Subject: Re: [HTTP/3]Sending reserved frame before SETTINGS

=C2=A0

I think the design of this is ok as is.

=C2=A0

On Sat, 1 Feb 2020, 22:49 Ian Swett, <ianswett=3D= 40google.= com@dmarc.ietf.org> wrote:

Thanks for bringing this up Renjie.=C2=A0 I agree th= e subsequent text seems to clarify the answer.

=C2=A0

However, is that the behavior we want, given it does= limit extensibility in some small ways?

=C2=A0

On Sat, Feb 1, 2020 at 11:25 AM Ryan Hamilton <ryan@optimism.cc>= ; wrote:

Wow, interesting question!

=C2=A0

6.2.1 requires the SETTINGS frame to be first on the control fr= ame:

=C2=A0

=C2=A0=C2=A0 I=
f the first frame of the control stream is any other frame
=C2=A0=C2=A0 type, this MUST be treated as=
 a connection error of type
=C2=A0=C2=A0 H3_MISSING_SETTINGS. <=
u>

=C2=A0

Whereas 7.2.9 says reserved frames have no semantic meaning:=

=C2=A0

=C2=A0=C2=A0 F=
rame types of the format "0x1f * N + 0x21" for integer values of =
N
=C2=A0=C2=A0 are reserved to exercise the =
requirement that unknown types be
=C2=A0=C2=A0 ignored (Sec=
tion 9).=C2=A0 These frames have no semantics, and can be sent
=C2=A0=C2=A0 on any open stream when appli=
cation-layer padding is desired.
=C2=A0<=
u>

This sounds like a conflict since something that has no semanti= cs seems like it should not cause errors! However, looking Section 9 I thin= k we find the resolution:

=C2=A0=C2=A0 I=
mplementations MUST ignore unknown or unsupported values in all
=C2=A0=C2=A0 extensible protocol elements.=
=C2=A0 Implementations MUST discard frames
=C2=A0=C2=A0 and unidirectional streams th=
at have unknown or unsupported types.
=C2=A0=C2=A0 This means that any of these =
extension points can be safely used by
=C2=A0=C2=A0 extensions without prior arra=
ngement or negotiation.=C2=A0 However, where
=C2=A0=C2=A0 a known frame type is require=
d to be in a specific location, such as
=C2=A0=C2=A0 the SETTINGS frame as the fir=
st frame of the control stream (see
=C2=A0=C2=A0 Secti=
on 6.2.1), an unknown frame type does not satisfy that
=C2=A0=C2=A0 requirement and SHOULD be tre=
ated as an error.
=C2=A0<=
u>
So it seems that i=
t's illegal to send a GREASED frame before the SETTINGS frame. Does tha=
t sound right to you?
=C2=A0
Cheers,
=C2=A0<=
u>
Ryan

=C2=A0

On Fri, Jan 31, 2020 at 11:10 PM Renjie Tang <ren= jietang=3D= 40google.com@dmarc.ietf.org> wrote:

Hi all,

=C2=A0

When I was implementing greasing for HTTP/3 frames, = I came across a potential confusion.

=C2=A0

Presumably, if a non-reserved unknown frame is recei= ved before SETTINGS on a control stream, the connection should be closed.

=C2=A0

But if a reserved frame is received before SETTINGS = frame on a control stream, does it count as an error and close the connecti= on? Or should it=C2=A0simply be ignored because it has no semantic meaning?=

=C2=A0

Thanks!

Renjie

--000000000000ea9bdf059dbe1b69-- From nobody Tue Feb 4 05:44:42 2020 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 284A01200C4 for ; Tue, 4 Feb 2020 05:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 OTr2-r1yMNZl for ; Tue, 4 Feb 2020 05:44:39 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 C5FDA120020 for ; Tue, 4 Feb 2020 05:44:38 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id t23so12205466lfk.6 for ; Tue, 04 Feb 2020 05:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KONmK6LXjjEiybZb9A3Q5e2WUvwAzYX5vakZwPln7aI=; b=b0djeZuxX7kV/6X4k8M/2/WgyfL2clofG4iNKFKXVPJ2qsgQMAlyjyZgdxxQlU99iY LyV9GYedZRLm1h0RPo02yq/tm+N+OGdDGE4ARIc3Mje1delGyvG0Ml8MmiRunxoNcNvJ f+zOBQWionrMxCK1IOlcVHlVAZJ1AThlzu1EqIGlw/vvzKnLfQ+Bvrh8akXNSBDLfSW/ RfNIweZpzttvWZP3ZYrmJnhPQ55IW/s02I3evNDOnF6CDBnJfj2+C1IO2gZKNAxzksZx gQsgoQmIVnFf/oRgGpEzZ98Ts+clat3OILYYK54YZX2gy2fuDzKwfs+uTpM0z4u62Yn6 C2aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KONmK6LXjjEiybZb9A3Q5e2WUvwAzYX5vakZwPln7aI=; b=Kq2TAAnQh6LHjMIGMWAauH4E2O2kRAzQSpI/joBgyYgqOxeG8/mby5xi+UUy472DEj HBbSxEej2wskaR3sjF9nKx0P1xNitwDXue5voDKmA9lKP5WzvE/q3YPolssOTrudROgs Q2koIYcYOzNEakphHrXcZO0PpeD6PCnA2e9hB5RNOnyYI7w7SA5tnvCFPaWkRhZLQBOj RPBE1VpDYGnD0qAH9XhXsydzUKGRn2GUC/RPwUKr9iemcyHJKUJ/u37MGhV00S7EVKBD 4mKjEdCxrDofkuGDvWywF+hGs5vD0HfF1654iTx1JmrYpERj2N4r1Uu3b1Wavmi9szyr /ypg== X-Gm-Message-State: APjAAAXaGacDmHSjq78nx3fe1VBivZ+j1CiSzYGhgVBAFM0GzMIQDayn FDIWeUg6n5TTfgloZNpMu5nLQkyQj1XObFYUJD1w8w== X-Google-Smtp-Source: APXvYqz/kZtjZlt11voEqyq4cK3iN91FTm2o3cE8zAmIrynofvzKetEwBSOLZbDiM3L6lpQ1QiTyIFC5GpVfCixiU8Y= X-Received: by 2002:a05:6512:64:: with SMTP id i4mr14898069lfo.55.1580823876944; Tue, 04 Feb 2020 05:44:36 -0800 (PST) MIME-Version: 1.0 References: <20200124222434.GA8279@ubuntu-dmitri> <7b228c14-c0d3-6458-77ab-945e713ef429@huitema.net> <20200125135411.GA19655@ubuntu-dmitri> In-Reply-To: From: Eric Rescorla Date: Tue, 4 Feb 2020 05:44:00 -0800 Message-ID: Subject: Re: Alternative ways to keeps ODCID on the server To: Kazuho Oku Cc: Christian Huitema , Marten Seemann , IETF QUIC WG , Dmitri Tikhonov , Ian Swett Content-Type: multipart/alternative; boundary="000000000000a35819059dc03d6d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 13:44:41 -0000 --000000000000a35819059dc03d6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I also agree with dropping the MAY. This seems like a pretty clear case for connection failure. On Tue, Jan 28, 2020 at 3:58 PM Kazuho Oku wrote: > > > 2020=E5=B9=B41=E6=9C=8828=E6=97=A5(=E7=81=AB) 15:45 Christian Huitema : > >> But then, the client that responded to a retry will fail the connection >> if the ODCID parameter is not there. There are two alternative in the ba= d >> token scenario: good faith client with an obsolete new token, or client >> that received a bad faith retry. In the first case, there is no harm >> completing the connection. In the second case, the client will drop it s= o >> there is only a modest issue of temporary resource allocation. >> > > While I agree that the two scenarios being described here are the > possibilities, I now tend to agree that the MAY can be dropped. Previousl= y, > I missed the fact that ODCID has to be carried as a TP (as correctly > pointed out by Marten and Dmitri). > > Regarding attack scenarios, I'd argue that it would be awkward for an > attacker to only send a spoofed packet to the server-side, when a malicio= us > middlebox can also send a packet to the client. I'd also argue that there > are many other ways of spoofing a client-sent Initial packet, and that > having a defense just for retry tokens does not change the picture. > > Therefore, I think dropping the MAY is fine. I think a server can continu= e > to ignore the retry token when it assumes that it was spoofed, but my tak= e > is that it's not worth writing it down. > >> On 1/27/2020 8:35 PM, Marten Seemann wrote: >> >> The client knows if it used a NEW_TOKEN token. More specifically, the >> client knows if it received and responded to a Retry packet. >> >> On Tue, Jan 28, 2020 at 11:21 AM Christian Huitema >> wrote: >> >>> >>> On 1/27/2020 7:11 PM, Marten Seemann wrote: >>> >>> > That's actually what I implemented. If the token can be verified, >>> accept >>> > the connection, treat it as validated. If it cannot be verified, chec= k >>> > whether the token is necessary, e.g., would any incoming connection >>> > trigger retry. If it is necessary, drop the connection; if not >>> > necessary, continue as if no token was there. >>> >>> Doesn't that defeat the purpose of the original_connection_id transport >>> parameter? We introduced it to prevent middleboxes from performing a Re= try. >>> With this logic, a middlebox could perform a Retry, and then corrupt th= e >>> token on the second Initial to trick the server into accepting the >>> connection. >>> Furthermore, client implementation will check for the >>> original_connection_id TP, and fail the connection if this TP is missin= g. >>> >>> The spec also has language that I'd interpret as forbidding this: >>> If the server sends a Retry packet, it MUST include the Destination >>> Connection ID field from the client's first Initial packet in the trans= port >>> parameter. >>> >>> How do you reconcile that requirement with the "NEW TOKEN" mechanism? I= f >>> the Initial packet carries a NEW TOKEN, it will be accepted and there w= on't >>> be any ODCID transport parameter. >>> >>> -- Christian Huitema >>> >> > > -- > Kazuho Oku > --000000000000a35819059dc03d6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also agree with dropping the MAY. This seems like a pret= ty clear case for connection failure.

On Tue, Jan 28, 2020 at 3:58 PM Ka= zuho Oku <kazuhooku@gmail.com= > wrote:


2020=E5=B9=B41=E6=9C=8828=E6=97=A5(=E7=81= =AB) 15:45 Christian Huitema <huitema@huitema.net>:
=20 =20 =20

But then, the client that responded to a retry will fail the connection if the ODCID parameter is not there. There are two alternative in the bad token scenario: good faith client with an obsolete new token, or client that received a bad faith retry. In the first case, there is no harm completing the connection. In the second case, the client will drop it so there is only a modest issue of temporary resource allocation.


While I agree that the two scenarios being described here = are the possibilities, I now tend to agree that the MAY can be dropped. Pre= viously, I missed the fact that ODCID has to be carried as a TP (as correct= ly pointed out by Marten and Dmitri).

Regarding at= tack scenarios, I'd argue that it would be awkward for an attacker to o= nly send a spoofed packet to the server-side, when a malicious middlebox ca= n also send a packet to the client. I'd also argue that there are many = other ways of spoofing a client-sent Initial packet, and that having a defe= nse just for retry tokens does not change the picture.

=
Therefore, I think dropping the MAY is fine. I think a server can cont= inue to ignore the retry token when it assumes that it was spoofed, but my = take is that it's not worth writing it down.

On 1/27/2020 8:35 PM, Marten Seemann wrote:
=20
The client knows if it used a NEW_TOKEN token. More specifically, the client knows if it received and responded to a Retry packet.

On Tue, Jan 28, 2020 at 11:21 AM Christian Huitema <huitema@huitema.net> wrote:


On 1/27/2020 7:11 PM, Marten Seemann wrote:
> That's actually what I implemented. If the token can be verified, accept
> the connection, treat it as validated. If it cannot be verified, check
> whether the token is necessary, e.g., would any incoming connection
> trigger retry. If it is necessary, drop the connection; if not
> necessary, continue as if no token was there.

Doesn't that defeat the purpose of the original_connection_id transport parameter? We introduced it to prevent middleboxes from performing a Retry.
With this logic, a middlebox could perform a Retry, and then corrupt the token on the second Initial to trick the server into accepting the connection.
Furthermore, client implementation will check for the original_connection_id TP, and fail the connection if this TP is missing.

The spec also has language that I'd interpret as forbidding this:
If the server sends a Retry packet, it MUST include the Destination Connection ID field from the client's first Initial packet in the transport parameter.

How do you reconcile that requirement with the "NEW TOKEN" mechanism? If the Initial packet carries a NEW TOKEN, it will be accepted and there won't be any ODCID transport parameter.

-- Christian Huitema



--
Kazuho Oku
--000000000000a35819059dc03d6d-- From nobody Tue Feb 4 08:16:33 2020 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 E71F912011F for ; Tue, 4 Feb 2020 08:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 CeJGCPB3k-9O for ; Tue, 4 Feb 2020 08:16:29 -0800 (PST) Received: from vs24.mail.saunalahti.fi (vs24.mail.saunalahti.fi [62.142.117.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729AC120137 for ; Tue, 4 Feb 2020 08:16:29 -0800 (PST) Received: from vs24.mail.saunalahti.fi (localhost [127.0.0.1]) by vs24.mail.saunalahti.fi (Postfix) with ESMTP id 7BE3620E92 for ; Tue, 4 Feb 2020 18:16:27 +0200 (EET) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by vs24.mail.saunalahti.fi (Postfix) with ESMTP id 70DFF20114 for ; Tue, 4 Feb 2020 18:16:27 +0200 (EET) Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw02.mail.saunalahti.fi (Postfix) with ESMTPSA id 6A08240015 for ; Tue, 4 Feb 2020 18:16:26 +0200 (EET) Received: from [100.72.42.128] (unknown [104.132.228.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id BF6996033FD for ; Tue, 4 Feb 2020 18:16:21 +0200 (EET) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_87B72D72-0E95-43F0-AAD5-AD17FB70A60C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Please send interim presentations Message-Id: <15406DDB-86CC-416B-BE6C-6028F0E4F7C1@eggert.org> Date: Tue, 4 Feb 2020 17:16:20 +0100 To: IETF QUIC WG X-MailScanner-ID: BF6996033FD.A4618 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 16:16:31 -0000 --Apple-Mail=_87B72D72-0E95-43F0-AAD5-AD17FB70A60C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, if you are presenting at the interim during the next few days, please = send your PDF slides as a PR against the wg-materials repo now. Thanks, Lars --Apple-Mail=_87B72D72-0E95-43F0-AAD5-AD17FB70A60C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl45mNQACgkQVLXDCb9w wVcGow//alHlRGPl3sgPbS4oxXBhgZs3n7m84bIce3/6C5qagRxoY/b1+a0GHNuP wma7pIGZZqkDpdwfiJxTzxhiDTFNbDHm5/a+HdP1uRRWhX9yoCOirLWgZf+nAzpy HYq2lonThdIOLh14NBfe7aZZdinLW99Ro2NtNacFU05h+npxWtvWzLFyuvKKU+WJ 1G/GVb8sca/i39DZj9gTrMSQEzuCezN5V2bTCa5fq0NbxBTYu1KoIeRjvvIxYp84 1mFNIN5m1U/ocdT9533WYfFUArDdq/MiU8P+dyUhS+owZ3EIWyzh5z9NhCMzUddO r0Dxrz0GrhP+ZNZYa8kT6tK3aUQWvNt52DrFajQ4cbpOnRk7Uzucam/RU9qZKrMg 8wExkAeZMTSYVhevpRYIAUEcesXNhaSeVHPBdycjtActaXGN1hqArYA5gWRJiz+8 BtZ4lkDq8OTSI3is6dUaZx8PPaiuTfdAqEZYdQdPBYNjnhfWgU0dM5xiwWd0os/e DLHjftEEuMKhVQOJqLIa6icXdBzt5RezZ5fas4Ym38BLOZm6vnIJP2oDpLb9BX62 46gj3j3co/rXXibC6mqo6ibcEbEQsi4wAteHIdMYqR6StoM0w7pxBGAxM00DJ2jZ aZGX8zhjMRwyXV7Id0nKMWiuWE4fI91CUv+Um0a0OsVcNWd/MWs= =WxhU -----END PGP SIGNATURE----- --Apple-Mail=_87B72D72-0E95-43F0-AAD5-AD17FB70A60C-- From nobody Tue Feb 4 11:24:19 2020 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 BB0641201EF; Tue, 4 Feb 2020 11:24:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: quic-chairs@ietf.org, quic@ietf.org Subject: Alissa Cooper's Yes on charter-ietf-quic-01-02: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158084425568.15760.14010903358228220915.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 11:24:15 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 19:24:16 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-quic-01-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-quic/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The milestone dates need updating. From nobody Tue Feb 4 13:05:18 2020 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 8189C120170 for ; Tue, 4 Feb 2020 13:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 WQoqTNOOfX_y for ; Tue, 4 Feb 2020 13:05:16 -0800 (PST) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 17F5F12020A for ; Tue, 4 Feb 2020 13:05:16 -0800 (PST) Received: by mail-wr1-f46.google.com with SMTP id t2so24948221wrr.1 for ; Tue, 04 Feb 2020 13:05:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+gIQZSukE2mRZHrEE2i5nAKNztVTdzArwBY1lFBFA1c=; b=i+5PE8+2o6bnRT7QZ6TE1385Ohbi4NRgB+kfwtR6h9ZHI0pOB7fa3zEyH/X3n4mIJ4 a8Zb8A+xGWi3aDWnlbWCHP5umSMW/Uf0H5UkGCD9pvebnwLNdzKh6XEqP9io7skJGceX qg0PXcP7PA+WxvchandoOB3I9Pfh+/OYbCkafOXpPs9BQJVVE5O2F98zj1Dgu50FEd1n MJ296qQqBRpEIBDJgXRgFIqNKifOS9FRMhkFhyhJ+YgOhT6AiBAZulMTbZNVWSwUWZf6 7/2p37YgUxyBoepNeA7bjtAeeuBbSmwMinWIa7rJ/iOglYGW9snwehID1mC0vL3qzaB6 RmGw== X-Gm-Message-State: APjAAAW++MMwJ4okt1vE18zgNoN3Cd/i/EQCrQjqaI82XqJMMaRtC4AA /ObZoGNltoLXVznJ8Xzhi3U8tO5/dvkYhM862bCoMqLImHs= X-Google-Smtp-Source: APXvYqyNi7JIo2JV++mL/CDL7Qr8UGSAJYtT/ix7mbc5I12KusCVgQL/brIGpR4rQN9okiIhAlihYnhMjuqaFI84YgM= X-Received: by 2002:adf:e686:: with SMTP id r6mr24123553wrm.177.1580850314535; Tue, 04 Feb 2020 13:05:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Nygren Date: Tue, 4 Feb 2020 16:05:03 -0500 Message-ID: Subject: QUIC re-chartering: include DNS-over-QUIC? To: Mark Nottingham Cc: IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="00000000000070e70b059dc665b1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 21:05:17 -0000 --00000000000070e70b059dc665b1 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 11, 2019 at 4:38 PM Mark Nottingham wrote: > We've just put out Calls for Adoption for extensions to QUICv1, as we > believe that the group has some capacity to discuss them as it finishes > work on the core protocol. > Is there interest and bandwidth in picking up work on DNS-over-QUIC (eg, draft-huitema-quic-dnsoquic-07 ) as well, presumably in coordination with the DNS community? Getting a second protocol using QUIC might help make sure we work through issues that may arise early, plus DNS-over-QUIC seems quite attractive as a technology for resolver-to-authoritative communication if/when we go that way. ie, it seems strictly better than defining a DNS-over-DTLS and also seems to have plenty of advantages over DoT. The current charter also says: This [HTTP] mapping will accommodate the extension mechanisms defined in > the HTTP/2 > specification. Upon completion of that mapping, additional protocols > may be added by updating this charter to include them. > Best, Erik --00000000000070e70b059dc665b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 11, 2019 at 4:38 PM Mark Nottingham <mnot@mnot.net> wrote:
We've just put out Calls for Adoption for= extensions to QUICv1, as we believe that the group has some capacity to di= scuss them as it finishes work on the core protocol.
<= br>
Is there interest and bandwidth in picking up work on DNS-over-QUIC (eg,= dra= ft-huitema-quic-dnsoquic-07) as well, presumably in coordination with t= he DNS community?=C2=A0

Getting a second protocol using QUIC might = help make sure we work through issues that may arise early, plus DNS-over-Q= UIC seems quite attractive as a technology for resolver-to-authoritative co= mmunication if/when we go that way.=C2=A0 ie, it seems strictly better than= defining a DNS-over-DTLS and also seems to have plenty of advantages over = DoT.

The current charter also says:

This [HTTP] mapping will accommodate the extension me= chanisms defined in the HTTP/2
specification. Upon completion of that ma= pping, additional protocols
may be added by updating this charter to in= clude them.

Best,
=C2=A0=C2=A0=C2=A0=C2=A0 Erik

--00000000000070e70b059dc665b1-- From nobody Tue Feb 4 16:17:14 2020 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 2C15012018D for ; Tue, 4 Feb 2020 16:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 WzF-j52bRNww for ; Tue, 4 Feb 2020 16:17:11 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 C63E2120152 for ; Tue, 4 Feb 2020 16:17:09 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 0150C7gF012107; Tue, 4 Feb 2020 16:17:05 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=ene2c6Ya8alzVG04kCAN3FCXnizPvk3Zyo23peSLQLM=; b=XbzPiLMYsgS/WBc+hbdxl62iEHxlHiTnZwG6Ld+2KKO8wEXIcLACXlulQu9Mca3/IFX6 Foa6/MqQuIPp/wHkJmJpP3lrg9WhCoDT4GMWxgxSxGK6gQ6ZpxviVjUBA9/3bRSX11m0 PdEAG7MDtuoz068AgkTF+PS14XmWIyGgiuX6sJhXGE9aOH18PUSBV+kvuNUqE+fFWbQY h+3lKNg1lHMx8rWROhKN2qd84zDpsP9vPVK41Kk4lXqfJWYCI3HhjsOT3TFwhGU7JK7u M3Rz+DMvMvRDFupaX8ZMBvcNAbdO1OQOYvjeoRDizl+wx3WslmeAWQL5I7FIo6eLlklF dg== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2xyhk1hafy-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 04 Feb 2020 16:17:05 -0800 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q5700Q8ACSGZ450@rn-mailsvcp-mta-lapp02.rno.apple.com>; Tue, 04 Feb 2020 16:17:04 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q5700G00C9G5H00@nwk-mmpp-sz13.apple.com>; Tue, 04 Feb 2020 16:17:04 -0800 (PST) X-Va-A: X-Va-T-CD: 3c405e4a76e9c4b391e73361135699a4 X-Va-E-CD: 6ca81ff41316a3e61e2ef30272efd66a X-Va-R-CD: 300a1c5f914f022e7d32c9a02a47ecc6 X-Va-CD: 0 X-Va-ID: 6139513b-e985-444f-aa5d-a4cf5b12ad8e X-V-A: X-V-T-CD: 3c405e4a76e9c4b391e73361135699a4 X-V-E-CD: 6ca81ff41316a3e61e2ef30272efd66a X-V-R-CD: 300a1c5f914f022e7d32c9a02a47ecc6 X-V-CD: 0 X-V-ID: 947f4da0-07ea-400b-9516-09f28f9968fe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-02-04_09:,, signatures=0 Received: from [17.234.11.169] (unknown [17.234.11.169]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q57006EHCSFU220@nwk-mmpp-sz13.apple.com>; Tue, 04 Feb 2020 16:17:03 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_D94D1B47-BB8E-4FCC-9E02-4E16D2B9471A" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Subject: Re: QUIC re-chartering: include DNS-over-QUIC? Date: Tue, 04 Feb 2020 16:17:03 -0800 In-reply-to: Cc: Mark Nottingham , Lars Eggert , IETF QUIC WG To: Erik Nygren References: X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-04_09:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 00:17:13 -0000 --Apple-Mail=_D94D1B47-BB8E-4FCC-9E02-4E16D2B9471A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My main question in doing DNS-over-QUIC is what benefit it provides over = DNS-over-HTTP/3 (DoH3?). DoH3 seems like a more practical deployment = model, since it allows relatively seamless upgrade from DoH2 to DoH3, = and allows a resolver to support consistent semantics on both. The = overhead of the HTTP layer is pretty minimal, and while I appreciate the = desire to define a non-HTTP protocol over QUIC, I imagine there would be = ones that would be more useful to adopt in the near term. Best, Tommy > On Feb 4, 2020, at 1:05 PM, Erik Nygren wrote: >=20 > On Wed, Dec 11, 2019 at 4:38 PM Mark Nottingham > wrote: > We've just put out Calls for Adoption for extensions to QUICv1, as we = believe that the group has some capacity to discuss them as it finishes = work on the core protocol. >=20 > Is there interest and bandwidth in picking up work on DNS-over-QUIC = (eg, draft-huitema-quic-dnsoquic-07 = ) as well, = presumably in coordination with the DNS community? =20 >=20 > Getting a second protocol using QUIC might help make sure we work = through issues that may arise early, plus DNS-over-QUIC seems quite = attractive as a technology for resolver-to-authoritative communication = if/when we go that way. ie, it seems strictly better than defining a = DNS-over-DTLS and also seems to have plenty of advantages over DoT.=20 >=20 > The current charter also says: >=20 > This [HTTP] mapping will accommodate the extension mechanisms defined = in the HTTP/2 > specification. Upon completion of that mapping, additional protocols=20= > may be added by updating this charter to include them. >=20 > Best, > Erik >=20 --Apple-Mail=_D94D1B47-BB8E-4FCC-9E02-4E16D2B9471A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii My = main question in doing DNS-over-QUIC is what benefit it provides over = DNS-over-HTTP/3 (DoH3?). DoH3 seems like a more practical deployment = model, since it allows relatively seamless upgrade from DoH2 to DoH3, = and allows a resolver to support consistent semantics on both. The = overhead of the HTTP layer is pretty minimal, and while I appreciate the = desire to define a non-HTTP protocol over QUIC, I imagine there would be = ones that would be more useful to adopt in the near term.

Best,
Tommy

On Feb 4, 2020, at 1:05 PM, = Erik Nygren <erik+ietf@nygren.org> wrote:

On Wed, Dec 11, 2019 at 4:38 PM Mark Nottingham = <mnot@mnot.net> = wrote:
We've just put out Calls for Adoption = for extensions to QUICv1, as we believe that the group has some capacity = to discuss them as it finishes work on the core protocol.

Is there = interest and bandwidth in picking up work on DNS-over-QUIC (eg, draft-huitema-quic-dnsoquic-07) as well, presumably in = coordination with the DNS community? 

Getting a second protocol using QUIC might help = make sure we work through issues that may arise early, plus = DNS-over-QUIC seems quite attractive as a technology for = resolver-to-authoritative communication if/when we go that way.  = ie, it seems strictly better than defining a DNS-over-DTLS and also = seems to have plenty of advantages over DoT.

The current charter also says:

This = [HTTP] mapping will accommodate the extension mechanisms defined in the = HTTP/2
specification. Upon completion of that mapping, = additional protocols
may be added by updating this = charter to include them.

Best,
     Erik


= --Apple-Mail=_D94D1B47-BB8E-4FCC-9E02-4E16D2B9471A-- From nobody Tue Feb 4 16:40:46 2020 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 BF125120072; Tue, 4 Feb 2020 16:40:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach via Datatracker To: "The IESG" Cc: quic-chairs@ietf.org, quic@ietf.org Subject: Adam Roach's No Objection on charter-ietf-quic-01-02: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <158086324474.15815.7109476137624402668.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 16:40:44 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 00:40:45 -0000 Adam Roach has entered the following ballot position for charter-ietf-quic-01-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-quic/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I note that the paragraph that previously ruled partial reliability and FEC out of scope has been removed. Are these mechanisms to be considered in-scope in this new version of the charter? I would suggest that it should say so explicitly, if such is the intention. From nobody Tue Feb 4 17:50:03 2020 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 850E012006E for ; Tue, 4 Feb 2020 17:50:02 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 JmzTri7oGv0z for ; Tue, 4 Feb 2020 17:50:01 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 A7FB6120058 for ; Tue, 4 Feb 2020 17:50:01 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 0151jjZN006302; Wed, 5 Feb 2020 01:49:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=8opgXfq4XPDGMRWiq/Ahy64ZrRImeXDq47mrV4+m5Z8=; b=mmMN05teoAcF3oQkUYN/Kr7GayhndAvYxs+Idx6d9107F8klM4xJJ7iA9uq0CYo97c9N FwOkGBWa3AqPwcsyEUt+oTpxdzEOl8AqAgN2c3rm1spqCaD9RMvQ7NTOjW2OBBRGQH3+ 0BO3WhC1Db+NEJLT+C1e/cq6hY6/Ive20xoKwG/lkYmXpRB6Nqcd+cmFnPJ8ut7s0eoH kLqh5sZektDdxIkroVCQEhxkIV8s+if0k/k6o2mahxS4/SWEE6DpTG0M8wdKfe6c36kB /Wukw5TGjHGkbCniZr7VY4DJCgoHMYnrNMjEwBE/GfxkPD0Q16Id+GXvUxniVCMJ29lZ 2Q== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2xyhn5gpy6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Feb 2020 01:49:56 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 0151m3Y2019931; Tue, 4 Feb 2020 17:49:55 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint5.akamai.com with ESMTP id 2xykfu813p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 04 Feb 2020 17:49:55 -0800 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 20:49:54 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 4 Feb 2020 20:49:54 -0500 From: "Salz, Rich" To: Tommy Pauly , Erik Nygren CC: Lars Eggert , Mark Nottingham , "IETF QUIC WG" Subject: Re: QUIC re-chartering: include DNS-over-QUIC? Thread-Topic: QUIC re-chartering: include DNS-over-QUIC? Thread-Index: AQHV258Zea7jxOk5qUmVuA7FYYAzPqgMD8GA///GH4A= Date: Wed, 5 Feb 2020 01:49:54 +0000 Message-ID: <3E036FFD-7A61-4B5B-8750-4EDF9025B4CE@akamai.com> References: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> In-Reply-To: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200203 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.114.49] Content-Type: multipart/alternative; boundary="_000_3E036FFD7A614B5B87504EDF9025B4CEakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002050012 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-04_09:2020-02-04, 2020-02-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 malwarescore=0 clxscore=1011 mlxscore=0 lowpriorityscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002050011 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 01:50:02 -0000 --_000_3E036FFD7A614B5B87504EDF9025B4CEakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpayB3YXMgc3VnZ2VzdGluZw0KDQogICogICBwbHVzIEROUy1vdmVyLVFVSUMgc2VlbXMgcXVp dGUgYXR0cmFjdGl2ZSBhcyBhIHRlY2hub2xvZ3kgZm9yIHJlc29sdmVyLXRvLWF1dGhvcml0YXRp dmUgY29tbXVuaWNhdGlvbiBpZi93aGVuIHdlIGdvIHRoYXQgd2F5Lg0KDQpJ4oCZZCByYXRoZXIg bm90IHNlZSBIVFRQIGVtYmVkZGVkIGluIHJlc29sdmVycyBleGNlcHQgdG8gaGFuZGxlIGNsaWVu dHMuICBUaGVyZeKAmXMgbm8gcmVhc29uIGZvciB0aGUgcm9vdCBzZXJ2ZXJzLCBlLmcuLCB0byBo YXZlIGFuIEhUVFAgc3RhY2suICBTbWFsbGVyIGF0dGFjayBzdXJmYWNlLg0KDQpETlMgc2VlbXMg bGlrZSBhIGdvb2QgZml0IGZvciBRVUlDOyBpdOKAmXMgcmVxdWVzdC9yZXNwb25zZSwgYW5kIGl0 4oCZZCBiZSBncmVhdCB0byBub3QgaGF2ZSB0byBjYXJlIGFib3V0IFVEUCB2cyBUQ1AuDQoNCg0K --_000_3E036FFD7A614B5B87504EDF9025B4CEakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjA2 NjM3MzAzMTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTEzODA1Mzc2MzggNDg2NjA5MzggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVyaWsgd2FzIHN1Z2dlc3RpbmcgPG86cD48L286cD48L3A+ DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+cGx1cyBETlMtb3Zlci1RVUlDIHNlZW1zIHF1aXRlIGF0dHJhY3RpdmUgYXMgYSB0ZWNo bm9sb2d5IGZvciByZXNvbHZlci10by1hdXRob3JpdGF0aXZlIGNvbW11bmljYXRpb24gaWYvd2hl biB3ZSBnbyB0aGF0IHdheS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmWQgcmF0 aGVyIG5vdCBzZWUgSFRUUCBlbWJlZGRlZCBpbiByZXNvbHZlcnMgZXhjZXB0IHRvIGhhbmRsZSBj bGllbnRzLiZuYnNwOyBUaGVyZeKAmXMgbm8gcmVhc29uIGZvciB0aGUgcm9vdCBzZXJ2ZXJzLCBl LmcuLCB0byBoYXZlIGFuIEhUVFAgc3RhY2suJm5ic3A7IFNtYWxsZXIgYXR0YWNrIHN1cmZhY2Uu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkROUyBzZWVtcyBsaWtlIGEgZ29vZCBmaXQgZm9yIFFV SUM7IGl04oCZcyByZXF1ZXN0L3Jlc3BvbnNlLCBhbmQgaXTigJlkIGJlIGdyZWF0IHRvIG5vdCBo YXZlIHRvIGNhcmUgYWJvdXQgVURQIHZzIFRDUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_3E036FFD7A614B5B87504EDF9025B4CEakamaicom_-- From nobody Tue Feb 4 19:13:07 2020 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 52F9012018D; Tue, 4 Feb 2020 19:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 Ga4wOCZcet-Y; Tue, 4 Feb 2020 19:13:04 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 B82F112001A; Tue, 4 Feb 2020 19:13:03 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id r14so375057lfm.5; Tue, 04 Feb 2020 19:13:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+xaj/P/JfF1FA7ZsPatDzH2OITWaftoJGzimqdxd5KU=; b=KCErrm6KJzAhLmVvUfLBLPIDwoK6sAdby4oplVMYx2YAJotpBCm0eXqm+8RWA3voWw /yn+wRjtAMlbJjHeTxbZa4WiSQGNi1NMvIG/09xY0dNt4tApB8m48831HidW4Q9H2oDw wQ+9cWqpTrqTPvg6wugq3rewpSoBAJ7lU5wagMssNoi7i+6K028hXRen56aWho3QczeK 3NCIAlLD5xrnHlxZ5b/1jrfPaLQh08kFIbDSO/yNke7L5Z0I311ubTgJzxenPpTZJOgp 4EC9SE6oXwDm58UtBAQULw6Amt9+1JR/Bho7NpMtbDEwNNKu5C/nm7cAa+V+4wBstD/v ejkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+xaj/P/JfF1FA7ZsPatDzH2OITWaftoJGzimqdxd5KU=; b=pJzCnR77uypkjnF2kypPG8KRd5EJ3kEMzCL9lP98EXrnetVVPVhT7pO3hhWDUK9+Q2 ug+z+csf+pXNB7o9kkAlhfxdI/pKDSUhxxmEF59wE79pKrXXDPPCRrJeDw/7GE7uQxHp K7ZgI8Muy7gdZMIO7Fjw2cXJVcLi9KvKhnoWE9Wq4zQQg1Q/QqE9VcSw5CQOH1DRGaeQ sP/GOdu6n7YU8HKBkJQg0dsST+rib/8I+Lf1Qz2WWOd/xpfuLel33i0APr1ySYS1N/aX gPwO8kNHDeaUbEnYY/oZ7Z6fF/Bhcg1RpCPiSNLSkyrStHgoERvJjuVudj+EXdsbUJ6D 7tjA== X-Gm-Message-State: APjAAAUkwaEE4kroe4dl6PhbINYhztWZkTHrBfcrN2GdEhH6NKhKDZ4r +onCPcro7QeQ9ESsauvO2FtDpcESSCBjhydJef71CYm/ X-Google-Smtp-Source: APXvYqwPBem8yBg3XVneYxKHs8tj0pJNnRFqXjp3Nd+Yiw6ls59VlGTEYQ0E6who3d7c+VC3xgBx8DN7/Hc86K1NKSI= X-Received: by 2002:a19:c82:: with SMTP id 124mr16441193lfm.152.1580872382048; Tue, 04 Feb 2020 19:13:02 -0800 (PST) MIME-Version: 1.0 References: <158086324474.15815.7109476137624402668.idtracker@ietfa.amsl.com> In-Reply-To: <158086324474.15815.7109476137624402668.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Tue, 4 Feb 2020 21:12:35 -0600 Message-ID: Subject: Re: Adam Roach's No Objection on charter-ietf-quic-01-02: (with COMMENT) To: Adam Roach Cc: The IESG , IETF QUIC WG , quic-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000c46ce6059dcb8814" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 03:13:06 -0000 --000000000000c46ce6059dcb8814 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 4, 2020 at 6:40 PM Adam Roach via Datatracker wrote: > Adam Roach has entered the following ballot position for > charter-ietf-quic-01-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-quic/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I note that the paragraph that previously ruled partial reliability and > FEC out > of scope has been removed. Are these mechanisms to be considered in-scope > in > this new version of the charter? I would suggest that it should say so > explicitly, if such is the intention. > I agree with Adam, of course, about making that explicit (one way or the other). Just speaking for myself, of course, but as I read the proposed charter, datagrams are in scope, and it seems =E2=80=A6 odd =E2=80=A6 to not have at= least partial reliability in scope as well. I'll let people who are more familiar with the current state of play on QUIC using FEC opine about that one. Best, Spencer Spencer --000000000000c46ce6059dcb8814 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 6:40 PM Adam R= oach via Datatracker <noreply@ietf.o= rg> wrote:
Adam Roach has entered the foll= owing ballot position for
charter-ietf-quic-01-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-qui= c/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I note that the paragraph that previously ruled partial reliability and FEC= out
of scope has been removed. Are these mechanisms to be considered in-scope i= n
this new version of the charter? I would suggest that it should say so
explicitly, if such is the intention.

= =C2=A0I agree with Adam, of course, about making that explicit (one way or = the other).

Just speaking for myself, of course, b= ut as I read the proposed charter, datagrams are in scope, and it seems =E2= =80=A6 odd =E2=80=A6 to not have at least partial reliability in scope as w= ell.

I'll let people who are more familiar wit= h the current state of play on QUIC using FEC opine about that one.

Best,

Spencer

Spencer
--000000000000c46ce6059dcb8814-- From nobody Tue Feb 4 21:53:34 2020 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 9C7C91201DC for ; Tue, 4 Feb 2020 21:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 SUzlDe6l_A1U for ; Tue, 4 Feb 2020 21:53:29 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::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 45EF8120045 for ; Tue, 4 Feb 2020 21:53:29 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id h23so1008903ljc.8 for ; Tue, 04 Feb 2020 21:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zO8atxyKS8XfBFvJ/ONwWAebctwfn3GJ2Ke5IVlNwAc=; b=NmwUsRjhH6Q9l+7jhs2IeFEgJhvgcqBnTJIUYYhlJsMvFIG68jmUG2Ti/Ll8ZuyD+e AFzhSIZjsLVDGuUBuqJOWmXMair6ZZDf+RIfGQ1QGcfjkntPnEh+o5SsEb8AznN25VNO wT20i4MmEehJD3ChOa8ywZwT60UoIR8vAwHuj9H6XNWBpHcXAo2CC3TkR4dVXJsj6uda sCeqbX+jhmGvq9Qpr4OHieW6702ktCHlV0QgJCElBKZs6XFL3sJaFNnEbAeFjyvhYM16 h1f/tTCE3m6lpd6JOycxdfqapM35ihavLl9VW/wJwe85RhUrIddCwG0WYoH6KrvChQ7i 4YHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zO8atxyKS8XfBFvJ/ONwWAebctwfn3GJ2Ke5IVlNwAc=; b=H+eV/h+EaXSkGL+oNDJyjezcWsak/OzrmCpxgIRGmaBYbB0yQy3Sg9z66iE7xKj10y n6n4Ru2t/xNObm9OpEne/TYX7lBqj2BnUBl36+ZpvuWhX+OGR7t+ltTfp+QoRC7+8Mxn U2qZwLoHyop69+8wh2TBGO/c1XyE5NI9O154VRp2bWMq/96/dkWK+mc/ZdiTMCUeREd/ N6kt0Wn+MpI102VZKFD+acW7jgeRFxyigi+9nknYCxdJ2M2UwFEooeNIRGhCsajn6pjq cBuP0vOGIPaTl5UfpqBKUOjk600CI8Nm13PhPdoiNONRKpL7b8jYGKVw17JiG1FiBnG0 wXBQ== X-Gm-Message-State: APjAAAUY6xiRAI35GcULUp5raZIRQaRhePvQYNfwND3NokLktjtqAPfa B4e+BC1hvW9hVlqxIK6kkwJdkFonrsHG7VdFFluI1w== X-Google-Smtp-Source: APXvYqy3N4x8JEt2NRlunFlQ1av+VFIE9ccRCIR9dbD8ggxr4JqrUMobOY00luoa5P70zkbOj3/bGnO1kV+zS18BRM8= X-Received: by 2002:a05:651c:448:: with SMTP id g8mr19710982ljg.35.1580882007486; Tue, 04 Feb 2020 21:53:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 4 Feb 2020 21:52:51 -0800 Message-ID: Subject: Re: QUIC re-chartering: include DNS-over-QUIC? To: Erik Nygren Cc: Mark Nottingham , Lars Eggert , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000007d03d0059dcdc656" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 05:53:33 -0000 --0000000000007d03d0059dcdc656 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 1:05 PM Erik Nygren wrote: > On Wed, Dec 11, 2019 at 4:38 PM Mark Nottingham wrote: > >> We've just put out Calls for Adoption for extensions to QUICv1, as we >> believe that the group has some capacity to discuss them as it finishes >> work on the core protocol. >> > > Is there interest and bandwidth in picking up work on DNS-over-QUIC (eg, > draft-huitema-quic-dnsoquic-07 > ) as well, > presumably in coordination with the DNS community? > I think it would be OK to define DoQ (though I share Tommy's question about DoH/3, which needs no additional standardization) but I don't think that should be done in the QUIC WG, any more than we define HTTP in TCPM. We needed one driving study but now that the QUIC mapping is done, other mappings should probably be done elsewhere. > > Getting a second protocol using QUIC might help make sure we work through > issues that may arise early, plus DNS-over-QUIC seems quite attractive as a > technology for resolver-to-authoritative communication if/when we go that > way. ie, it seems strictly better than defining a DNS-over-DTLS > You might be interested in https://tools.ietf.org/html/rfc8094 -Ekr > and also seems to have plenty of advantages over DoT. > > The current charter also says: > > This [HTTP] mapping will accommodate the extension mechanisms defined in >> the HTTP/2 >> specification. Upon completion of that mapping, additional protocols >> may be added by updating this charter to include them. >> > > Best, > Erik > > --0000000000007d03d0059dcdc656 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Feb 4, 2020 at 1:05 PM Erik Nygren <erik+ietf@nygren.org> wro= te:
On We= d, Dec 11, 2019 at 4:38 PM Mark Nottingham <mnot@mnot.net> wrote:
We've just put out Calls for Adopti= on for extensions to QUICv1, as we believe that the group has some capacity= to discuss them as it finishes work on the core protocol.
=

Is there intere= st and bandwidth in picking up work on DNS-over-QUIC (eg, dra= ft-huitema-quic-dnsoquic-07) as well, presumably in coordination with t= he DNS community?=C2=A0

<= div>I think it would be OK to define DoQ (though I share Tommy's questi= on about DoH/3, which needs no additional standardization) but I don't = think that should be done in the QUIC WG, any more than we define HTTP in T= CPM. We needed one driving study but now that the QUIC mapping is done, oth= er mappings should probably be done elsewhere.

Getting a second protocol using QUIC might help make sure we work throug= h issues that may arise early, plus DNS-over-QUIC seems quite attractive as= a technology for resolver-to-authoritative communication if/when we go tha= t way.=C2=A0 ie, it seems strictly better than defining a DNS-over-DTLS

You might be interested in <= a href=3D"https://tools.ietf.org/html/rfc8094" target=3D"_blank">https://to= ols.ietf.org/html/rfc8094

-Ekr

<= /div>
=C2=A0
and also seems to have plenty of advantages over DoT.

The current charter also says:

This [HTTP] m= apping will accommodate the extension mechanisms defined in the HTTP/2
s= pecification. Upon completion of that mapping, additional protocols
may= be added by updating this charter to include them.

Best,
=C2=A0=C2=A0=C2=A0=C2=A0 Erik

--0000000000007d03d0059dcdc656-- From nobody Wed Feb 5 00:55:57 2020 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 ED95912029C for ; Wed, 5 Feb 2020 00:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 fVFabnvRQYfL for ; Wed, 5 Feb 2020 00:55:52 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 D249B120271 for ; Wed, 5 Feb 2020 00:55:52 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id j20so1240176otq.3 for ; Wed, 05 Feb 2020 00:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PTPJE6w9PIlLME7oEwrifC4Rq/BU+MdlRet/QusavAY=; b=M8Km2Ti3MLm4WdJKREpM/fRCDhaPg4FMJTHDlNsRaI0TllVWattiUFw2nMb70Bz/KP IH5unY664l0dvoaaOhn4lYkI6l1KPUBprckpCZipKUshr1sFQAXuR2ZyUT647g8qZkxj g3PmaqeXIF8ISvzDz6QYm6EoilG7Qp2MJYkOhDphFc+WKzVPoQ0o5jwAEaRiPX2MAkpN e6KuTBHe/MLXqEwdZfRKJyxvyOZuXN70cxK5DXU3NIO6zrdbCv+ot5/EDOl+j4kfMbn9 pCi67Ea/aidCR20HlIxSh7ltw6EG6ojGziPhvioyDzDir5YbGEKucuyr4x0F7wMv7F2B aO+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PTPJE6w9PIlLME7oEwrifC4Rq/BU+MdlRet/QusavAY=; b=Xz/kTzr9F2mX7GHvAzamGvn0rx0r5eQRuHpdI80h/gIEAZKMGMzRRyD4pXYDkDXegY oU9BsxAUM+8JE+AvV4/8fSAppAU6+qRQvWMo3qG5XF2WXbO3Fk8QlM+q09WJxF0YmBH8 Q0CoQ0yvYTjJK4JauFUV/Ye/tygMIQ39x5wBsBq4og7xD6saQJB9lHP0E3o70tt48VOb tSuiqxVqaKmlaa+W5cyRbW3pmXZbzt4eusci6LX+B9B/QHHzv+4SJZlrJ7ntDye+NPrB 9+UlmTFInRThxwmmBvhG7X2wOFtINldWz6VlcAd6w7gzlcPFGZsJ9cqkwRka3Ngriap8 wWMg== X-Gm-Message-State: APjAAAXOpMq+0WZ2ElnaK9vz9uBK5tug+F8DN25SpHqAp5t5riDXY9DL L8NDT+6Hoo4yRu+o+a7LPyobKc8QnkdGEY9jBXI= X-Google-Smtp-Source: APXvYqy7o912j3yhiaKz3Ful+NPqh6E3QFeah1svifn/CxPfA6URjc+RY1swtQPF88MI16TYLU6PuAuvvtVbK0KCN8M= X-Received: by 2002:a9d:6f0a:: with SMTP id n10mr26077574otq.54.1580892952147; Wed, 05 Feb 2020 00:55:52 -0800 (PST) MIME-Version: 1.0 References: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> In-Reply-To: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> From: Ted Hardie Date: Wed, 5 Feb 2020 09:55:26 +0100 Message-ID: Subject: Re: QUIC re-chartering: include DNS-over-QUIC? To: Tommy Pauly Cc: Erik Nygren , Lars Eggert , Mark Nottingham , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000d73b5a059dd052cc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 08:55:56 -0000 --000000000000d73b5a059dd052cc Content-Type: text/plain; charset="UTF-8" Hi Tommy, On Wed, Feb 5, 2020 at 1:17 AM Tommy Pauly wrote: > My main question in doing DNS-over-QUIC is what benefit it provides over > DNS-over-HTTP/3 (DoH3?). DoH3 seems like a more practical deployment model, > since it allows relatively seamless upgrade from DoH2 to DoH3,and allows a > resolver to support consistent semantics on both. > I think the deployment path here is really for folks who were on DoT (or considered DoT) but want to have the advantages of QUIC. As such, I support the DNS over QUIC work. I believe it is actually easier for folks who want consistent semantics from DNS over UDP-->DNS over (D)TLS-->DNS over QUIC, with none of the HTTP semantics entering the equation. regards, Ted Hardie > The overhead of the HTTP layer is pretty minimal, and while I appreciate > the desire to define a non-HTTP protocol over QUIC, I imagine there would > be ones that would be more useful to adopt in the near term. > > Best, > Tommy > > On Feb 4, 2020, at 1:05 PM, Erik Nygren wrote: > > On Wed, Dec 11, 2019 at 4:38 PM Mark Nottingham wrote: > >> We've just put out Calls for Adoption for extensions to QUICv1, as we >> believe that the group has some capacity to discuss them as it finishes >> work on the core protocol. >> > > Is there interest and bandwidth in picking up work on DNS-over-QUIC (eg, > draft-huitema-quic-dnsoquic-07 > ) as well, > presumably in coordination with the DNS community? > > Getting a second protocol using QUIC might help make sure we work through > issues that may arise early, plus DNS-over-QUIC seems quite attractive as a > technology for resolver-to-authoritative communication if/when we go that > way. ie, it seems strictly better than defining a DNS-over-DTLS and also > seems to have plenty of advantages over DoT. > > The current charter also says: > > This [HTTP] mapping will accommodate the extension mechanisms defined in >> the HTTP/2 >> specification. Upon completion of that mapping, additional protocols >> may be added by updating this charter to include them. >> > > Best, > Erik > > > --000000000000d73b5a059dd052cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tommy,

On Wed, Feb 5, 2020 at 1:17 AM Tommy Pau= ly <tpauly=3D40apple.com@d= marc.ietf.org> wrote:
My main question in = doing DNS-over-QUIC is what benefit it provides over DNS-over-HTTP/3 (DoH3?= ). DoH3 seems like a more practical deployment model, since it allows relat= ively seamless upgrade from DoH2 to DoH3,and allows a resolver to support c= onsistent semantics on both.

I think= the deployment path here is really for folks who were on DoT (or considere= d DoT) but want to have the advantages of QUIC.=C2=A0 As such, I support th= e DNS over QUIC work.=C2=A0 I believe it is actually easier for folks who w= ant consistent semantics from DNS over UDP-->DNS over (D)TLS-->DNS ov= er QUIC, with none of the HTTP semantics entering the equation.=C2=A0
<= /div>

regards,

Ted Hardie
=C2=A0
The overhead of the HTTP layer is pre= tty minimal, and while I appreciate the desire to define a non-HTTP protoco= l over QUIC, I imagine there would be ones that would be more useful to ado= pt in the near term.

Best,
Tommy

<= blockquote type=3D"cite">
On Feb 4, 2020, at 1:05 PM, Erik Nygren <<= a href=3D"mailto:erik+ietf@nygren.org" target=3D"_blank">erik+ietf@nygren.o= rg> wrote:

On Wed, Dec 11, 2019 at 4:38 PM Mark= Nottingham <mnot@mno= t.net> wrote:
We've just put out Calls for Adoption for extensions to QUICv1, as= we believe that the group has some capacity to discuss them as it finishes= work on the core protocol.

Is there interest and bandwidth in picking up = work on DNS-over-QUIC (eg, draft-huitema-quic-dnsoquic-07= ) as well, presumably in coordination with the DNS community?=C2=A0

Getting a second protocol using QUIC might help= make sure we work through issues that may arise early, plus DNS-over-QUIC = seems quite attractive as a technology for resolver-to-authoritative commun= ication if/when we go that way.=C2=A0 ie, it seems strictly better than def= ining a DNS-over-DTLS and also seems to have plenty of advantages over DoT.=

The current charter also says:

Thi= s [HTTP] mapping will accommodate the extension mechanisms defined in the H= TTP/2
specification. Upon completion of that mapping, additional protoco= ls
may be added by updating this charter to include them.

Best,
=C2=A0=C2=A0=C2=A0=C2=A0 Erik


--000000000000d73b5a059dd052cc-- From nobody Wed Feb 5 01:33:34 2020 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 5513D120639 for ; Wed, 5 Feb 2020 01:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 iRRs6r2UY06X for ; Wed, 5 Feb 2020 01:33:30 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8168C12026E for ; Wed, 5 Feb 2020 01:33:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4D8F166017A; Wed, 5 Feb 2020 11:33:28 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4KlFBMoXxE2; Wed, 5 Feb 2020 11:33:26 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 70738660150; Wed, 5 Feb 2020 11:33:26 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: QUIC re-chartering: include DNS-over-QUIC? From: Jari Arkko In-Reply-To: Date: Wed, 5 Feb 2020 10:33:24 +0100 Cc: Tommy Pauly , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <8FD478B2-4FB5-451F-9402-A278186C4E63@piuha.net> References: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> To: Ted Hardie X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 09:33:32 -0000 I share Tommy=E2=80=99s and Ekr=E2=80=99s questions and thoughts on = this. I think you are right Ted that DoQ is probably more = straightforward and has less components. However, I also feel that the = number of DNS query transport solutions is growing :-) and that it might = be worthwhile for us to think about which of these have sufficient = market demand. I thought DoH (and DoH3 as a natural version of that) had = a standing, which other ones do? Jari From nobody Wed Feb 5 02:00:02 2020 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 2C405120019 for ; Wed, 5 Feb 2020 02:00:00 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ulr19ty4E6YY for ; Wed, 5 Feb 2020 01:59:57 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2047.outbound.protection.outlook.com [40.107.20.47]) (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 2C78712012D for ; Wed, 5 Feb 2020 01:59:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RTUsbqriIG0O995A58wf7zFC4om/IHmlGKsWGuUTkRQnm3HXY1wcPOh/lhyQ6cx9t5joGrIA+hlHFuLSxPfJiT7oGx9PvusUa3o7SnmdUSJXfzBh84njb0Ceqg2tjKydJZc2LRWgaMDB6LCgoO7Ji2I5SEgsU1wc1maQOBr/2Xro+8FOuhnOiKn0ai+1LL3pBkSRF+Ln0MzMHZl7UrNPO3f4M3PGLhJ9K1fhG/Oy6X7NKVolrcEmFcYRUzrbaqHGuWaf9OhEjO6PMuEc+hG2GH8vpIQSVg3HdFz+CP4eewrWXYyzQP3CvO5V1YZGPJuTugeZeb604Yzqm5jbTz721Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0pn8VuSvUqXT6S8vrtfF0cOkz/wPCJJ2ibMFwOgPj0s=; b=dzfjo83k45b/1WraJFKkXlQitYePJvL44cJKiBtxLFjBBb2uc+qCPX9/kAzRSGk7/f1dqrYzP3qmAdY7z1W/LWiaLRtPtvxlep4DdtCHvXVoG20/SZsKpcWjhE4TOYt6yuT4SRkrNUlC5yjjiU331fUibHZ7jxo1AWmLAzViN7OpbVhCC9gLUF68XhxvxdK/Awg74W5VQaqxV/3H778peHYdY8et9dPXNIca/vDUqGJiNPFrZRhF4ccYWAIyuKQlK6LqhbffVHY7DYa7JmqAwzT3kq3VsfmLAQqGFM91E9fDIOizZTvu22EA7q/yXSv8884P+vzoPyUsogiifJOV1w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0pn8VuSvUqXT6S8vrtfF0cOkz/wPCJJ2ibMFwOgPj0s=; b=HiVQew1W3W8x1NgKypDtCdJ+o2mMIsDWxThzwIRmmhAH1PT0Dv64b7V2PfDDjQgE62ccA8UVbCth1+WnLQk7EMO4E7Lx12/LCYo0eiJsAZZHqjB5L+xE0Z/vvCtWa4YELb89uKWeOh6TsG4oZEKNnCaI2Xey64oaT4n8SQhgoL4= Received: from DB7PR07MB4572.eurprd07.prod.outlook.com (52.135.133.12) by DB7PR07MB6011.eurprd07.prod.outlook.com (20.178.108.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.10; Wed, 5 Feb 2020 09:59:54 +0000 Received: from DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544]) by DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544%5]) with mapi id 15.20.2707.016; Wed, 5 Feb 2020 09:59:54 +0000 From: Magnus Westerlund To: "mnot@mnot.net" , "erik+ietf@nygren.org" CC: "lars@eggert.org" , "quic@ietf.org" Subject: Re: QUIC re-chartering: include DNS-over-QUIC? Thread-Topic: QUIC re-chartering: include DNS-over-QUIC? Thread-Index: AQHV257YQhnQXGnxOUW8tUB4ePFBCagMXskA Date: Wed, 5 Feb 2020 09:59:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.130.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b5e6b94-3461-4ce4-c2de-08d7aa22266b x-ms-traffictypediagnostic: DB7PR07MB6011: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(136003)(366004)(376002)(199004)(189003)(53546011)(2906002)(36756003)(6506007)(71200400001)(86362001)(81166006)(81156014)(8676002)(8936002)(316002)(26005)(64756008)(110136005)(4326008)(44832011)(54906003)(186003)(6486002)(5660300002)(2616005)(66476007)(66946007)(6512007)(76116006)(66556008)(66446008)(478600001)(66616009)(91956017); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB6011; H:DB7PR07MB4572.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7efWBeGvBMPle/K6htrOjav4Ew2wlT8tKk0DLDqyc03dE94mtMzb1OiGVHz4L3Ef/ZktrG9RAVapwgT5ONof9xJLU3XJwTVkcsGCmr476IZif0ppAvhr7wwXe5KYEyXbCU7pahGOgyEYUwcwD+ZSXeQ7wsRp+1UpHY1VjYO4E8Th0mWUIn0xuueciyZ/YSi0tA5jffhh6qoXWw65WZ7TS22u8PWhrcUJ88cdQBMElXKndtSOv5mm95XJe8kGBFY0FqtfwCWSW+yJknaek1TW9CUtmFNi4dQdxOpf6IAQThdpa1IrZcfms9aln/Cg9Bx6CyUSRMocPMKhQTo8a7pK8eneYvPL//IBTx6b0aHlNi/nkHAm6qWg1mIBjlpd23hNsaf9w65PqQ2CUTO20BXfeYBsbLeogFUDUdT5FZxVMP4rp2+tMT2j+HD6S8eUWxiW x-ms-exchange-antispam-messagedata: 4EDLzR9Oixuk6a/KrhO+fdgko/Lt7tJiOEiMMxx8zmNEILN0xqdpzO5+e7RBJOe7/eR1xahlfEBnBDyy1VKQWSrR7QCBEe3BAbebdQ1dwB2/g3wRb3+px1bhrbfF03r4kQndIXt7ODSjIfEpj0gvjQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-wJfXFUFE/FHzsbzShbB+" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b5e6b94-3461-4ce4-c2de-08d7aa22266b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 09:59:54.4811 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: snIetAKcRWYkMfoVWOy0BqZlQIXQTnLGHyA8ZDhWoK4+O3P0O5mw7swXLRajcmjiXHCjm3+nzzab4D1X7zvGCvtEnNkJXNF179kx9ZZXNVA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6011 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 10:00:00 -0000 --=-wJfXFUFE/FHzsbzShbB+ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, This will not be included in this rechartering. This one is targeted to ena= ble three specific work items. A larger recharter is planned to happen when the= main set of the v1 spec is done.=20 Also, a DNS over QUIC specification could work that should happen in anothe= r WG. My current thought is that QUIC will focus evolving the protocol, doing extensions and updates. Thus additional protocol mappings should really onl= y be done if that mapping shows stress on QUIC which may require fixes or update= s to the protocol to resolve.=20 But, please figure out if this is a reasonable piece of work to do anywhere= in the IETF. However, the right place may be a more DNS focused WG.=20 Cheers Magnus Westerlund On Tue, 2020-02-04 at 16:05 -0500, Erik Nygren wrote: > On Wed, Dec 11, 2019 at 4:38 PM Mark Nottingham wrote: > > We've just put out Calls for Adoption for extensions to QUICv1, as we > > believe that the group has some capacity to discuss them as it finishes= work > > on the core protocol. >=20 > Is there interest and bandwidth in picking up work on DNS-over-QUIC (eg, > draft-huitema-quic-dnsoquic-07) as well, presumably in coordination with = the > DNS community? =20 >=20 > Getting a second protocol using QUIC might help make sure we work through > issues that may arise early, plus DNS-over-QUIC seems quite attractive as= a > technology for resolver-to-authoritative communication if/when we go that > way. ie, it seems strictly better than defining a DNS-over-DTLS and also > seems to have plenty of advantages over DoT.=20 >=20 > The current charter also says: >=20 > > This [HTTP] mapping will accommodate the extension mechanisms defined i= n the > > HTTP/2 > > specification. Upon completion of that mapping, additional protocols= =20 > > may be added by updating this charter to include them. > >=20 >=20 > Best, > Erik >=20 --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-wJfXFUFE/FHzsbzShbB+ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIwNTA5NTk1NFowLwYJKoZIhvcN AQkEMSIEIDeovaEOZQOaGNSVkVX6DF2NxOAfaj7DyXs59pxFZiqFMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAd6JrtXcoG5gM kMzAihX2rZcTkTieHq/3vL+T44TtsFNlgABmWRjnvXz+BiE7NvPmLM8cN+PlGt+W5MKBFJzanROe W45tH/g+IrTtnThJf71CTc5pLrNgGE4J3h0ZBWhfHArBMpD9dz3LixHBx1+ffV+KL5y/MDP5Qg7V QAhje4iLyTOVMdhSuRDevwg9nbMosPfX5vaF0Pz71xs8XPIS0ZdWztZh6Mcr5K7J03cMkfw8+4cx 2g8iK2zUz6zQmfsoYlu9S55Fb4XyiPR7H0Iuf4KNnVnGDOxgB/g0m+hXKRT7CTPxyAHdXDXS4OTe 0z046sdlDvmfPT4uUmdXMBdWoAAAAAAAAA== --=-wJfXFUFE/FHzsbzShbB+-- From nobody Wed Feb 5 02:03:54 2020 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 8D6B512012D; Wed, 5 Feb 2020 02:03:48 -0800 (PST) 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 (2048-bit key) header.d=mnot.net header.b=DJ43wt65; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aOfRGIhw 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 5Iro6RfGRULt; Wed, 5 Feb 2020 02:03:46 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37AC120129; Wed, 5 Feb 2020 02:03:46 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id A08F760E; Wed, 5 Feb 2020 05:03:44 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 05 Feb 2020 05:03:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=c pZHsmdFVYnzEd/3nA7XekjLpUC24GZGSU8Hzd9DifE=; b=DJ43wt65YQ3F/3w4g CCJwyj6/h3K+araEI7ZG5dG073cnXTJbxl7CgzZgd5cff/8hiKbSRh/QiygDGiN4 f0zD/EHq2NjVt1OqKAw1+tfzo6UT31xMDuwLpLYD2ysdeNPBuWSPJOEpQbQAX8jj +64eN5BdMbnpJbbVT+Uuf//s3o/9B0dakYEzNLCk2D5nCDlkFDmGIekvtSH2k1BD Id04IMBTolj2uXVsoGK+Rn+VgpKy3anJ1lnpq+QEKq9Lwt9i05t4L3lSCjdAnKjx 0s/1RA8hWdQx6uJ8kfcBlqw649vNUIBc//rc7/yeRAT7We/uaZD+IYHf3j9HnPFA pQmjw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=cpZHsmdFVYnzEd/3nA7XekjLpUC24GZGSU8Hzd9Di fE=; b=aOfRGIhwU/IigxvBUfsIIbs0yn4VP/kD8+Nxy9ERoBVWZDO/+WKlE4Kly fuQOaewBm/vFMiUxm+YyXv9uEA+qjO+hxm/qmaCil4mu5hyBiDRVjM111XUB+w8m b+DcRsQCqt6SLjmxiUhmZpczzhUa31+gyaGm5aiiaZ0kD6H075eUVk9NQPOhkr+v 2B/hjrQ9U819YbaAMYjjsWawPkZfxKSS5neY3OcDfW+ZZbpmt1OMBYzosiVmbOwB pE1NY66gfe441Ls3PLCrg0Nv8uLioIUR1CWK2II/qkgCZXziHC3EPJPopg7klIs2 PgkvbG7IOuSk5NRAWVAMSyGId9NYw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrhedugddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hmnhhothdrnhgvthenucfkphepuddtgedrudefvddrvddvkedruddtieenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrd hnvght X-ME-Proxy: Received: from [100.72.36.122] (unknown [104.132.228.106]) by mail.messagingengine.com (Postfix) with ESMTPA id C02FB3280060; Wed, 5 Feb 2020 05:03:42 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: Adam Roach's No Objection on charter-ietf-quic-01-02: (with COMMENT) From: Mark Nottingham In-Reply-To: <158086324474.15815.7109476137624402668.idtracker@ietfa.amsl.com> Date: Wed, 5 Feb 2020 11:03:41 +0100 Cc: The IESG , quic-chairs@ietf.org, quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <875780BE-E57C-48EC-AC8E-ED92352F65D2@mnot.net> References: <158086324474.15815.7109476137624402668.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 10:03:49 -0000 > On 5 Feb 2020, at 1:40 am, Adam Roach via Datatracker = wrote: >=20 > I note that the paragraph that previously ruled partial reliability = and FEC out > of scope has been removed. Are these mechanisms to be considered = in-scope in > this new version of the charter? I would suggest that it should say so > explicitly, if such is the intention. That was replace with text saying that _any_ new extension not listed = requires a recharter. -- Mark Nottingham https://www.mnot.net/ From nobody Wed Feb 5 02:07:55 2020 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 8279B12012D for ; Wed, 5 Feb 2020 02:07:53 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 5wKKpedLk-lo for ; Wed, 5 Feb 2020 02:07:50 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2049.outbound.protection.outlook.com [40.107.21.49]) (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 35AFF120019 for ; Wed, 5 Feb 2020 02:07:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FW3sSfNQGPiZ/aAa9QF9DmfmQR+HpoSypKQsKT2npvyycwb7TrBAQl/2W24wuv5+slytWhLzJ1L4xFpk9mIpwaxFF7rqRPOFyQ0wG3ODvtkKcD7DSz7yP5ibetzbeN/++xMA7N8zc3jPQvwkIp0smTE5b76Fjfz9VcFKkBnriDNfZtHb97uC8RZ5cO31A6gVr3/i4zLUC2VOzSh8BchnKF6IW5Zc+F8ebiTk/YTmjHmhHRwqKcCgFjktOp9qLD87untpipOSVZihMFjU7/oCYpqF0FnQz50rlsJCx8rw3ZyVFFTAvVYwz8xCbbieQcxtRYC1CDorIwuCLLsspGkEdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=phGP1mmIXLVm/GaOsCo8DByiALneLFn2hI8Yph2FAVw=; b=oLkanbrOGqArCswIxdn/wOO0+kcbQpD6Ke+HOfkm9x1wsiIQQnsl1S5KZ5q6rTu925BxsAucFU7CQiTJKriUxER6qy8ZT+2ZQtgfHdVMLVY1a2acvk7Y6U/b1skX50A5FQmGVR0P+D5iDNzbYAxkzHa3wNj5BQWRcckq8g1vJKMhz5z7nYqygJNWf0ijnTh3Zd7dClzbkp+IxQDI9TV3lUdybJChP3pm/gZKa/bRYzs3G76toBwORQ9QD1aZSl99o9srmWj45arWsbKgfZmROz/CKVjJlUZnuWyFgjvYn27Ry1qH6PxFAdD5+mVnFJ8pkvMNS3vFqIoq6WiAnoLD1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=phGP1mmIXLVm/GaOsCo8DByiALneLFn2hI8Yph2FAVw=; b=ZeOzXSzkWt/w1prBpjYgv4SFrrLhvUZry5615rs3BrP+4xitJJAR4wc6J5QatahH5J3eLxIafTP5L2wSslg8GZsfdta0wbT/sAjMO0cABDqLCTjHw7yiR/Qb3pOwp815be/2mVkUd1uOw/MNiNI/g3Yu8GrDAUngisBcH3LxBBs= Received: from DB7PR07MB4572.eurprd07.prod.outlook.com (52.135.133.12) by DB7PR07MB6011.eurprd07.prod.outlook.com (20.178.108.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.10; Wed, 5 Feb 2020 10:07:47 +0000 Received: from DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544]) by DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544%5]) with mapi id 15.20.2707.016; Wed, 5 Feb 2020 10:07:46 +0000 From: Magnus Westerlund To: "ryan@optimism.cc" , "jri.ietf@gmail.com" CC: "fenix@fb.com" , "ianswett@google.com" , "mbishop@evequefou.be" , "quic@ietf.org" , Mirja Kuehlewind Subject: Re: Proposed Charter Text Thread-Topic: Proposed Charter Text Thread-Index: AQHV1QxjvPDTcWegp0eJWJe1gsp2N6f6YuYAgAQt/wCAACJd4P//zegAgACGTeCAADI6gIACdxsAgAFB+ACAABI8AIAAyMIAgAEilQCAALFWgIABIJSAgAF4igCABDNWAA== Date: Wed, 5 Feb 2020 10:07:46 +0000 Message-ID: References: <3d2e70c1f581579a97124c31b096f0bda8b053b5.camel@ericsson.com> <269e8e73b792523247587725709c3e1fde7d0645.camel@ericsson.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.130.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0ea8fbe-b6dc-41ea-0165-08d7aa233fe9 x-ms-traffictypediagnostic: DB7PR07MB6011:|DB7PR07MB6011: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(136003)(346002)(396003)(366004)(189003)(199004)(6486002)(186003)(2616005)(5660300002)(64756008)(107886003)(316002)(26005)(110136005)(4326008)(44832011)(54906003)(3480700007)(76116006)(6512007)(66476007)(66946007)(91956017)(66556008)(66446008)(478600001)(66616009)(6506007)(2906002)(36756003)(53546011)(8676002)(7116003)(81166006)(81156014)(8936002)(71200400001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB6011; H:DB7PR07MB4572.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: z2ZJnrTEhZh5BR4HYKlWPsjJqntobp/NvgLfEszbe0x2WqG2DdHScCixuKxukP48lfvexlY/MlntOmZUByqlyd12ZEz3XWxXfnoSWCoI74nAbI6dzBL6LyZLwWFzQPilBL5v6Swr0TmUxKWvE9epDnfWVdzjEk+BKoiQ8wT7jJix4wDlJd/0gSScDhbFJjfs7uBLMKlTBMevsVcCKxMuEYVR9zO52FxIHxr4SP80e+uWNw3o3WfPaQv5lrXOQgLxc5G9dQSXEvcQRP0Fal8q3TE/i26MHtcpBmjXMv+71uJkLIjTpnASzgWlVZQKWpxyzxpLXvHKWbip/bnCnAJKkReEGF59vHxMeLZM0GI/sDHoeA4p5rC6kHtx3CqMaD3v+GDQKpyiAsudoCC9PBS9sP0vRTvkRCPHYT0QXSmi5Z7rmaJz49LqqfE/GcmxQUhq x-ms-exchange-antispam-messagedata: tb8FM9NebrrHSIAafYCz48b6FNRL019M1VG7dHjBbGdMhOLLu5o5RxQSIZG9lpFsQQu7FDzYT/8218ja68UaqyLn2a98FRGtvNftIHHue4uVscAmceYg0CqWdZZ6z83TS1ga5xqcgSfCEIOWWYpz1Q== Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-prQxRrXWikc7ujZyIRto" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0ea8fbe-b6dc-41ea-0165-08d7aa233fe9 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 10:07:46.7877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bnIEarEaaJD2ERHcA/C4yGxVdbsIz/H+nQ5tCPxs9U4kHf5/vEcGT6+U3rA6CcWNvkN9B/JwQlC/6HcjYalE0C42SabsJE16eHXM2ib0cb4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6011 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 10:07:54 -0000 --=-prQxRrXWikc7ujZyIRto Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I think the below proposals is the best one.=20 Additionally, the Working Group will provide guidance on how to handle QUIC traffic in load balancers. I will add this one to the charter that is provided to IESG for external re= view. Cheers Magnus On Sun, 2020-02-02 at 18:59 +0100, Jana Iyengar wrote: >=20 > On Sat, Feb 1, 2020 at 11:31 AM Ryan Hamilton wrote: > > On Fri, Jan 31, 2020 at 6:19 PM Jana Iyengar wrote= : > > > > Additionally, the Working Group will provide guidance on how to ena= ble > > > > load > > > > balancers to handle QUIC traffic. > > >=20 > > > SGTM. A minor rephrase: "Additionally, the Working Group will provide > > > guidance on how load balancers can be enabled to handle QUIC traffic.= " > > >=20 > >=20 > > That feels a bit clunky to me. What about: > >=20 > > > Additionally, the Working Group will provide guidance on how to handl= e > > > QUIC traffic in load balancers. > >=20 > > or: > >=20 > > > Additionally, the Working Group will provide guidance on how load > > > balancers should handle QUIC traffic. >=20 > That sounds fine to me too, module the recognition that IETF-weary eyes m= ight > read should as a recommendation rather than as solutions. But, this reads= fine > to me. > =20 --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-prQxRrXWikc7ujZyIRto Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIwNTEwMDc0NlowLwYJKoZIhvcN AQkEMSIEICYGcg0x3Z5Da2qQTLsWzJNKIi/JcB04oh0FePpvYluGMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAeiEB698z+io+ DpUyGsYM0R2D5u2iCR24Eqqms8cwHlBlV9vFN5lxiYksL+4at9LEpHR5enSdPZHhNOf37vth8afG FvnGlqoXx0MkYJAVKSyU6mjp7sdhEoqL8Mv+laajlynJmS+qtv22aJxN+n5xyptdRaOQwstAS9P3 2mR9X66iXZKV6DbX2zYduDQp5lPG85cq/of59vPB2Ek5HwGheexltWL1WPEWFHWhDeUJ9AZXHOvz PeGMTW6HN0VYzYAdKB5J8ie+ow6zSeCnaFVqsVbYh3x5iXh5+ZMdwHbGuI7Ch3cGwAiLRWYySu58 CGn1URSYU8R4d4XbbYfvtVsgSgAAAAAAAA== --=-prQxRrXWikc7ujZyIRto-- From nobody Wed Feb 5 02:16:59 2020 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 238E11207FD; Wed, 5 Feb 2020 02:16:57 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 igCS7mv4r-S7; Wed, 5 Feb 2020 02:16:54 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30073.outbound.protection.outlook.com [40.107.3.73]) (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 8EADA120804; Wed, 5 Feb 2020 02:16:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z/5ZWLHWTgrEq1tVRplHq3bBxNdo0UUxxaOVDoPiSvpBq0J7i5FF9IRDwj3qI8nLTv8UTWcrSG953NWZx6NqkBiAaXFYirWQMNfk215eaIPy52dUzr4m+b2RNdmCS9zT1TXNUzXpjwiW/V9CnfytwLShz/i/D5XgLutK8tRJ8i+pKPlW47AHKvv8FOkbwnuaUmi12vob6qMqhsSwIE4GMbYd9hqcnL41k1qokXiEFTh6AURqlZU9hoRYl2V9nEu8+a+YV09qUXHZ2HFDQ4lll4DRMhGheFTSdbG5wMdycG2Ho+VvYhsOwRoAimHVda4RdgFRDrgt8W5CDscdoEmzFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2bSvs+Vc1HL8tZbFkngPJ+94luHfaA9AMWwSsdSvzdM=; b=U/4RhWZr2v2yXzBOFnzP0igB50V1v9jO7nWmYEkehQoow14tyDPMSjuh+eqgrnDhfSUE+RLWozNajFnPGBxzCmaMmQes53dxjjZO1PIioo7x4IgMma6p3VuhmpSuzVakYt/xxJyeHueEDiNCRyVGdijsfjvD1B8k4mrlitmJx96PIUEG9BX9e1l5NVgBHEeIZh3oHaTNmmldkcmTldoXcki1tLgt7loZd6qdLRo88yt42ehTSIIgsQvlMtWubXsaI9LUsea7goUYTevGxbW1fWkuguw/Zs+baQl0b7ibD2lp9UOq/a4pYkkEdpcATSZlQ/gDtgl8PFbuTgnncqzqZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2bSvs+Vc1HL8tZbFkngPJ+94luHfaA9AMWwSsdSvzdM=; b=iNgRXMutN/FmOFZlXdDCMALGGpSQT441QBIg0B/E3woEAoEPbSmIuisuwpQrcVAZwZaqpDXmbxxU3KMNFOAkZelRImcoj7GAU8auYSccThmHSE+PVcn0p77Na9C64h4gF6NS89KAWqCL/be6v9JDRS+19yL9nmcKiMoLxSMDJok= Received: from DB7PR07MB4572.eurprd07.prod.outlook.com (52.135.133.12) by DB7PR07MB4074.eurprd07.prod.outlook.com (52.134.100.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.18; Wed, 5 Feb 2020 10:16:49 +0000 Received: from DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544]) by DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544%5]) with mapi id 15.20.2707.016; Wed, 5 Feb 2020 10:16:48 +0000 From: Magnus Westerlund To: "adam@nostrum.com" , "spencerdawkins.ietf@gmail.com" CC: "quic-chairs@ietf.org" , "iesg@ietf.org" , "quic@ietf.org" Subject: Re: Adam Roach's No Objection on charter-ietf-quic-01-02: (with COMMENT) Thread-Topic: Adam Roach's No Objection on charter-ietf-quic-01-02: (with COMMENT) Thread-Index: AQHV27zvN/KOcYoINkea91+k4i/zvKgL7L+AgAB2hwA= Date: Wed, 5 Feb 2020 10:16:48 +0000 Message-ID: References: <158086324474.15815.7109476137624402668.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.130.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 197f5491-b1ce-47ea-6250-08d7aa2482ff x-ms-traffictypediagnostic: DB7PR07MB4074: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(136003)(396003)(376002)(366004)(199004)(189003)(76116006)(66946007)(71200400001)(91956017)(66446008)(66556008)(66476007)(54906003)(86362001)(110136005)(81156014)(8936002)(81166006)(966005)(44832011)(2616005)(5660300002)(64756008)(66616009)(8676002)(316002)(26005)(53546011)(6512007)(6486002)(6506007)(2906002)(36756003)(478600001)(4326008)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4074; H:DB7PR07MB4572.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8FdRyTm0GgeVjb2t5Ia080rMInnm2WGYFSuxqKS/6KxXCsAgSPNpKjpR4e+cpTiRlAVOfmlHY0HH7dLOf9E8uAkKY1XLDb8Q2KLj/YetzKunhafJy7Jx3qZx5Lxp/cY9pDEAfAbZopUp/7bULOGc8Iro1eVTt3U04+b+nEWhsfRpf6+wTze6JuRZ2ayJ4OKOd0/QTHt9pxBArzVSKqybVaUHtVX/EaTdGN5b/C7GOwMk/mrGY1l0bp+9SLaCTkEsZHem7NkXdyuUVJ1S3l6cVWfu/7G1iSYFubHZVjh0z7Mm+TTwfC5CjOUAoe6YWTKMP/TMHLVfN0dzdlAsfOzCANUMYUUDUmNjvwdL8HBZrX2hFPPwYGxJdsMXqp4UQ8orNMdxPiVN7p7Y558EInua4qJb1pvlXJzh2sRG64DlWwvICBw3obcxyy5EV6zr8UTuD12swL9vY5+FHXWuKr5t62qAYmfCIMlu8oCKb1K0811UG6Rz+2ZdUYZGW56212zai/XvIGXyyogUv4L2z5GE8A== x-ms-exchange-antispam-messagedata: FB5kj9KVxcHdB/H4SMqo1GZXrJErdFTHbIdvI1xYsjMraMydyJ0nqpSoAqb3UvW8m6cOy7lG9sfxzrIEuJA+tiQJHowy7bdvFnTmqEQJS4s+mCsUKG0apcrAwQBAuiwpHRTFvlvEAfAjwWjcHabDkg== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-/Kik0tPwXjOn3YI5DTnN" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 197f5491-b1ce-47ea-6250-08d7aa2482ff X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 10:16:48.8204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: v/wb8QU1e0avaGVxN3lap12LITKtisqA3zk+QJbC+twN5lHTYPzDKMoelG1qAFeF91NA2jFgsx2h/h4jyVMbDWQZnSJm9UFDP3zpba+Afwk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4074 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 10:16:57 -0000 --=-/Kik0tPwXjOn3YI5DTnN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, FEC is current out of scope, by not being explicitly mentioned. And as Mark noted there is a general ruling out of scope additional extension not expli= citly mentioned.=20 With the datagram extension, there will indirect be some discussion of part= ial reliability. However, that function can be implemented in the context of datagram as a pure sender side funciton by tracking which datagram frames t= hat are delivered and which that failed.=20 Cheers Magnus On Tue, 2020-02-04 at 21:12 -0600, Spencer Dawkins at IETF wrote: >=20 >=20 > On Tue, Feb 4, 2020 at 6:40 PM Adam Roach via Datatracker > wrote: > > Adam Roach has entered the following ballot position for > > charter-ietf-quic-01-02: No Objection > >=20 > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > >=20 > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-quic/ > >=20 > >=20 > >=20 > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > >=20 > > I note that the paragraph that previously ruled partial reliability and= FEC > > out > > of scope has been removed. Are these mechanisms to be considered in-sco= pe in > > this new version of the charter? I would suggest that it should say so > > explicitly, if such is the intention. >=20 > I agree with Adam, of course, about making that explicit (one way or the > other). >=20 > Just speaking for myself, of course, but as I read the proposed charter, > datagrams are in scope, and it seems =E2=80=A6 odd =E2=80=A6 to not have = at least partial > reliability in scope as well. >=20 > I'll let people who are more familiar with the current state of play on Q= UIC > using FEC opine about that one. >=20 > Best, >=20 > Spencer >=20 > Spencer --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-/Kik0tPwXjOn3YI5DTnN Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIwNTEwMTY0OFowLwYJKoZIhvcN AQkEMSIEIBKLMcofe2YIvC2M53/DpnnJ1UxFWOKe3folnjvJPm7xMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAL/U3NmT5yDNJ JAMoVHWGz5OvC970DYGFNQOY9I2uF+hWM0qc8EVDRIZd5xjPzZyykjdQWpts9kKNb3RHDD4lguMM wzWioBx9f93vlgXyDKelR4L172T/U8dqX+A907ODJpQtMv30ynFxbQctzEqwHcvdBSFQMbJC/9wZ 8eCzbVUIgfN78eKgzxdcQJdXYSJh0bC3/UEWkFLiLORPDCLbSGYYgCrp2MCoZpFH+cy/aJTeHgM+ 6eLnloqg5kXS62GfiYN7H+Mkk8sbe7kL6VbjUXxaZPgEsxfqkU2I0jMKDYHcnvF+Viw8T9uw9S1R GW0QWwjJkUJo9VekOfPRp4MeCAAAAAAAAA== --=-/Kik0tPwXjOn3YI5DTnN-- From nobody Wed Feb 5 02:32:56 2020 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 3F6CF1207FD for ; Wed, 5 Feb 2020 02:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 UMVjjp3Jr9IY for ; Wed, 5 Feb 2020 02:32:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCC912012D for ; Wed, 5 Feb 2020 02:32:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1259DBE39; Wed, 5 Feb 2020 10:32:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRPb7ku-kZwY; Wed, 5 Feb 2020 10:32:46 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DE8EABE2F; Wed, 5 Feb 2020 10:32:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1580898766; bh=nhAFyIAkcOZPeYHUg7OUk31HyRYKdzKXlzMBMT1Ua5c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NAg3ZuPk27uZt1u1czpzhcrIYy4mWNbLFF3B2pRjlQ6gWLnx77I1pHDeHx8r4fRJM BCmqfXV9rOAVbGCAHnRBHiVddnCjCQGRU2v3w50EUluuObS0zkk3OFCTIIAMqsURDi jG7UwIT9A3ujfP4u3Vkn5thsHJeh4lDfgfuiHIak= Subject: Re: QUIC re-chartering: include DNS-over-QUIC? To: Magnus Westerlund , "mnot@mnot.net" , "erik+ietf@nygren.org" Cc: "lars@eggert.org" , "quic@ietf.org" References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Wed, 5 Feb 2020 10:32:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="K9eTzoX1hphRQtirQIhsFeqRj9VFO7fml" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 10:32:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --K9eTzoX1hphRQtirQIhsFeqRj9VFO7fml Content-Type: multipart/mixed; boundary="oTDf0l9phEKrxyWgaKLOPEshHZGWtpW2R"; protected-headers="v1" From: Stephen Farrell To: Magnus Westerlund , "mnot@mnot.net" , "erik+ietf@nygren.org" Cc: "lars@eggert.org" , "quic@ietf.org" Message-ID: Subject: Re: QUIC re-chartering: include DNS-over-QUIC? References: In-Reply-To: --oTDf0l9phEKrxyWgaKLOPEshHZGWtpW2R Content-Type: multipart/mixed; boundary="------------D61AD95AF58669D74062A5FE" Content-Language: en-US This is a multi-part message in MIME format. --------------D61AD95AF58669D74062A5FE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/02/2020 09:59, Magnus Westerlund wrote: > But, please figure out if this is a reasonable piece of work to do anyw= here in > the IETF. However, the right place may be a more DNS focused WG.=20 FWIW, I think doing this somewhere else seems better. As dprive are considering recursise->authoritative, I hope this option gets examination as part of that. I'm not sure if it'd be better than DoT but if it were, that'd perhaps provide a justification for standardising DoQ. Cheers, S. --------------D61AD95AF58669D74062A5FE Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------D61AD95AF58669D74062A5FE-- --oTDf0l9phEKrxyWgaKLOPEshHZGWtpW2R-- --K9eTzoX1hphRQtirQIhsFeqRj9VFO7fml Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl46mc0ACgkQWrL68XsX K+pRCQ/8DKf4PQuNRoUIb35cZfOeEfk1DTcn/2Tdr8qNk2j68HQ2MxoyBRRbufCl GzvTt3GoCBWSBAfxPf2JX4gLvG7JzUm9LBuA1xgV4uT8kwdAnD22N/LpRpYRUFMx 0k2p37fVsTtvV+5tA/HOyiChFGP2Z/1rn6sBl7M+k6fHPSXMwZPdbs5fnB98EBhn VF84J8z2bVk098/caw2NdBdcmv8ayh7ZNrmFA4hUphBB0+n0IZlu/OsBoWf1Ea3N OVOXjV2hS1S6JBY+/BpyQoeYnpGFN5BHx7GSk7osF29IDaNDbz6SvI9A2Ab9+8es idzEMg6IwhIQ+sbaGHi2q75SqBS9jzuemcaMhcfgb9UA5n9AOxD+Vn6mVn6LHatI BC7udduFhsXcSoX430k38z9QcplmYDInwcCml4hoUOxLfk3UVk6m4hmGVJ5DWM8V A9OLiUkX3z3hxv27/cWb87nywAdqX3LsjziPAGZMoPxCMYvEh8n47LkFsXmWlQxo mn3aH26mjFd2kXfacxT7vtjRXgb9ybhSTfQO7686s0ecqTWWGIblvOhVnQ1MWkNx nDEClrarjjLZ/bcJlPVTSZtf348qGC75MjQKO1emHzk7yxLbT68j+YolT9JoirEo bcxKa6aTnLMdIYaFG8EMcLSmlTfWTrJW1BqOPnEi/rpjL6dhSic= =ByN1 -----END PGP SIGNATURE----- --K9eTzoX1hphRQtirQIhsFeqRj9VFO7fml-- From nobody Wed Feb 5 06:52:07 2020 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 47B661200C1; Wed, 5 Feb 2020 06:51:53 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 nDLQQV_n6VKZ; Wed, 5 Feb 2020 06:51:50 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on062c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::62c]) (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 2BB8D1200B3; Wed, 5 Feb 2020 06:51:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JqOJg8bON1QpJvE3bucN3Nfjrg82vXwgXbmAoqmVIUBzKCFK+oqzvrqb5j/Ib/kKZSEOY6P0PpqEBzH/z+tzwAU4jxbc7c2NbMnw6K7FFahmgbUkS1z7KaliEkni3g3lHTtbUwqexUJd4Y2IHVl6v6YRAFkp0fMx3Ko7p3H93XiwsA8nINhZEIHfrN+C+2Q/71GazBUlXa/SEhCE4U6RX1hmZlNqW2FMkUJX+XaVyRkq3S6freReJcjCbFxrVURtcUqCdGxDgd7Tu+t2CAMFST4aSwOH4ZV83stylGaPndMLyuUKR0AEOO7uEA/MsQsJkssjKdFUjT5ZyE0hXgkiOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AVcD/IzdFJOxa+C1jcQc0hLWfXhdKE65pvZGdnm+Fuo=; b=hDFmUdxk9IkFtTJ2+cAva5BTb3O4IDe/NBsTUu1JT1b8OAhutny/T7nTNEGc/e6VkaFeARNcRPwjJlFo/q55Ab570AUxgYqNpMmi22tE/rEGlhxpBT+AI4gpoq0zYiGZYAeFfmIpC7e88yF4ZSb9QdQOlfgUeEV1hteYTgdFbO4PYg13uXqTKFzymllwHbubdQ6Qu5zjhftF7wuqwQZs6k6F2pNDZgLp0H/MMYtSMAeWA0OxIj4x+wAsK87we2r5YQwfPTf4mR3jvGTqnYkpX52yBEJOAPiXP5MkiZ5ijKzPAJ6c/VAb2vusCsOjO1dlP4qcWkEjuLggxao+RkMp5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AVcD/IzdFJOxa+C1jcQc0hLWfXhdKE65pvZGdnm+Fuo=; b=D9N+53EOa9W+BCxRsuMmjBA8L0uJZBOFQ1Kb8gSe7FsuIJdJ6zEIpU+veUl/BVFVa4K/FqqzZzq/c78NPALIgyI5UxlfzSP5uZXrdC4EZLhQhBuU1snEmRVzy+13Vp185UPHuqvtUJb6JvZMSzRyEyZ4JeJc6lKuQNQWtzo8mqs= Received: from DB7PR07MB4572.eurprd07.prod.outlook.com (52.135.133.12) by DB7PR07MB5257.eurprd07.prod.outlook.com (20.178.42.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.15; Wed, 5 Feb 2020 14:51:47 +0000 Received: from DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544]) by DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544%5]) with mapi id 15.20.2707.016; Wed, 5 Feb 2020 14:51:47 +0000 From: Magnus Westerlund To: "iesg@ietf.org" , "alissa@cooperw.in" CC: "quic-chairs@ietf.org" , "quic@ietf.org" Subject: Re: Alissa Cooper's Yes on charter-ietf-quic-01-02: (with COMMENT) Thread-Topic: Alissa Cooper's Yes on charter-ietf-quic-01-02: (with COMMENT) Thread-Index: AQHV25C2n2YnUm2Q2kemVB8AIeWl96gMsHKA Date: Wed, 5 Feb 2020 14:51:47 +0000 Message-ID: <4c5a23b4cca201be66af5a6e03e41a8761978371.camel@ericsson.com> References: <158084425568.15760.14010903358228220915.idtracker@ietfa.amsl.com> In-Reply-To: <158084425568.15760.14010903358228220915.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.130.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 18948721-d421-428b-67ea-08d7aa4aed10 x-ms-traffictypediagnostic: DB7PR07MB5257: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(366004)(376002)(346002)(199004)(189003)(8936002)(71200400001)(54906003)(478600001)(81156014)(81166006)(186003)(5660300002)(4744005)(6512007)(4326008)(8676002)(66616009)(966005)(6486002)(6506007)(26005)(316002)(110136005)(44832011)(36756003)(64756008)(2906002)(66476007)(76116006)(91956017)(2616005)(66446008)(86362001)(66946007)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5257; H:DB7PR07MB4572.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4n9GAehC4sJUF3Ri0V3uDOfrTA4+4cNAv8CN8vCYxKuVTpSDQiD4vQFFeR96oqyvoeQmPe1G6uDo1+EfgZ7B7QYxKL0XOrkIeIS0+G06xhY3DVIZI8arbtcIn/wmcJ9AHwL7HqXm4b4PQzPWan9U1ZoVZZjUnY5vEiFuO4+P7J+L6emtW+f2OHGKyHM1x76Qn0/4fTCz0t7yxQQyrWyCJ1XT1v9wDpJcTwsXo+C1k210Jfqw4/tfp2+Sq21So+AEWlAqi35G0VPC4jgd1AbXw3BSdcIcOyfK1r4dpWzvTCU0p3xy8BaG6FYecBu/wnGdTaquvY9l+iFOibxhaSxhStaauPx5Q23ucNkt/WXzac9ey6QtLpzZSOoa0KZoHLSBNzLisxc73uTtxPiX6vkqsuZ75gDW/7rWBmELmrwr997FeP7Q08FwnAHxeYMMuNb9Steh5bepPr3o8+iI8D3+1JYNCsZSXeeFT1DhJCU3yeY2cvB6Z6Z8756sChQVW/ZXlMQiCk24ONA/mLVTvJytnA== x-ms-exchange-antispam-messagedata: kI6AvqEe4x/OhrmfI7efGIGvCk+SzXCbMmijNI1bzE9Y1TIxRTwSUkRRWwxVX5IpkfnztS50ibWrMHImiEkvaG6ANgaolY5SW8Xj44o9Qo2x/ErbD9gpX8NCZlxNwf3REPmAob6wOBRg0GJVl5hUFQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-qN8ktPaeZMTocIc9UQxx" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 18948721-d421-428b-67ea-08d7aa4aed10 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 14:51:47.6972 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Uc0BZ5rH/6TyXL0Xyt0E0k6zQ1ZcjY7r0Zc7UXuOzPraSTys74+RmTxQaJAR5tjX3miT497S5DSTsXS6KVspTQZJZ2trFOjeJ/KxEK1Gai8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5257 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 14:51:54 -0000 --=-qN8ktPaeZMTocIc9UQxx Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2020-02-04 at 11:24 -0800, Alissa Cooper via Datatracker wrote: > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-quic/ >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The milestone dates need updating. >=20 This is now addressed. We also remove a duplicate and added the milestones = for the extensions.=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-qN8ktPaeZMTocIc9UQxx Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIwNTE0NTE0N1owLwYJKoZIhvcN AQkEMSIEIAsdht/RYq5J56/yO1q94Dj5KxmYAW3QvPl1BO2p6Wn4MGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAFrtrmUJLLN9Y dLhPKSJ+aZ/7ccmyeFid1GZOU4Rwxj3fATGjQZ1HHwRNkmC2V21+A+lP1MqvKMMsQxIrurMRABAX b+b7nOp5nYm8o81v5pYxQ5S+CU8qWYy9a8a0ffjVawP3wGH/zXBVhaHlFJ5rmnvlGmC4pN3fyoEc NqEgtcnUBM/4nTTLeetCSIAWbRpmbU58R7BoXrT1Zi+FdRQ5ZNn/EO7JbP+1VZ07yKoV6EEJBbRk TDxIFFICEENCGfJ5nWiFLQHL5V2AzDPh8ieKbFc2P7f7MxxUxzJQH5Naw/xeMGiBHf/oZHy9ZgSl NDLyr8Qk6Sezqz4h0ps0zdcfvwAAAAAAAA== --=-qN8ktPaeZMTocIc9UQxx-- From nobody Wed Feb 5 08:17:01 2020 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 A4151120898 for ; Wed, 5 Feb 2020 08:16:59 -0800 (PST) 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 (2048-bit key) header.d=mnot.net header.b=2gNRz25C; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ztxeKsFR 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 a-605Mw7uFYn for ; Wed, 5 Feb 2020 08:16:57 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C93120893 for ; Wed, 5 Feb 2020 08:16:57 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id F11E473E; Wed, 5 Feb 2020 11:16:56 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 05 Feb 2020 11:16:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=X 2HjCSGuLDBKO4u7/2+m9dPjIDHNmZPo2pcLeMja6hg=; b=2gNRz25CrqMXYddJH W5fu/Ypf5mNjkiQ0VcQuzBxi2XEb1f1mwToZFCZstrzW4vWox3GcRn/LXUdTcAWR OOElZDmqGB95xp5jEp1vqu2USsBlvWw5/z7tMwXN9++cJqRZCkTTfLDAk5dtpMYe SLFufEr73QTD699/o8urZjNWpudZK7whi6PW5us4BokFypGj4fK71dqhV8986Aus 7AMd+xmwYDHR/qAKCJvodboTua1TsxLWANW5r5QrmNjHIpxE2rXdLeYDRcJSUBBY coFE4IX/kPVxsw3tki/f8Cs5LEN6chsqRzGtkUp0lCOlNCsXJ0IMQzxc5Bb1KlUA AGbtA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=X2HjCSGuLDBKO4u7/2+m9dPjIDHNmZPo2pcLeMja6 hg=; b=ztxeKsFRGGcImLQTs+jvh7kiHE33ycxQEiyu/py+3Pi4JVF1hpqS3WDp4 tS2O+aSCQqTjP3JNfzGd54ALtoTfsNC9XG55oII8/r+BsltPiUY2h816DR9GGnEW uUnZBeVLDEkmMOL3qWcJlnMWJgmY0+35dF6b9mWwavYiWp1F+FyJbZh2cgk2bHGP 6plGPkxW0a12FGwywKRZDSE6AgWdUxPcSOO+GgZ6dizq8QdCqlGFmipbD2DIq0tb 7HMCKOZ/twhgm8WuLacp15W951IKQRY+Vv09B+RKaNCFbYyFq5qZVjVBiixmMgY1 mDEWCuv//Jkf20LI+GRPz+E1820dw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrhedugdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppedutdegrddufedvrddvvdek rddutdeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [100.72.36.122] (unknown [104.132.228.106]) by mail.messagingengine.com (Postfix) with ESMTPA id 28A173280063; Wed, 5 Feb 2020 11:16:55 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: Consensus calls for Late Stage-Documents, pre-Zurich edition From: Mark Nottingham In-Reply-To: <81D63E10-B725-45CA-AD3F-0DF70294C569@mnot.net> Date: Wed, 5 Feb 2020 17:16:54 +0100 Cc: Lars Eggert , Lucas Pardue Content-Transfer-Encoding: quoted-printable Message-Id: References: <81D63E10-B725-45CA-AD3F-0DF70294C569@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 16:16:59 -0000 Hearing no pushback, consensus declared, *except* for #3357, which has = an outstanding discussion. > On 24 Jan 2020, at 5:35 am, Mark Nottingham wrote: >=20 > The following issues have proposals for resolution, and discussion so = far seems to support consensus to accept them. If you object, please do = so on the issue or in response to this message (changing the Subject = appropriately!). Absent any pushback, we'll direct the editors to = incorporate them just before the Zurich meeting. >=20 > See for the current = state of issues in the Late Stage process, itself defined at = . >=20 > * #3357: Only send one immediate ACK after reordering > The proposal is >=20 > * #3345: Clarify the definition of things that make messages malformed > The proposal is >=20 > * #3307: Allow use of token after client address changes > The proposal is >=20 > * #3297: Immediate close without state > The proposal is >=20 > * #3275: Why are there two ways of associating push with requests? > The proposal is >=20 > * #3269: CONNECTION_CLOSE for unpadded Initial > The proposal is >=20 > * #3117: Recouple QUIC version and ALPN > The proposal is >=20 > * #2555: Define idle period for congestion control > The proposal is >=20 > * #2125: Document what needs to be checked for address validation > The proposal is >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu Feb 6 03:36:09 2020 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 40B1112009C for ; Thu, 6 Feb 2020 03:36:08 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 xnuK6WeNR97c for ; Thu, 6 Feb 2020 03:36:07 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 EB56A12023E for ; Thu, 6 Feb 2020 03:36:06 -0800 (PST) Received: from xse88.mail2web.com ([66.113.196.88] helo=xse.mail2web.com) by mx37.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1izfRu-0006cS-TL for quic@ietf.org; Thu, 06 Feb 2020 12:36:03 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 48CxFb06JGz1kvg for ; Thu, 6 Feb 2020 03:35:47 -0800 (PST) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1izfRi-0001xS-SW for quic@ietf.org; Thu, 06 Feb 2020 03:35:46 -0800 Received: (qmail 11890 invoked from network); 6 Feb 2020 11:35:46 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.10]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Feb 2020 11:35:46 -0000 To: Tommy Pauly , Erik Nygren Cc: Lars Eggert , Mark Nottingham , IETF QUIC WG References: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Subject: Re: QUIC re-chartering: include DNS-over-QUIC? Message-ID: <367135c9-ea82-9fe7-8d80-a1b47440e2a1@huitema.net> Date: Thu, 6 Feb 2020 03:35:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.88 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.88/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.88/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.52) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0S9sfM/nP8gxoqs1zeWkeM2pSDasLI4SayDByyq9LIhVjjXXIDv3C9Ei oF0oP/pyMETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fvV6O15lENb52gjZoL7wFUDU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+7KJix/R2qbtdH2ZflMjNgfMm/JD3cPBOX47Hg3FEpDo46jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm4Mn5ODoMuXT e61GOROcBldP1gB2VhyL18pVuJYmbB3RnEFK86tKSWORln+y9m0OHweYUOp7A73HI6oJg7w/Vocg cKoGWvjwxDCpaZLCR0lVmhlKb/lC+C9AijoWgc8vkIGThCScvU0cCIiHSQbmcVIGC2ArCTCHImaG ATskdebEAztqzrCt4TZ/wLtujY/tpR81IKh6p5gjuJGp4KtRoeANhZYKgFjyp5g7TFwWTJFRPAlb DjazCbhs7qBpykynMvtDTtO+u9LH2FRC7Cqll7XeIx9XxyO4NNsp5Cj289fSNWOfRy3it5pbjqbJ QF61U112fwop9BTafX0DKHjywhGbO+8nMRYL9kekVL4dhx06ifnL+9wgoTj4ygNPw1XfN0zsCG5v xMF5WG1gYscNCfISP4VPJRUjPgTf43t5z5OGMMhkxyAKDRV/o3FuwxpnRHnKFOL2qbwhklIekV0n lts= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 11:36:08 -0000 On 2/4/2020 4:17 PM, Tommy Pauly wrote: > My main question in doing DNS-over-QUIC is what benefit it provides > over DNS-over-HTTP/3 (DoH3?). DoH3 seems like a more practical > deployment model, since it allows relatively seamless upgrade from > DoH2 to DoH3, and allows a resolver to support consistent semantics on > both. The overhead of the HTTP layer is pretty minimal, and while I > appreciate the desire to define a non-HTTP protocol over QUIC, I > imagine there would be ones that would be more useful to adopt in the > near term. There are significant differences between DoQ and DoH. My main worry is that protocol written to run over HTTP tend to be developed on top of web platforms, and so you end up bringing the entire attack surface of the web platforms in your DNS implementation. That's OK if your DNS usage is directly dependent on your web traffic, for example if a browser is sending queries for the pages that it visits. But that's not so good for the resolver to authoritative scenario, in which a leaner protocol seems safer. But there are other issues. Look at the "M" scenario in the Quic Interop runner, loading 2000 small files in parallel. It turns out that several implementations had issues because when doing that they were hitting the OS limit on the number of open files. The way you control that in Quic is by limiting the number of open streams below the number of files that you can maintain open. In a web-oriented implementation of H3 and Quic, you will most likely do that. But you don't need to worry about that in the DNS scenario, because you are certainly not going to write a file for every DNS transaction. Doing an ad hoc application mapping avoids this kind of issues. -- Christian Huitema From nobody Thu Feb 6 06:57:34 2020 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 0CBDC12006D for ; Thu, 6 Feb 2020 06:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 SOMCZVAnTQ8r for ; Thu, 6 Feb 2020 06:57:28 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 291D412004E for ; Thu, 6 Feb 2020 06:57:27 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id g23so3933408vsr.7 for ; Thu, 06 Feb 2020 06:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NWLnv1q2whbYxe0dWVva0EdMbZEAbcra1Y+KSsosGoY=; b=Tb4mFpbyUXKafSyXX0H67jDeBsxsuX4WnT480IQDlHkSQu1pUPRUrpiB/gGdLbN76g NqqvsE4W2yh6D+WvkP2q5JN9HGtkpT6VARuCOXUpbhZoqL6p6E2DpfuXBs04o7TZMXMw 4Rn5XFsDYqV2TNEjtieJVaLZu6y5thsKpLLTZDnlwPtsgaBKF4Dq7GmR2IwgQyjPg012 kE2XVoYdBJOTJTQTUQDvnyUWjaR98p8oPiCa7T/LDWi2h8pj00ngIlAOvBsB25mN5FYp UV7WSPYoIp0bsDh1scf+kCFnvFo0sWkfh8F46NVi2luJrIjeGBDEGflAwX6e8KvIGlx6 xfoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NWLnv1q2whbYxe0dWVva0EdMbZEAbcra1Y+KSsosGoY=; b=QtHFhP0ZCs/nxGaszkg+YXBiUZwdqVSgMeXDxAQTb2J599tcj0bBDIyPquM5/I6/u7 3bk/4OaHibDtWcKazB1mh/5KkBIFpaeoOfqSfddZLG0GlAl05qJ9g+6x21u9VZMQUyod yAWZ828cK5fHYe4kCQNhM1Lqa1RTvR4Yx0mzoAE2u2l+4e/kXrsGcVZvlUMCKmT1pXC3 cWqdZuiYrVRAexfxXNywEUcZm35djGteAbtcxgyszKkmxTe+nJ9sEEpFxJ4eVuQnnU/m fVt+KgO7BMuapQhzSBdqg2kU9gAlGobZPNtfma3b5nQakyEm7fDbAYO0Ye4BDmmtR0XQ HhJA== X-Gm-Message-State: APjAAAWSk7TmL38YjsQtArNODWoFY2pvo4KScnfw+Uwz/fIv60QsmWSH nwkbFXZ3TRJUFUSQRI8l1eoThTe/OIbr51tSiFJqyzcE X-Google-Smtp-Source: APXvYqx7CMXPyKWoWhcXGFyBw2aTQ982thUMzvn1XPJnqbs6GEYG2YWXLDfunjySJB9tKY/D06tev33rmg/O/yGmjsg= X-Received: by 2002:a67:89c4:: with SMTP id l187mr1861419vsd.31.1581001045776; Thu, 06 Feb 2020 06:57:25 -0800 (PST) MIME-Version: 1.0 References: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> <367135c9-ea82-9fe7-8d80-a1b47440e2a1@huitema.net> In-Reply-To: <367135c9-ea82-9fe7-8d80-a1b47440e2a1@huitema.net> From: Daniel Migault Date: Thu, 6 Feb 2020 09:57:14 -0500 Message-ID: Subject: Re: QUIC re-chartering: include DNS-over-QUIC? To: Christian Huitema Cc: Tommy Pauly , Erik Nygren , Lars Eggert , Mark Nottingham , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b91d74059de97d8d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 14:57:32 -0000 --000000000000b91d74059de97d8d Content-Type: text/plain; charset="UTF-8" I support DoQ being done here or somewhere else to prevent including the attack surface of the web platform as well as to have a non HTTP use case for quic. I also expect that previous work on DoT, DoH will reduce the effort on DoQ. It is true one could question the advantages of having yet another transport, but on the other hand, it might be better we can have the choice now rather than later. Yours, Daniel On Thu, Feb 6, 2020 at 6:36 AM Christian Huitema wrote: > On 2/4/2020 4:17 PM, Tommy Pauly wrote: > > > My main question in doing DNS-over-QUIC is what benefit it provides > > over DNS-over-HTTP/3 (DoH3?). DoH3 seems like a more practical > > deployment model, since it allows relatively seamless upgrade from > > DoH2 to DoH3, and allows a resolver to support consistent semantics on > > both. The overhead of the HTTP layer is pretty minimal, and while I > > appreciate the desire to define a non-HTTP protocol over QUIC, I > > imagine there would be ones that would be more useful to adopt in the > > near term. > > There are significant differences between DoQ and DoH. My main worry is > that protocol written to run over HTTP tend to be developed on top of > web platforms, and so you end up bringing the entire attack surface of > the web platforms in your DNS implementation. That's OK if your DNS > usage is directly dependent on your web traffic, for example if a > browser is sending queries for the pages that it visits. But that's not > so good for the resolver to authoritative scenario, in which a leaner > protocol seems safer. > > But there are other issues. Look at the "M" scenario in the Quic Interop > runner, loading 2000 small files in parallel. It turns out that several > implementations had issues because when doing that they were hitting the > OS limit on the number of open files. The way you control that in Quic > is by limiting the number of open streams below the number of files that > you can maintain open. In a web-oriented implementation of H3 and Quic, > you will most likely do that. But you don't need to worry about that in > the DNS scenario, because you are certainly not going to write a file > for every DNS transaction. Doing an ad hoc application mapping avoids > this kind of issues. > > -- Christian Huitema > > > > -- Daniel Migault Ericsson --000000000000b91d74059de97d8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support DoQ being done here or somewhere else to prevent= including the attack surface of the web platform as well as to have a non = HTTP use case for quic. I also expect that previous work on DoT, DoH will r= educe the effort on DoQ. It is true one could question the advantages=C2=A0= of having yet another transport, but on the other hand, it might be better = we can have the choice now rather than later.=C2=A0
Yours,=C2=A0
Dan= iel

On Thu, Feb 6, 2020 at 6:36 AM Christian Huitema <huitema@huitema.net> wrote:
On 2/4/2020 4:17 PM, Tommy Pau= ly wrote:

> My main question in doing DNS-over-QUIC is what benefit it provides > over DNS-over-HTTP/3 (DoH3?). DoH3 seems like a more practical
> deployment model, since it allows relatively seamless upgrade from
> DoH2 to DoH3, and allows a resolver to support consistent semantics on=
> both. The overhead of the HTTP layer is pretty minimal, and while I > appreciate the desire to define a non-HTTP protocol over QUIC, I
> imagine there would be ones that would be more useful to adopt in the<= br> > near term.

There are significant differences between DoQ and DoH. My main worry is
that protocol written to run over HTTP tend to be developed on top of
web platforms, and so you end up bringing the entire attack surface of
the web platforms in your DNS implementation. That's OK if your DNS
usage is directly dependent on your web traffic, for example if a
browser is sending queries for the pages that it visits. But that's not=
so good for the resolver to authoritative scenario, in which a leaner
protocol seems safer.

But there are other issues. Look at the "M" scenario in the Quic = Interop
runner, loading 2000 small files in parallel. It turns out that several
implementations had issues because when doing that they were hitting the OS limit on the number of open files. The way you control that in Quic
is by limiting the number of open streams below the number of files that you can maintain open. In a web-oriented implementation of H3 and Quic,
you will most likely do that. But you don't need to worry about that in=
the DNS scenario, because you are certainly not going to write a file
for every DNS transaction. Doing an ad hoc application mapping avoids
this kind of issues.

-- Christian Huitema





--
Daniel Migault
Ericsson
--000000000000b91d74059de97d8d-- From nobody Thu Feb 6 07:13:50 2020 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 6EC871208AE for ; Thu, 6 Feb 2020 07:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 rXS0rAE8DfMr for ; Thu, 6 Feb 2020 07:13:47 -0800 (PST) Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) (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 6742A12080C for ; Thu, 6 Feb 2020 07:13:47 -0800 (PST) Received: by mail-wm1-f67.google.com with SMTP id p17so422019wma.1 for ; Thu, 06 Feb 2020 07:13:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y22qqnqvGoTGvxpgro9wLz84GNvMBgJKeNWKiYKakcg=; b=hJT4UnermmSHz3pVKsKOCKftINF7trUc0Ixsbwkwca7E1FH/oVzSG5IHVSQgQ9PVAr 5gIiDL6Kl6UYJdKZYIFvBdUVXTIow9B9Gr1+dNB4w8QruAm/EUUFRbjdwUr7iUHQZIYG vfSJ693iTN8mtJ2Tu3+lbnh+aqNuEqNCXvK4PLcL2S+QgHsvnCGmG6hQujuxeDfaa2/d Sb0EjPNTSNpdURUQpXwaKGQPEqgXzkKyXkiN0/ZB6rDYA0EAgVperDlWWR5owqVCMi+3 CW51/Va10VHf3KS3TPlQFGI5ul0KwyVG34Y7bVYofGGHGEXHpAyVD6/N+RHA5nMJxnoo OrKg== X-Gm-Message-State: APjAAAXO1XAP9BejZJ2GeCIr0upMBOKykJrwfiuuXo9LGriW9NJGHYyI JMjNyulM6V+fkfgaAFcWK3XPhO83wd8wXX45LsU= X-Google-Smtp-Source: APXvYqxP4kO8CIGOMuXO3aQVzJMSg+/lBdh/EgkmIWdCoErb6WqpGhsEyM68OG/7dbq9jFOutl9Cd3tpLHFgBtfYPhU= X-Received: by 2002:a1c:a754:: with SMTP id q81mr4954637wme.139.1581002025298; Thu, 06 Feb 2020 07:13:45 -0800 (PST) MIME-Version: 1.0 References: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> <367135c9-ea82-9fe7-8d80-a1b47440e2a1@huitema.net> In-Reply-To: From: Erik Nygren Date: Thu, 6 Feb 2020 10:13:33 -0500 Message-ID: Subject: Re: QUIC re-chartering: include DNS-over-QUIC? To: Daniel Migault Cc: Christian Huitema , Tommy Pauly , Lars Eggert , Mark Nottingham , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000001b7175059de9b883" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 15:13:49 -0000 --0000000000001b7175059de9b883 Content-Type: text/plain; charset="UTF-8" It sounds like a good path forwards might be to take the draft-huitema-quic-dnsoquic to dprive in Vancouver and/or Madrid if the authors are interested and willing? For encrypting recursive-to-authoritative I'm hopefully that we can pick one (or at most two) things as "MTI" for interop, and I suspect if we had a pros/cons matrix for the various options that a DoQ solution has a good chance as being the contender for being the preferred option for reasons stated above, as well as for other functionality that exists in QUIC that may make scaling and robustness easier for authority operators. Erik On Thu, Feb 6, 2020 at 9:57 AM Daniel Migault wrote: > I support DoQ being done here or somewhere else to prevent including the > attack surface of the web platform as well as to have a non HTTP use case > for quic. I also expect that previous work on DoT, DoH will reduce the > effort on DoQ. It is true one could question the advantages of having yet > another transport, but on the other hand, it might be better we can have > the choice now rather than later. > Yours, > Daniel > > On Thu, Feb 6, 2020 at 6:36 AM Christian Huitema > wrote: > >> On 2/4/2020 4:17 PM, Tommy Pauly wrote: >> >> > My main question in doing DNS-over-QUIC is what benefit it provides >> > over DNS-over-HTTP/3 (DoH3?). DoH3 seems like a more practical >> > deployment model, since it allows relatively seamless upgrade from >> > DoH2 to DoH3, and allows a resolver to support consistent semantics on >> > both. The overhead of the HTTP layer is pretty minimal, and while I >> > appreciate the desire to define a non-HTTP protocol over QUIC, I >> > imagine there would be ones that would be more useful to adopt in the >> > near term. >> >> There are significant differences between DoQ and DoH. My main worry is >> that protocol written to run over HTTP tend to be developed on top of >> web platforms, and so you end up bringing the entire attack surface of >> the web platforms in your DNS implementation. That's OK if your DNS >> usage is directly dependent on your web traffic, for example if a >> browser is sending queries for the pages that it visits. But that's not >> so good for the resolver to authoritative scenario, in which a leaner >> protocol seems safer. >> >> But there are other issues. Look at the "M" scenario in the Quic Interop >> runner, loading 2000 small files in parallel. It turns out that several >> implementations had issues because when doing that they were hitting the >> OS limit on the number of open files. The way you control that in Quic >> is by limiting the number of open streams below the number of files that >> you can maintain open. In a web-oriented implementation of H3 and Quic, >> you will most likely do that. But you don't need to worry about that in >> the DNS scenario, because you are certainly not going to write a file >> for every DNS transaction. Doing an ad hoc application mapping avoids >> this kind of issues. >> >> -- Christian Huitema >> >> >> >> > > -- > Daniel Migault > Ericsson > --0000000000001b7175059de9b883 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It sounds like a good path forwards might be to take the draft-huitema-quic-dnsoquic
to dprive in Vancouver and/or Madrid= if the authors are interested and willing?

For encrypting recursive-to-= authoritative I'm hopefully that we can pick one (or at most
two) things= as "MTI" for interop, and I suspect if we had a pros/cons matrix= for the various
options that a DoQ solution has a good chance as being the = contender for being the preferred
option for reasons stated above, as w= ell as for other functionality that exists in QUIC
that may make scaling and= robustness easier for authority operators.=C2=A0

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



On Thu, Feb 6, 2020 at 9:57 AM Daniel Migault <mglt.ietf@gmail.com> wrote:
<= /div>
I s= upport DoQ being done here or somewhere else to prevent including the attac= k surface of the web platform as well as to have a non HTTP use case for qu= ic. I also expect that previous work on DoT, DoH will reduce the effort on = DoQ. It is true one could question the advantages=C2=A0of having yet anothe= r transport, but on the other hand, it might be better we can have the choi= ce now rather than later.=C2=A0
Yours,=C2=A0
Daniel

<= div class=3D"gmail_quote">
On Thu, Feb= 6, 2020 at 6:36 AM Christian Huitema <huitema@huitema.net> wrote:
On 2/4/2020 4:17 PM, Tommy Pauly= wrote:

> My main question in doing DNS-over-QUIC is what benefit it provides > over DNS-over-HTTP/3 (DoH3?). DoH3 seems like a more practical
> deployment model, since it allows relatively seamless upgrade from
> DoH2 to DoH3, and allows a resolver to support consistent semantics on=
> both. The overhead of the HTTP layer is pretty minimal, and while I > appreciate the desire to define a non-HTTP protocol over QUIC, I
> imagine there would be ones that would be more useful to adopt in the<= br> > near term.

There are significant differences between DoQ and DoH. My main worry is
that protocol written to run over HTTP tend to be developed on top of
web platforms, and so you end up bringing the entire attack surface of
the web platforms in your DNS implementation. That's OK if your DNS
usage is directly dependent on your web traffic, for example if a
browser is sending queries for the pages that it visits. But that's not=
so good for the resolver to authoritative scenario, in which a leaner
protocol seems safer.

But there are other issues. Look at the "M" scenario in the Quic = Interop
runner, loading 2000 small files in parallel. It turns out that several
implementations had issues because when doing that they were hitting the OS limit on the number of open files. The way you control that in Quic
is by limiting the number of open streams below the number of files that you can maintain open. In a web-oriented implementation of H3 and Quic,
you will most likely do that. But you don't need to worry about that in=
the DNS scenario, because you are certainly not going to write a file
for every DNS transaction. Doing an ad hoc application mapping avoids
this kind of issues.

-- Christian Huitema





--
Daniel Migault
Ericsson
--0000000000001b7175059de9b883-- From nobody Thu Feb 6 07:28:38 2020 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 F276612006D for ; Thu, 6 Feb 2020 07:28:36 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 njXJ97GoBo6j for ; Thu, 6 Feb 2020 07:28:34 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E24931208FE for ; Thu, 6 Feb 2020 07:28:33 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 016FEshA016057; Thu, 6 Feb 2020 15:28:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=TAfxcM/CSSkrfVfYF/64AkCIDqQP4XZ5iR3X43o3XPA=; b=V4jm1s+ySuHs9NHx+RvHhPhkdRXx9ac+nqIUEtU6mC3Q7UfRuln+8sTMdpMv75DCiVHA uXmFRHhxezXtld2X60QeM+I1Gw44Iu+00bHxT4Bomf8R0OvDi5h21S/xISAaKlTJL7bK P5IUcl+IZjREhyCvOeGlNojF+ueBmxAs/PbCZPwlx68wb2SqZts3cQy/drP3EovP1iKh JSYXtwxQrQ0kLiRkz2cHm4jabxa0aS8foldMe9Foz0C3Ar+lrvk45kAPT2+FWOHfhr/K aEAylWnaYhmYBFIDnFfypkvXPJBFRDRr7Asug7W8gAA0w6qBtU8Eq0LxCH2oec5p+OaN sg== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2xyhpffgqd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Feb 2020 15:28:24 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 016FHU2E021960; Thu, 6 Feb 2020 10:28:24 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 2xykfw3h10-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 06 Feb 2020 10:28:23 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Feb 2020 10:25:22 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 6 Feb 2020 10:25:22 -0500 From: "Salz, Rich" To: Christian Huitema , Tommy Pauly , Erik Nygren CC: Lars Eggert , Mark Nottingham , "IETF QUIC WG" Subject: Re: QUIC re-chartering: include DNS-over-QUIC? Thread-Topic: QUIC re-chartering: include DNS-over-QUIC? Thread-Index: AQHV258Zea7jxOk5qUmVuA7FYYAzPqgMD8GAgAJP+ID//+xTAA== Date: Thu, 6 Feb 2020 15:25:22 +0000 Message-ID: <0285ED2F-4231-4969-AED0-E8303378ADD3@akamai.com> References: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> <367135c9-ea82-9fe7-8d80-a1b47440e2a1@huitema.net> In-Reply-To: <367135c9-ea82-9fe7-8d80-a1b47440e2a1@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200203 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.207] Content-Type: text/plain; charset="utf-8" Content-ID: <2F4198FD94FFA246813B7B96FAFDECD5@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-06_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=681 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002060116 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-06_01:2020-02-06, 2020-02-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 mlxlogscore=661 clxscore=1011 bulkscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 phishscore=0 spamscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002060116 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 15:28:37 -0000 QWdyZWUgdmVyeSBtdWNoIHdpdGggd2hhdCBDaHJpc3RpYW4gd3JvdGUuDQoNCg== From nobody Thu Feb 6 08:13:08 2020 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 B17F112098E for ; Thu, 6 Feb 2020 08:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=oUYfpBze; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=K/pdgqoX 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 cdhYAKjN_ji1 for ; Thu, 6 Feb 2020 08:12:56 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B86120963 for ; Thu, 6 Feb 2020 08:12:56 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B1CD922017 for ; Thu, 6 Feb 2020 11:12:55 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 06 Feb 2020 11:12:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=8gKI0 F2P1QO7Ww8adYkN+tdSvZ4NR1aNyl6357qSYEU=; b=oUYfpBzerkVV8rxOaVHd1 8BMgqMaxf8DvzBr5suusVFUdyIH6GhBsPbwKRCoWyO1gfhx5Fo9/cYFSeTs0yW90 hw6rz1y2L2hBjf35kSFB8MtSohHVQJK5MNyaRh4Wkn2kPmZDXV/lDKN2QZCFQE8p JApp3nZVuwpMqpSBl8a6bmqiJh8HfW3oQUxQsuQSno9OBs6zkCVKzbPADfCRGpJc gf+8hiiKP/y+BZNXKD6TbX7zZ+0ooR8r2H+xt5J2PVGzLJZtloLmJbnAZuczrQ8v Ee7YZYfmP5UsyNysKbcG5jUyeK6QFgov1O8TGifrB9AljTAsvSZzPpzvXi+tiyzS w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=8gKI0F2P1QO7Ww8adYkN+tdSvZ4NR1aNyl6357qSY EU=; b=K/pdgqoXfxYi7oX0ZGr/i9du1qXpCFcvPpPG+YllJBcpJffxSQoOJuAFe b5mR/QfdF7+iUWtju56KEyO8lTTkxu23crfcO9T0N4umY1H2l+2UlUFmH8eoQyoh CjuCeqYqSYgfV8B1LT7coBIB3m9TVhs98H38ul0annQVlpLfC54rZmx1S07101Di yC6ait/OZ4c5k9wM95ADfx9GaW7wqHJb3hAqtybV7qyYqlVGtEniNxio90gJ/b/S HVkMFFbvlq/hRxYHsck4ZxnAFMx6Mn74LdbZBiBAFrm5oG3tGDiZkaauLPTpx2Mm TJ2uIa1s0AHasU8GpYcHXWkAxHMCA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheefgdekhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfies hhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4F92E3C00A1; Thu, 6 Feb 2020 11:12:55 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <978152dc-826c-4af2-9a3e-be553574ebf5@www.fastmail.com> In-Reply-To: References: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> <367135c9-ea82-9fe7-8d80-a1b47440e2a1@huitema.net> Date: Thu, 06 Feb 2020 08:12:35 -0800 From: "Christopher Wood" To: quic@ietf.org Subject: Re: QUIC re-chartering: include DNS-over-QUIC? Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 16:13:07 -0000 On Thu, Feb 6, 2020, at 7:13 AM, Erik Nygren wrote: > It sounds like a good path forwards might be to take the=20 > draft-huitema-quic-dnsoquic=20 > > to dprive in Vancouver and/or Madrid if the authors are interested and= =20 > willing? +1 =E2=80=94 I think taking it to DPRIVE makes sense. Best, Chris >=20 > For encrypting recursive-to-authoritative I'm hopefully that we can=20= > pick one (or at most > two) things as "MTI" for interop, and I suspect if we had a pros/cons=20= > matrix for the various > options that a DoQ solution has a good chance as being the contender=20= > for being the preferred=20 > option for reasons stated above, as well as for other functionality=20= > that exists in QUIC > that may make scaling and robustness easier for authority operators.=20= >=20 > Erik >=20 >=20 >=20 > On Thu, Feb 6, 2020 at 9:57 AM Daniel Migault wr= ote: > > I support DoQ being done here or somewhere else to prevent including= the attack surface of the web platform as well as to have a non HTTP us= e case for quic. I also expect that previous work on DoT, DoH will reduc= e the effort on DoQ. It is true one could question the advantages of hav= ing yet another transport, but on the other hand, it might be better we = can have the choice now rather than later.=20 > > Yours,=20 > > Daniel > >=20 > > On Thu, Feb 6, 2020 at 6:36 AM Christian Huitema > wrote: > >> On 2/4/2020 4:17 PM, Tommy Pauly wrote: > >>=20 > >> > My main question in doing DNS-over-QUIC is what benefit it provi= des > >> > over DNS-over-HTTP/3 (DoH3?). DoH3 seems like a more practical > >> > deployment model, since it allows relatively seamless upgrade fr= om > >> > DoH2 to DoH3, and allows a resolver to support consistent semant= ics on > >> > both. The overhead of the HTTP layer is pretty minimal, and whil= e I > >> > appreciate the desire to define a non-HTTP protocol over QUIC, I= > >> > imagine there would be ones that would be more useful to adopt i= n the > >> > near term. > >>=20 > >> There are significant differences between DoQ and DoH. My main wor= ry is > >> that protocol written to run over HTTP tend to be developed on top= of > >> web platforms, and so you end up bringing the entire attack surfac= e of > >> the web platforms in your DNS implementation. That's OK if your DN= S > >> usage is directly dependent on your web traffic, for example if a > >> browser is sending queries for the pages that it visits. But that'= s not > >> so good for the resolver to authoritative scenario, in which a lea= ner > >> protocol seems safer. > >>=20 > >> But there are other issues. Look at the "M" scenario in the Quic I= nterop > >> runner, loading 2000 small files in parallel. It turns out that se= veral > >> implementations had issues because when doing that they were hitti= ng the > >> OS limit on the number of open files. The way you control that in = Quic > >> is by limiting the number of open streams below the number of file= s that > >> you can maintain open. In a web-oriented implementation of H3 and = Quic, > >> you will most likely do that. But you don't need to worry about th= at in > >> the DNS scenario, because you are certainly not going to write a f= ile > >> for every DNS transaction. Doing an ad hoc application mapping avo= ids > >> this kind of issues. > >>=20 > >> -- Christian Huitema > >>=20 > >>=20 > >>=20 > >=20 > >=20 > > --=20 > > Daniel Migault > > Ericsson From nobody Thu Feb 6 08:46:52 2020 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 2E7C61200F4 for ; Thu, 6 Feb 2020 08:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 MSOxrsBsqRcU for ; Thu, 6 Feb 2020 08:46:48 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 87E8D120073 for ; Thu, 6 Feb 2020 08:46:48 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id f129so812927wmf.2 for ; Thu, 06 Feb 2020 08:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+CtqVTDHC8h+1cf/3qtkY1e/1z9JnOdiG11Fw3gzglY=; b=GkPrh6F2KvUud0TDdy+HasG0yaT9HJQiwMVvhzlPzWNSIB5NPnuZWWgoObiZ+m/gno RVIGuwm8muow9BFfSLEws0rBAgg6ICEaWJoq9k8M8SXn6SDAjhyDJgmqfFmohTZeSvii HHBd6hHcJHA0qQuQFa7DbxRb2LnVMX9cb6asQ6849PGFxWfoxZ+CnOOYFx5T8hnpDpQX wD388v0CCOdvz+v/Ouyyu9E9nl8ACVPSP/LyoDEo30ND3TNWXn4WwhXW5QrVlBLfroyM XGjwBC7u/zrp4j7GSQgd7/kltOWa2mQBZCjHdJMiqNR3ZKlO3yVQIyFt1IAmjwyKauXQ MeLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+CtqVTDHC8h+1cf/3qtkY1e/1z9JnOdiG11Fw3gzglY=; b=ZRJ8lEGYF6YNl1jHDauCtkKdNEdZg+3o2MuRCHMJdm31gO6Ac0APKMW1TpfZeU89HG QOCufkktzkiuhzH9CgmvFRuZnnXafFgfzDhpK6xJhecLbiVtb+K9nP64GaMTu5DY0unA /CUlNELh9InyN18Gdlq9v86XwkHK6j3jpJ84lLdBQ59CdcdcKoCNwhGMG0mt40lrcsY0 SCzf7WdzYEo8QJ0dOtfiHBbPbdQHRKmQqc/3NQa63d0TVXQ2o796PgSSKzkasf/OVfEC lXDxb+5aYxhFsUtfcYbuai3TDNc8f4Dq1XHnLrUvLVh6JjrgE248eRZ6vZsjLLEjKk77 NE2g== X-Gm-Message-State: APjAAAWWBtpJeCkIg9xfTNacCFoBtY845cHZy6TEWgsUEe9CgBTQcZtT KkRHGBqLiqa+UN6Ieu79OilmCt2vSwavAEUnGgkWY/2d+l4= X-Google-Smtp-Source: APXvYqyy/2M+Eo0KsAs0JUtFnT5XCyKSQHFALP9aAw8Iuew4T1NcVdDJ1tlewfru0ruTNmNapqwJ0YCIPK9CZYUZSzM= X-Received: by 2002:a05:600c:21ce:: with SMTP id x14mr5444208wmj.120.1581007606720; Thu, 06 Feb 2020 08:46:46 -0800 (PST) MIME-Version: 1.0 References: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com> <367135c9-ea82-9fe7-8d80-a1b47440e2a1@huitema.net> <978152dc-826c-4af2-9a3e-be553574ebf5@www.fastmail.com> In-Reply-To: <978152dc-826c-4af2-9a3e-be553574ebf5@www.fastmail.com> From: Ian Swett Date: Thu, 6 Feb 2020 11:46:34 -0500 Message-ID: Subject: Re: QUIC re-chartering: include DNS-over-QUIC? To: Christopher Wood Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000c98d80059deb04c9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 16:46:51 -0000 --000000000000c98d80059deb04c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 as well. I think this work is worth doing, and I would hope it does not require the QUIC WG's active involvement. On Thu, Feb 6, 2020 at 11:13 AM Christopher Wood wrote: > > > On Thu, Feb 6, 2020, at 7:13 AM, Erik Nygren wrote: > > It sounds like a good path forwards might be to take the > > draft-huitema-quic-dnsoquic > > > > to dprive in Vancouver and/or Madrid if the authors are interested and > > willing? > > +1 =E2=80=94 I think taking it to DPRIVE makes sense. > > Best, > Chris > > > > > For encrypting recursive-to-authoritative I'm hopefully that we can > > pick one (or at most > > two) things as "MTI" for interop, and I suspect if we had a pros/cons > > matrix for the various > > options that a DoQ solution has a good chance as being the contender > > for being the preferred > > option for reasons stated above, as well as for other functionality > > that exists in QUIC > > that may make scaling and robustness easier for authority operators. > > > > Erik > > > > > > > > On Thu, Feb 6, 2020 at 9:57 AM Daniel Migault > wrote: > > > I support DoQ being done here or somewhere else to prevent including > the attack surface of the web platform as well as to have a non HTTP use > case for quic. I also expect that previous work on DoT, DoH will reduce t= he > effort on DoQ. It is true one could question the advantages of having yet > another transport, but on the other hand, it might be better we can have > the choice now rather than later. > > > Yours, > > > Daniel > > > > > > On Thu, Feb 6, 2020 at 6:36 AM Christian Huitema > wrote: > > >> On 2/4/2020 4:17 PM, Tommy Pauly wrote: > > >> > > >> > My main question in doing DNS-over-QUIC is what benefit it provid= es > > >> > over DNS-over-HTTP/3 (DoH3?). DoH3 seems like a more practical > > >> > deployment model, since it allows relatively seamless upgrade fro= m > > >> > DoH2 to DoH3, and allows a resolver to support consistent > semantics on > > >> > both. The overhead of the HTTP layer is pretty minimal, and while= I > > >> > appreciate the desire to define a non-HTTP protocol over QUIC, I > > >> > imagine there would be ones that would be more useful to adopt in > the > > >> > near term. > > >> > > >> There are significant differences between DoQ and DoH. My main worr= y > is > > >> that protocol written to run over HTTP tend to be developed on top = of > > >> web platforms, and so you end up bringing the entire attack surface > of > > >> the web platforms in your DNS implementation. That's OK if your DNS > > >> usage is directly dependent on your web traffic, for example if a > > >> browser is sending queries for the pages that it visits. But that's > not > > >> so good for the resolver to authoritative scenario, in which a lean= er > > >> protocol seems safer. > > >> > > >> But there are other issues. Look at the "M" scenario in the Quic > Interop > > >> runner, loading 2000 small files in parallel. It turns out that > several > > >> implementations had issues because when doing that they were hittin= g > the > > >> OS limit on the number of open files. The way you control that in > Quic > > >> is by limiting the number of open streams below the number of files > that > > >> you can maintain open. In a web-oriented implementation of H3 and > Quic, > > >> you will most likely do that. But you don't need to worry about tha= t > in > > >> the DNS scenario, because you are certainly not going to write a fi= le > > >> for every DNS transaction. Doing an ad hoc application mapping avoi= ds > > >> this kind of issues. > > >> > > >> -- Christian Huitema > > >> > > >> > > >> > > > > > > > > > -- > > > Daniel Migault > > > Ericsson > > --000000000000c98d80059deb04c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 as well.=C2=A0 I think this work is worth doing, and I = would hope it does not require the QUIC WG's active involvement.

On = Thu, Feb 6, 2020 at 11:13 AM Christopher Wood <caw@heapingbits.net> wrote:


On Thu, Feb 6, 2020, at 7:13 AM, Erik Nygren wrote:
> It sounds like a good path forwards might be to take the
> draft-huitema-quic-dnsoquic
> <https://tools.ietf.org/html/draft= -huitema-quic-dnsoquic-07>
> to dprive in Vancouver and/or Madrid if the authors are interested and=
> willing?

+1 =E2=80=94 I think taking it to DPRIVE makes sense.

Best,
Chris

>
> For encrypting recursive-to-authoritative I'm hopefully that we ca= n
> pick one (or at most
> two) things as "MTI" for interop, and I suspect if we had a = pros/cons
> matrix for the various
> options that a DoQ solution has a good chance as being the contender <= br> > for being the preferred
> option for reasons stated above, as well as for other functionality > that exists in QUIC
> that may make scaling and robustness easier for authority operators. <= br> >
>=C2=A0 Erik
>
>
>
> On Thu, Feb 6, 2020 at 9:57 AM Daniel Migault <mglt.ietf@gmail.com> wrote:
> > I support DoQ being done here or somewhere else to prevent includ= ing the attack surface of the web platform as well as to have a non HTTP us= e case for quic. I also expect that previous work on DoT, DoH will reduce t= he effort on DoQ. It is true one could question the advantages of having ye= t another transport, but on the other hand, it might be better we can have = the choice now rather than later.
> > Yours,
> > Daniel
> >
> > On Thu, Feb 6, 2020 at 6:36 AM Christian Huitema <huitema@huitema.net <ma= ilto:huitema@huitema.= .net>> wrote:
> >> On 2/4/2020 4:17 PM, Tommy Pauly wrote:
> >>
> >>=C2=A0 > My main question in doing DNS-over-QUIC is what be= nefit it provides
> >>=C2=A0 > over DNS-over-HTTP/3 (DoH3?). DoH3 seems like a mo= re practical
> >>=C2=A0 > deployment model, since it allows relatively seaml= ess upgrade from
> >>=C2=A0 > DoH2 to DoH3, and allows a resolver to support con= sistent semantics on
> >>=C2=A0 > both. The overhead of the HTTP layer is pretty min= imal, and while I
> >>=C2=A0 > appreciate the desire to define a non-HTTP protoco= l over QUIC, I
> >>=C2=A0 > imagine there would be ones that would be more use= ful to adopt in the
> >>=C2=A0 > near term.
> >>
> >>=C2=A0 There are significant differences between DoQ and DoH. = My main worry is
> >>=C2=A0 that protocol written to run over HTTP tend to be devel= oped on top of
> >>=C2=A0 web platforms, and so you end up bringing the entire at= tack surface of
> >>=C2=A0 the web platforms in your DNS implementation. That'= s OK if your DNS
> >>=C2=A0 usage is directly dependent on your web traffic, for ex= ample if a
> >>=C2=A0 browser is sending queries for the pages that it visits= . But that's not
> >>=C2=A0 so good for the resolver to authoritative scenario, in = which a leaner
> >>=C2=A0 protocol seems safer.
> >>
> >>=C2=A0 But there are other issues. Look at the "M" s= cenario in the Quic Interop
> >>=C2=A0 runner, loading 2000 small files in parallel. It turns = out that several
> >>=C2=A0 implementations had issues because when doing that they= were hitting the
> >>=C2=A0 OS limit on the number of open files. The way you contr= ol that in Quic
> >>=C2=A0 is by limiting the number of open streams below the num= ber of files that
> >>=C2=A0 you can maintain open. In a web-oriented implementation= of H3 and Quic,
> >>=C2=A0 you will most likely do that. But you don't need to= worry about that in
> >>=C2=A0 the DNS scenario, because you are certainly not going t= o write a file
> >>=C2=A0 for every DNS transaction. Doing an ad hoc application = mapping avoids
> >>=C2=A0 this kind of issues.
> >>
> >>=C2=A0 -- Christian Huitema
> >>
> >>
> >>
> >
> >
> > --
> > Daniel Migault
> > Ericsson

--000000000000c98d80059deb04c9-- From nobody Thu Feb 6 09:26:58 2020 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 A1F6F12010D for ; Thu, 6 Feb 2020 09:26:56 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 6mzdm0JsTaYn for ; Thu, 6 Feb 2020 09:26:54 -0800 (PST) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 8D4C3120108 for ; Thu, 6 Feb 2020 09:26:54 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id 016H7j4O053014; Thu, 6 Feb 2020 09:26:49 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=MD8M7rke5q/vsddfwf5GV8u3gCeGQ8radpCXsGBYK9s=; b=AXAy2XV7xuSiw32nrO7C8rUcnQYM/bBZWwm2WrbB3tnzlWHx4tXVl6b88Dv4VUo7Ra2r Wu08EZb3lTg3gE2qr56MWXywRJk+Tw0R90YOso2gf4eHVaukahitMUDw8kBkNDJRHqUI rsxgCTbu+/vao5yGiSe6Z5d5jZKvEYCwEkPuPr7/qK1pA2Wi/yEMjIR4l1/ajb+NsGrN +o+UBIPldcMDkpSOCWQbVSUz42LQIuLf0PU69lQhQLj5wKWQgzLovY3enGXky0b6JURX n7v9KL93+Nf9slxj+ooz702MIez6U4bMa2asJjS7DCYZZeA47j2Y2rd5QQaIQzBs3H9f 3Q== Received: from ma-mailsvcp-mta-lapp02.corp.apple.com (ma-mailsvcp-mta-lapp02.corp.apple.com [10.226.18.134]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2xykayw41r-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 06 Feb 2020 09:26:49 -0800 Received: from ma-mailsvcp-mmp-lapp01.apple.com (ma-mailsvcp-mmp-lapp01.apple.com [17.32.222.14]) by ma-mailsvcp-mta-lapp02.corp.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q5A008J5J4OPLB0@ma-mailsvcp-mta-lapp02.corp.apple.com>; Thu, 06 Feb 2020 09:26:48 -0800 (PST) Received: from process_milters-daemon.ma-mailsvcp-mmp-lapp01.apple.com by ma-mailsvcp-mmp-lapp01.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) id <0Q5A00Z00J45AY00@ma-mailsvcp-mmp-lapp01.apple.com>; Thu, 06 Feb 2020 09:26:48 -0800 (PST) X-Va-A: X-Va-T-CD: c8b10700d71aad692d44400dd5e552ae X-Va-E-CD: 50ace2a2c7a519dfea16dd2e6ff08205 X-Va-R-CD: 5ea96b195aba36741a99102bfdbc7bae X-Va-CD: 0 X-Va-ID: a6f08016-7121-4948-91c5-5d0373c624a9 X-V-A: X-V-T-CD: c8b10700d71aad692d44400dd5e552ae X-V-E-CD: 50ace2a2c7a519dfea16dd2e6ff08205 X-V-R-CD: 5ea96b195aba36741a99102bfdbc7bae X-V-CD: 0 X-V-ID: 4154a14e-7bb7-4cc6-a991-22429a778c7a X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-06_01:2020-02-06, 2020-02-06 signatures=0 Received: from [17.234.226.103] (unknown [17.234.226.103]) by ma-mailsvcp-mmp-lapp01.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPSA id <0Q5A00TAYJ4MJW40@ma-mailsvcp-mmp-lapp01.apple.com>; Thu, 06 Feb 2020 09:26:48 -0800 (PST) Sender: vidhi_goel@apple.com Content-type: multipart/alternative; boundary=Apple-Mail-96067D01-E527-420D-B44A-74DA983293B3 Content-transfer-encoding: 7bit From: Vidhi Goel MIME-version: 1.0 (1.0) Subject: Re: QUIC re-chartering: include DNS-over-QUIC? Date: Thu, 06 Feb 2020 09:26:46 -0800 Message-id: <69F63EAA-B7AB-4874-9AD5-7C8F98A92C77@apple.com> References: Cc: Christopher Wood , IETF QUIC WG In-reply-to: To: Ian Swett X-Mailer: iPhone Mail (18A195a) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-06_01:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 17:26:57 -0000 --Apple-Mail-96067D01-E527-420D-B44A-74DA983293B3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I support DoQ for the use cases that are based on non HTTP application proto= col. DoQ implicitly provides benefits of QUIC which DoT doesn=E2=80=99t have= . Vidhi > On Feb 6, 2020, at 8:47 AM, Ian Swett wrote: >=20 > =EF=BB=BF > +1 as well. I think this work is worth doing, and I would hope it does no= t require the QUIC WG's active involvement. >=20 >> On Thu, Feb 6, 2020 at 11:13 AM Christopher Wood wr= ote: >>=20 >>=20 >> On Thu, Feb 6, 2020, at 7:13 AM, Erik Nygren wrote: >> > It sounds like a good path forwards might be to take the=20 >> > draft-huitema-quic-dnsoquic=20 >> > >> > to dprive in Vancouver and/or Madrid if the authors are interested and=20= >> > willing? >>=20 >> +1 =E2=80=94 I think taking it to DPRIVE makes sense. >>=20 >> Best, >> Chris >>=20 >> >=20 >> > For encrypting recursive-to-authoritative I'm hopefully that we can=20 >> > pick one (or at most >> > two) things as "MTI" for interop, and I suspect if we had a pros/cons=20= >> > matrix for the various >> > options that a DoQ solution has a good chance as being the contender=20= >> > for being the preferred=20 >> > option for reasons stated above, as well as for other functionality=20 >> > that exists in QUIC >> > that may make scaling and robustness easier for authority operators.=20= >> >=20 >> > Erik >> >=20 >> >=20 >> >=20 >> > On Thu, Feb 6, 2020 at 9:57 AM Daniel Migault wro= te: >> > > I support DoQ being done here or somewhere else to prevent including t= he attack surface of the web platform as well as to have a non HTTP use case= for quic. I also expect that previous work on DoT, DoH will reduce the effo= rt on DoQ. It is true one could question the advantages of having yet anothe= r transport, but on the other hand, it might be better we can have the choic= e now rather than later.=20 >> > > Yours,=20 >> > > Daniel >> > >=20 >> > > On Thu, Feb 6, 2020 at 6:36 AM Christian Huitema > wrote: >> > >> On 2/4/2020 4:17 PM, Tommy Pauly wrote: >> > >>=20 >> > >> > My main question in doing DNS-over-QUIC is what benefit it provid= es >> > >> > over DNS-over-HTTP/3 (DoH3?). DoH3 seems like a more practical >> > >> > deployment model, since it allows relatively seamless upgrade fro= m >> > >> > DoH2 to DoH3, and allows a resolver to support consistent semanti= cs on >> > >> > both. The overhead of the HTTP layer is pretty minimal, and while= I >> > >> > appreciate the desire to define a non-HTTP protocol over QUIC, I >> > >> > imagine there would be ones that would be more useful to adopt in= the >> > >> > near term. >> > >>=20 >> > >> There are significant differences between DoQ and DoH. My main worr= y is >> > >> that protocol written to run over HTTP tend to be developed on top o= f >> > >> web platforms, and so you end up bringing the entire attack surface= of >> > >> the web platforms in your DNS implementation. That's OK if your DNS= >> > >> usage is directly dependent on your web traffic, for example if a >> > >> browser is sending queries for the pages that it visits.. But that'= s not >> > >> so good for the resolver to authoritative scenario, in which a lean= er >> > >> protocol seems safer. >> > >>=20 >> > >> But there are other issues. Look at the "M" scenario in the Quic In= terop >> > >> runner, loading 2000 small files in parallel. It turns out that sev= eral >> > >> implementations had issues because when doing that they were hittin= g the >> > >> OS limit on the number of open files. The way you control that in Q= uic >> > >> is by limiting the number of open streams below the number of files= that >> > >> you can maintain open. In a web-oriented implementation of H3 and Q= uic, >> > >> you will most likely do that. But you don't need to worry about tha= t in >> > >> the DNS scenario, because you are certainly not going to write a fi= le >> > >> for every DNS transaction. Doing an ad hoc application mapping avoi= ds >> > >> this kind of issues. >> > >>=20 >> > >> -- Christian Huitema >> > >>=20 >> > >>=20 >> > >>=20 >> > >=20 >> > >=20 >> > > --=20 >> > > Daniel Migault >> > > Ericsson >>=20 --Apple-Mail-96067D01-E527-420D-B44A-74DA983293B3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I support DoQ for the use cases that are ba= sed on non HTTP application protocol. DoQ implicitly provides benefits of QU= IC which DoT doesn=E2=80=99t have.

Vidhi

On Feb 6, 2020, at 8:47 AM, Ian Swe= tt <ianswett=3D40google.com@dmarc.ietf.org> wrote:

=EF=BB=BF
= +1 as well.  I think this work is worth doing, and I would hope it does= not require the QUIC WG's active involvement.

On Thu, Feb 6, 2020 at 11:1= 3 AM Christopher Wood <caw@heaping= bits.net> wrote:


On Thu, Feb 6, 2020, at 7:13 AM, Erik Nygren wrote:
> It sounds like a good path forwards might be to take the
> draft-huitema-quic-dnsoquic
> <https://tools.ietf.org/html/draft-h= uitema-quic-dnsoquic-07>
> to dprive in Vancouver and/or Madrid if the authors are interested and <= br> > willing?

+1 =E2=80=94 I think taking it to DPRIVE makes sense.

Best,
Chris

>
> For encrypting recursive-to-authoritative I'm hopefully that we can > pick one (or at most
> two) things as "MTI" for interop, and I suspect if we had a pros/cons <= br> > matrix for the various
> options that a DoQ solution has a good chance as being the contender > for being the preferred
> option for reasons stated above, as well as for other functionality > that exists in QUIC
> that may make scaling and robustness easier for authority operators. >
>  Erik
>
>
>
> On Thu, Feb 6, 2020 at 9:57 AM Daniel Migault <mglt.ietf@gmail.com> wrote:
> > I support DoQ being done here or somewhere else to prevent includi= ng the attack surface of the web platform as well as to have a non HTTP use c= ase for quic. I also expect that previous work on DoT, DoH will reduce the e= ffort on DoQ. It is true one could question the advantages of having yet ano= ther transport, but on the other hand, it might be better we can have the ch= oice now rather than later.
> > Yours,
> > Daniel
> >
> > On Thu, Feb 6, 2020 at 6:36 AM Christian Huitema <huitema@huitema.net <mail= to:huitema@huitema..net>> wrote:
> >> On 2/4/2020 4:17 PM, Tommy Pauly wrote:
> >>
> >>  > My main question in doing DNS-over-QUIC is what ben= efit it provides
> >>  > over DNS-over-HTTP/3 (DoH3?). DoH3 seems like a mor= e practical
> >>  > deployment model, since it allows relatively seamle= ss upgrade from
> >>  > DoH2 to DoH3, and allows a resolver to support cons= istent semantics on
> >>  > both. The overhead of the HTTP layer is pretty mini= mal, and while I
> >>  > appreciate the desire to define a non-HTTP protocol= over QUIC, I
> >>  > imagine there would be ones that would be more usef= ul to adopt in the
> >>  > near term.
> >>
> >>  There are significant differences between DoQ and DoH. M= y main worry is
> >>  that protocol written to run over HTTP tend to be develo= ped on top of
> >>  web platforms, and so you end up bringing the entire att= ack surface of
> >>  the web platforms in your DNS implementation. That's OK i= f your DNS
> >>  usage is directly dependent on your web traffic, for exa= mple if a
> >>  browser is sending queries for the pages that it visits.= . But that's not
> >>  so good for the resolver to authoritative scenario, in w= hich a leaner
> >>  protocol seems safer.
> >>
> >>  But there are other issues. Look at the "M" scenario in t= he Quic Interop
> >>  runner, loading 2000 small files in parallel. It turns o= ut that several
> >>  implementations had issues because when doing that they w= ere hitting the
> >>  OS limit on the number of open files. The way you contro= l that in Quic
> >>  is by limiting the number of open streams below the numb= er of files that
> >>  you can maintain open. In a web-oriented implementation o= f H3 and Quic,
> >>  you will most likely do that. But you don't need to worr= y about that in
> >>  the DNS scenario, because you are certainly not going to= write a file
> >>  for every DNS transaction. Doing an ad hoc application m= apping avoids
> >>  this kind of issues.
> >>
> >>  -- Christian Huitema
> >>
> >>
> >>
> >
> >
> > --
> > Daniel Migault
> > Ericsson

= --Apple-Mail-96067D01-E527-420D-B44A-74DA983293B3-- From nobody Thu Feb 6 13:16:52 2020 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 96268120147 for ; Thu, 6 Feb 2020 13:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 InlQ_IIR6Ezi for ; Thu, 6 Feb 2020 13:16:48 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552441200E5 for ; Thu, 6 Feb 2020 13:16:48 -0800 (PST) Received: from [10.0.10.241] (unknown [80.146.187.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 00610B0591; Thu, 6 Feb 2020 21:16:45 +0000 (UTC) Subject: Re: QUIC re-chartering: include DNS-over-QUIC? To: Vidhi Goel Cc: Ian Swett , IETF QUIC WG , Christopher Wood References: <69F63EAA-B7AB-4874-9AD5-7C8F98A92C77@apple.com> From: Paul Vixie Message-ID: Date: Thu, 6 Feb 2020 22:16:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.11 MIME-Version: 1.0 In-Reply-To: <69F63EAA-B7AB-4874-9AD5-7C8F98A92C77@apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 21:16:49 -0000 Vidhi Goel wrote on 2020-02-06 18:26: > I support DoQ for the use cases that are based on non HTTP application > protocol. DoQ implicitly provides benefits of QUIC which DoT doesn’t have. i fear this may be off-topic for this mailing list; in which case, just tell me. i've been watching this thread carefully, and i think the concern about too many dns transports with no possible guidance to developers as to which one to try in what order. as a server operator i expect to have to support everything, which means arguments about threat surface in one transport vs. another are effectively null. i can definitely see why the QUIC team might want more than one proof, it would help assure us all that there aren't HTTP assumptions designed in. and all of the reasons i never pushed for DNS over DTLS or DNS over SCTP are certainly addressed by DNS over QUIC. however, my reasons for not pushing DNS over DTLS or DNS over SCTP are also addressed by DoT. i'd be grateful if you could explain what problems you think DoT has, which would beg us to invent another DNS transport profile such as DNS over QUIC. i see DoQ as nec'y for QUIC's success but not relevant to DNS beyond the fact that DNS is a convenient second example of how QUIC can be used. if there are use cases or failure modes not handled well by DoT, i'd like to learn more about those. -- P Vixie From nobody Thu Feb 6 13:27:30 2020 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 2EBE6120289 for ; Thu, 6 Feb 2020 13:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 1kNKU24_SYbl for ; Thu, 6 Feb 2020 13:27:27 -0800 (PST) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 A07B1120111 for ; Thu, 6 Feb 2020 13:27:27 -0800 (PST) Received: by mail-wm1-f49.google.com with SMTP id a5so465923wmb.0 for ; Thu, 06 Feb 2020 13:27:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oUe6KaPWwi+1exZsnkuzDumfOo2eJJpcW7FiFLzqrIM=; b=pU5b4W54EWHexpAl9E77t405ObR4ljq4GKvsAC2whisOVrFHtgSiVORPRUhNA5gQmU VWfAVz/y/35EncMyhikm8ygJuKlzpNIk2iW3an+dbWQaETNgxczi/XCQp1zOB0ul79f1 eWFCqMyxLsb4lT5Hs6qPSYzZnVF7y2K5IP0VRK7X8i9r+WIUQbmxSLivVHWw1JFEf1Ig MXS439oEULOPy+joCgTJGKoduie8ZKCRa5ZsiKSZQaWBDTo5GIM4jqbI5vE4u+0HuEPy rsCHbbHBXZblYwLXEhUt7mGgkg8hDJvjl3EWpB7Kux7AR97jGS33lB8BSvD0fMhckQOO joEg== X-Gm-Message-State: APjAAAUO9h3+DBQKMICUZ0bQv6pafeT040R9aXUmIUkFMcEYe6+1KnA9 TwrQhwMomj+7uxiJFZiDm9svrNG286Q+gW8pvmc= X-Google-Smtp-Source: APXvYqyinWQTHoBYHOlyaf9ACfknOEnhLqgbCr+K8HlXC7feHofWjkhCNw5igFHIvFxakuzAmgUs8yTXS/qadW+q2l4= X-Received: by 2002:a1c:7406:: with SMTP id p6mr7023051wmc.82.1581024445851; Thu, 06 Feb 2020 13:27:25 -0800 (PST) MIME-Version: 1.0 References: <69F63EAA-B7AB-4874-9AD5-7C8F98A92C77@apple.com> In-Reply-To: From: Erik Nygren Date: Thu, 6 Feb 2020 16:27:14 -0500 Message-ID: Subject: Re: QUIC re-chartering: include DNS-over-QUIC? To: Paul Vixie Cc: Vidhi Goel , IETF QUIC WG , Christopher Wood , Ian Swett Content-Type: multipart/alternative; boundary="00000000000079edb4059deef018" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 21:27:29 -0000 --00000000000079edb4059deef018 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 6, 2020 at 4:16 PM Paul Vixie wrote: > i see DoQ as nec'y for QUIC's success but not relevant to DNS beyond the > fact that DNS is a convenient second example of how QUIC can be used. if > there are use cases or failure modes not handled well by DoT, i'd like > to learn more about those. > Some possible reasons (not comprehensive): * Reduce the impact of head-of-line blocking during loss. If packets are lost, only the request(s) associated with the loss are impacted. * Faster resumption and 0RTT behaviors (although you get some of these with TFO + TLS 1.3 0RTT). But this substantially reduces the performance impact when new connections need to be established. * The previous also means servers can be more aggressive about timing out connections to reduce the state they need to keep, but while minimizing perf impact, which can be critical at-scale. * Better ability for load balancers at-scale to do creative things, including being able to recover better when Anycast moves routes between data centers. (The server-supplied Connection ID means that options become available to better recover without needing to reset re-establish connections and without needing to share state between clusters.) * QUIC provides a framework for future extensions that may be useful in the DNS space. For example, FEC might actually be useful for DNS in some cases. I'm sure there are plenty more reasons... Erik --00000000000079edb4059deef018 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 6, 2020 at 4:16 PM Paul Vixie <paul@redbarn.org> wrote:
i see DoQ as nec'y for QUIC's success but not relevant to DNS beyon= d the
fact that DNS is a convenient second example of how QUIC can be used. if there are use cases or failure modes not handled well by DoT, i'd like =
to learn more about those.

Some possible reasons (= not comprehensive):

* Reduce the impact of head-of-line = blocking during loss.=C2=A0 If packets are lost, only the request(s) associ= ated with the loss are impacted.
* Faster resumption and 0RTT behaviors (alt= hough you get some of these with TFO + TLS 1.3 0RTT).=C2=A0 But this substa= ntially reduces the performance impact when new connections need to be esta= blished.
* The previous also means servers can be more aggressive about timi= ng out connections to reduce the state they need to keep, but while minimiz= ing perf impact, which can be critical at-scale.
* Better ability for lo= ad balancers at-scale to do creative things, including being able to recove= r better when Anycast moves routes between data centers.=C2=A0 (The server-= supplied Connection ID means that options become available to better recove= r without needing to reset re-establish connections and without needing to = share state between clusters.)
* QUIC provides a framework for future extens= ions that may be useful in the DNS space.=C2=A0 For example, FEC might actu= ally be useful for DNS in some cases.

I'm sure= there are plenty more reasons...

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

--00000000000079edb4059deef018-- From nobody Thu Feb 6 14:12:25 2020 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 9C187120819 for ; Thu, 6 Feb 2020 14:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 nNquS9d63oFW for ; Thu, 6 Feb 2020 14:12:21 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::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 D9DBB120111 for ; Thu, 6 Feb 2020 14:12:20 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id a142so10191oii.7 for ; Thu, 06 Feb 2020 14:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xFwtAtNDbz4k9yzGl5o4YLnNW9OqLy+qXAU3eyxQSjg=; b=irIr53j+BAmbYvy/ZMNVXj92s/248+ig/c+Rwp7ZIU6IVXPsiM+fxS5CKXx+KUu6gM 7huiBSHdKJIhtsNbpozBj+A0kz19lJ4KdcnPGmmNWf8C3+aNci3402omK7fWGFPdOo2D OEszf6K19N7jp6X2CXL2s576xEoB+wB8Dz2BuV7xJkLPcc/zsmjBggVPYEkPSjb6vHF1 34+keuSy0Kgw0ietsrkBCcVMW9LwrE3Jlj4rMVcb8883cSQL3he9pRzqvUhSnCsFZ5qj T2EfctWojJ4G8Ym/8BI4zSv9eHDetguRk2Zd8MGrFPUT/1vz1EFzZkLO3M0y3nhKo3ME RQ4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xFwtAtNDbz4k9yzGl5o4YLnNW9OqLy+qXAU3eyxQSjg=; b=HuANhd0+BALGXk9+vTwooHHc+Joy0c0jR8TieFensBvujF8yov7PmrOaSqv/AO52EW RRwuPqKvj4ULGA2EDsLKIsQ9U7kEUnC2gtH/bEIb7am6X0z/shZQxMZrV65R1YKVrHIN WBusdBRhuVYhFVmjB36v5vWGJNGpAGyCoLwoz0qvO52pnz6+h/FFxd0rLtgCvmRCA+cH w0BlLShTxMI++Zr/lxgmEXVSW6hvtUmbMbrLzz2AdP1bKJIGlaajTlUzwJD93sM3RCeO 5+sETjCve0XQrfbTMqcv9N9NJ1dykMaauNIK1ckHQ4zKOc0jBcypjWh+04v/DeLYxSCO 0dQw== X-Gm-Message-State: APjAAAXKxUUxtbEdLx5z+Kcz2tUZiVoxoWkosUgV654dw/OO82gtltA1 QBKOYKMdtpw2KNqa4xCQ0oOWFFKkaeg2GWdHui8= X-Google-Smtp-Source: APXvYqwgcqUnRt9JfZ3pd2SmhVaJfv98BrUfLUd8K2amDMGm43gSZ6NJJzPc21Y6c7wGRcQhoHoxYzP1K+99ZKog5P4= X-Received: by 2002:aca:b187:: with SMTP id a129mr95260oif.175.1581027140167; Thu, 06 Feb 2020 14:12:20 -0800 (PST) MIME-Version: 1.0 References: <69F63EAA-B7AB-4874-9AD5-7C8F98A92C77@apple.com> In-Reply-To: From: Erik Kline Date: Thu, 6 Feb 2020 14:12:09 -0800 Message-ID: Subject: Re: QUIC re-chartering: include DNS-over-QUIC? To: Paul Vixie Cc: Vidhi Goel , IETF QUIC WG , Christopher Wood , Ian Swett Content-Type: multipart/alternative; boundary="00000000000011ebcf059def911a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 22:12:24 -0000 --00000000000011ebcf059def911a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 6, 2020 at 1:17 PM Paul Vixie wrote: > > > Vidhi Goel wrote on 2020-02-06 18:26: > > I support DoQ for the use cases that are based on non HTTP application > > protocol. DoQ implicitly provides benefits of QUIC which DoT doesn=E2= =80=99t > have. > > i fear this may be off-topic for this mailing list; in which case, just > tell me. i've been watching this thread carefully, and i think the > concern about too many dns transports with no possible guidance to > developers as to which one to try in what order. > I think the add charter might be aiming to address the advice to clients concern (https://datatracker.ietf.org/doc/charter-ietf-add/). --00000000000011ebcf059def911a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 6, 2020 at 1:17 PM Paul V= ixie <paul@redbarn.org> wrote= :


Vidhi Goel wrote on 2020-02-06 18:26:
> I support DoQ for the use cases that are based on non HTTP application=
> protocol. DoQ implicitly provides benefits of QUIC which DoT doesn=E2= =80=99t have.

i fear this may be off-topic for this mailing list; in which case, just tell me. i've been watching this thread carefully, and i think the
concern about too many dns transports with no possible guidance to
developers as to which one to try in what order.

<= /div>
I think the add charter might be aiming to address the advice to = clients concern (https://datatracker.ietf.org/doc/charter-ietf-add/).
--00000000000011ebcf059def911a-- From nobody Fri Feb 7 09:16:08 2020 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 D478F12084E; Fri, 7 Feb 2020 09:15:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" Subject: WG Review: QUIC (quic) X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Cc: quic@ietf.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158109575881.11589.7522751407809468206.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 09:15:58 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 17:15:59 -0000 The QUIC (quic) WG in the Transport Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-02-17. QUIC (quic) ----------------------------------------------------------------------- Current status: Active WG Chairs: Mark Nottingham Lars Eggert Lucas Pardue Assigned Area Director: Magnus Westerlund Transport Area Directors: Mirja Kühlewind Magnus Westerlund Mailing list: Address: quic@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/quic Archive: https://mailarchive.ietf.org/arch/browse/quic/ Group page: https://datatracker.ietf.org/group/quic/ Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/ The QUIC working group will provide standards-track specifications for a UDP-based, stream-multiplexing, encrypted transport protocol, based on pre-standardization implementation and deployment experience. Key goals for QUIC are: - Minimizing connection establishment and overall transport latency for applications, starting with HTTP; - Providing multiplexing without head-of-line blocking; - Requiring only changes to path endpoints to enable deployment; - Enabling multipath and forward error correction extensions; and - Providing always-secure transport, using TLS 1.3 by default. The work of the group will have five main focus areas, corresponding to five core deliverables. 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 options negotiation. Work on congestion control will describe use of a standardized congestion controller as a default scheme for QUIC. Defining new congestion control schemes is explicitly out of scope for this group. QUIC is expected to support rapid, distributed development and testing of features. The second of these focus areas is security. This work will describe how the protocol uses TLS 1.3 for key negotiation and will also describe how those keys are used to provide confidentiality and integrity protection of both application data and QUIC headers. This work will ensure that QUIC has security and privacy properties that are at least as good as a stack composed of TLS 1.3 using TCP (or MPTCP when using multipath). The third focus area describes the mapping between the HTTP application protocol and the transport facilities of QUIC. This mapping will have performance characteristics comparable with HTTP/2, and provide extension mechanisms similar to HTTP/2. Upon completion of this mapping, work to define additional mappings may be included by updates to this charter, or may be worked on by other working groups. The fourth focus area will be on extensions to core protocol facilities, to enable datagram delivery, version negotiation, and multipath capabilities. Other extensions are out of the scope of this charter. The fifth focus area will provide an Applicability and Manageability Statement, describing how, and under what circumstances, QUIC may be safely used, and describing deployment and manageability implications of the protocol. Additionally, the Working Group will provide guidance on how to handle QUIC traffic in load balancers. Current practices for network management of transport protocols include the ability to apply access control lists (ACLs), hashing of flows for equal-cost multipath routing (ECMP), directional signaling of flows, signaling of flow setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each of these abilities, or enable them in the same way as they are enabled by TCP when used with TLS 1.3, but the working group must consider the impact of the protocol on network management practices, reflecting the tensions described in RFC 7258. 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. The QUIC working group will work closely with the HTTPbis working group, especially on the QUIC mapping for HTTP. Milestones: Jul 2020 - Core Protocol document to IESG Jul 2020 - Loss detection and Congestion Control document to IESG Jul 2020 - TLS 1.3 Mapping document to IESG Jul 2020 - HTTP/2 mapping document to IESG Jul 2020 - QUIC Applicability and Manageability Statement to IESG Jul 2020 - Version-Independent Properties of QUIC to IESG Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG Dec 2020 - Working group adoption of Multipath extension document Mar 2021 - Datagram Extension to IESG Mar 2021 - Version Negotiation Extension to IESG Dec 2021 - Multipath extension document to IESG From nobody Fri Feb 7 15:03:47 2020 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 CA2451200FE for ; Fri, 7 Feb 2020 15:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 23h5oyqbksdI for ; Fri, 7 Feb 2020 15:03:44 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 2CB931200FA for ; Fri, 7 Feb 2020 15:03:44 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id t23so4172960wmi.1 for ; Fri, 07 Feb 2020 15:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=3+e/90KCcbAePAz9mYYfPmR/H907DOGEJrghCRhUbuY=; b=ChSRO6c6xheICoTeSQ9VMOp7Wc8OLemmq1nhDWaQKdlfez2LTAjxEC1s8WtWOzWfVB M5YWY7GGoSKV0EktyQh5j+r1ikiUlKyM/oX4CTYOGumCvQ6A9xn2Q9QhMUzusLwJUc4r Q9jksCzvKBJBKJLhb6GD0+hm2Xpc1pRVVq23gHgyQc7UC5SfXhkwgixztfEF6Etjk/5X QgqzI0gUxX23zPpNVqRPF5KZuxvxlLUyotiEHZwpH9R2ZM7MHuaqXFZ74eGNRqnFHBzP rxh5NPoaiPAlVBQgHA5e79H/e1KqLerjahb8C7CQV3+1i3TNZJt+o7gjJplMoWV4WMO0 bH5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=3+e/90KCcbAePAz9mYYfPmR/H907DOGEJrghCRhUbuY=; b=fkBw04pFMCLLvJcfLrwZEW55zwGkn86U+SI1mKTwjHqqcQl/pjVlDdcR71a8ulNhoS vZKZwJk16viwsTgGAktlsFlBNNSBE6dWZC5Ubs968Noe4ONlszdsy625gvhdSQAto+Vx 8qhyrYZJ0MAqS9SUfulrtbCOCkmeuTsDidxNqIKAJ1UPh9S/hiYVd2QucN3wONCE8cwp 5xdp/6wTao/c7jbdy+IulqTKME/DDnfNBqpLOD035uCiZvMAy+ba51JGVl8axKIctfyu BHzw8Xpg9II3oxYZ4RADFZfDujY0SLpiCgA5z+pRIPRjaLiQNpIaIpY5k6zEqtbzQRql jnbw== X-Gm-Message-State: APjAAAW4JaLtS1DCIWEr1c2iUcqARlfLBSnn2B0jXffqeqb+9VGdVXCf mD/kk88wNEom6XE0HeysZ+PaJoAn9dGOydbXhgFzjkb4uhc= X-Google-Smtp-Source: APXvYqxG2Np3aeP/qwCccFDL8WkmMiFP2YV83ZfdZEqqCUqE09khFM9w/yA8qF029+MWqOA2qOXdQ6TyRwYn20gBGpg= X-Received: by 2002:a05:600c:d5:: with SMTP id u21mr556833wmm.98.1581116622392; Fri, 07 Feb 2020 15:03:42 -0800 (PST) MIME-Version: 1.0 From: Lucas Pardue Date: Fri, 7 Feb 2020 23:03:31 +0000 Message-ID: Subject: DRAFT minutes for the Zurich interim To: QUIC WG Cc: Mark Nottingham , Lars Eggert Content-Type: multipart/alternative; boundary="000000000000a0534c059e046613" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 23:03:46 -0000 --000000000000a0534c059e046613 Content-Type: text/plain; charset="UTF-8" ... are available at: https://github.com/quicwg/wg-materials/blob/master/interim-20-02/minutes.md As always, corrections appreciated, either as Pull Requests or e-mail. Thanks again to our scribes and hosts. Lucas --000000000000a0534c059e046613 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
... are available at:
https://= github.com/quicwg/wg-materials/blob/master/interim-20-02/minutes.md

As always, corrections appreciated, either as Pull Re= quests or e-mail.

Thanks again to our scribes and = hosts.

Lucas
--000000000000a0534c059e046613-- From nobody Sat Feb 8 23:32:42 2020 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 9FFEA1200D5 for ; Sat, 8 Feb 2020 23:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=zjM9aEXp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3LyQvvMl 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 1S8giHuWctjN for ; Sat, 8 Feb 2020 23:32:36 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D461200B3 for ; Sat, 8 Feb 2020 23:32:35 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5C0A121E1C for ; Sun, 9 Feb 2020 02:32:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 09 Feb 2020 02:32:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=PlQTayYFpRQZpUDtxPwRxh/3KK1KWnIAVtCwkcCIafM=; b=zjM9aEXp /UBBc6zzv6iumBI13cagHwEIvJsudPZyTIuDBm+EXTYs5StpBJECR9Xa4+2h0fm3 ViyvpNqpVgrv0UwXcoTHxY5FmQ2pCHv7eVKVfubPFZgTXqwZp82Ve6rHrSfsvWDn NEV7bUurzaYJuF+a8Th+OZQcnsMWee2M1IuoVx/OjIEFOcn+INcOzgP8XvYStBq7 +OFAeJtRk3si0T9vMrDvU7l6jCBlywRc+B4mDGsaOQUo+ioMrFhI+WnJFTE0EIqE gAbUoKqbE53Jjp7QAOnHbp31UrCersHWT4dTud5yV2CoD0QyJWphe9mqtIQKX+4l 9mLm51Y/5mHALw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=PlQTayYFpRQZpUDtxPwRxh/3KK1KW nIAVtCwkcCIafM=; b=3LyQvvMlg/Q+ec2QF0YGZFQND6NWpoifDn5Tgr6lkaWav PRkBR5+79vW2KRS1a/gUk9mGEnn9CSvnj7ArioPhQKXq8haCkj6+jzu/mcoCzblw OoIn82s2tsO1UzFn9Gen34hrYmMfEWTgSkXuvO8fA3pjf7IzSGEDvAVT/MCEnIO4 V/dW+3DPWG57hN6Zsz/kRqhfrOHFDBUvSXorHYIBCBf6sjdkL32rJ+LNOVf8riU+ HCp9W0TIDbbOyibnYSjIznQN9ZPZIvN5gQ7QaIzMvmmUbhYF+s/rJuTsjVq8bNnP VjJefixodDWY34OaL1Tx6wSG8STswMRet6dzby4Ng== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheekgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphepgedtrdduvddurdduieeirdeifeenucevlhhushht vghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.121.166.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 04D2630606E9 for ; Sun, 9 Feb 2020 02:32:32 -0500 (EST) Content-Type: multipart/alternative; boundary="===============0764814649462881125==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: quic@ietf.org Subject: Weekly github digest (QUIC Activity Summary) Message-Id: <20200209073232.04D2630606E9@mailuser.nyi.internal> Date: Sun, 9 Feb 2020 02:32:32 -0500 (EST) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 07:32:40 -0000 --===============0764814649462881125== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+11/-2/=F0=9F=92=AC92) 11 issues created: - Authenticating connection IDs (by martinthomson) https://github.com/quicwg/base-drafts/issues/3439 [-transport]=20 - CONNECTION_CLOSE should be allowed in 0-RTT (by marten-seemann) https://github.com/quicwg/base-drafts/issues/3436=20 - Allow CONNECTION_CLOSE in 0-RTT (by martinthomson) https://github.com/quicwg/base-drafts/issues/3435 [-transport]=20 - Remembering transport parameters (by martinthomson) https://github.com/quicwg/base-drafts/issues/3434 [-transport]=20 - It is unclear if some frames are forbidden in 0-RTT (by kazuho) https://github.com/quicwg/base-drafts/issues/3430=20 - A fixed transport parameter profile is legitimate (by martinthomson) https://github.com/quicwg/base-drafts/issues/3429 [-transport]=20 - H3 guidance on CONNECTION_CLOSE does make clear if the type is 0x1c or = 0x1d (by LPardue) https://github.com/quicwg/base-drafts/issues/3428 [-http]=20 - active_connection_id_limit description is unclear about whose connectio= n ID might be zero length (by nharper) https://github.com/quicwg/base-drafts/issues/3427=20 - active_connection_id_limit is unknown for 0-RTT (by marten-seemann) https://github.com/quicwg/base-drafts/issues/3423=20 - Forced connection ID retirement (by martinthomson) https://github.com/quicwg/base-drafts/issues/3420 [-transport]=20 - Order transport parameters (by marten-seemann) https://github.com/quicwg/base-drafts/issues/3418=20 32 issues received 92 new comments: - #3439 Authenticating connection IDs (1 by ad-l) https://github.com/quicwg/base-drafts/issues/3439 [-transport]=20 - #3436 CONNECTION_CLOSE should be allowed in 0-RTT (1 by marten-seemann) https://github.com/quicwg/base-drafts/issues/3436=20 - #3435 Allow CONNECTION_CLOSE in 0-RTT (3 by MikeBishop, ianswett, kazuh= o) https://github.com/quicwg/base-drafts/issues/3435 [-transport]=20 - #3430 It is unclear if some frames are forbidden in 0-RTT (6 by MikeBis= hop, ekr, marten-seemann, martinthomson) https://github.com/quicwg/base-drafts/issues/3430 [-transport]=20 - #3429 A fixed transport parameter profile is legitimate (8 by dtikhonov= , ekr, ianswett, kazuho, marten-seemann, martinthomson, nharper) https://github.com/quicwg/base-drafts/issues/3429 [-transport]=20 - #3423 active_connection_id_limit is unknown for 0-RTT (6 by MikeBishop,= larseggert, marten-seemann) https://github.com/quicwg/base-drafts/issues/3423 [-transport] [design]= =20 - #3420 Forced connection ID retirement (5 by MikeBishop, erickinnear, ka= zuho, larseggert, nibanks) https://github.com/quicwg/base-drafts/issues/3420 [-transport] [design]= =20 - #3418 Order transport parameters (4 by huitema, kazuho, larseggert, mar= ten-seemann) https://github.com/quicwg/base-drafts/issues/3418 [-transport] [design]= =20 - #3413 Does the amplification limit apply to PTO packets? (1 by larsegge= rt) https://github.com/quicwg/base-drafts/issues/3413 [-transport] [design]= =20 - #3408 Is absence of both :authority and Host an error? (1 by larseggert) https://github.com/quicwg/base-drafts/issues/3408 [-http] [design]=20 - #3373 More strongly recommend ECN marking (4 by huitema, larseggert, ma= rtinthomson, mirjak) https://github.com/quicwg/base-drafts/issues/3373 [-transport] [design]= [proposal-ready]=20 - #3363 max_ack_delay should be in us, not ms (2 by ianswett, marten-seem= ann) https://github.com/quicwg/base-drafts/issues/3363 [-transport]=20 - #3353 Description of the use of Preferred Address is unclear (5 by Mike= Bishop, huitema, kazuho, larseggert, martinthomson) https://github.com/quicwg/base-drafts/issues/3353 [-transport] [design]= =20 - #3350 Ignoring ACK delay can result in wrong RTT calculations (1 by lar= seggert) https://github.com/quicwg/base-drafts/issues/3350 [-recovery] [design] = - #3348 Which DCID do Handshake retransmissions use? (5 by huitema, iansw= ett, kazuho, larseggert) https://github.com/quicwg/base-drafts/issues/3348 [-transport] [design]= =20 - #3340 Anti-amplification limits should count junk too (1 by ianswett) https://github.com/quicwg/base-drafts/issues/3340 [-transport]=20 - #3335 Immediate retransmission upon loss detection (1 by larseggert) https://github.com/quicwg/base-drafts/issues/3335 [-recovery] [design] = - #3333 Padding outside QUIC packet (6 by ekr, huitema, igorlord, larsegg= ert, martinthomson) https://github.com/quicwg/base-drafts/issues/3333 [-transport] [design]= [proposal-ready]=20 - #3332 Composability of QUIC Extensions (1 by larseggert) https://github.com/quicwg/base-drafts/issues/3332 [-transport] [design]= =20 - #3304 ACK generation recommendation (1 by larseggert) https://github.com/quicwg/base-drafts/issues/3304 [-transport] [design]= =20 - #3294 Make transport parameter ID and length varint (5 by DavidSchinazi= , LPardue, britram, larseggert) https://github.com/quicwg/base-drafts/issues/3294 [-transport] [design]= [proposal-ready]=20 - #3272 pto_count should be reset when dropping a packet number space (1 = by larseggert) https://github.com/quicwg/base-drafts/issues/3272 [-recovery] [design] = - #3259 Safety issue during incipient persistent congestion episode (1 by= larseggert) https://github.com/quicwg/base-drafts/issues/3259 [-recovery] [design] = - #3216 Flow Control Tuning (1 by larseggert) https://github.com/quicwg/base-drafts/issues/3216 [-transport] [design]= =20 - #3215 Timer interval for retire the connection IDs (4 by MikeBishop, ka= zuho, larseggert) https://github.com/quicwg/base-drafts/issues/3215 [-transport] [design]= [proposal-ready]=20 - #3161 Simplify the client's PTO code by allowing the server to send a P= ING (3 by ianswett, larseggert) https://github.com/quicwg/base-drafts/issues/3161 [-recovery] [-transpo= rt] [design]=20 - #3126 TIMEOUT CONNECTION_CLOSE error (1 by larseggert) https://github.com/quicwg/base-drafts/issues/3126 [-transport] [design]= =20 - #3094 congestion window increase on every ACKed packet could result in = bursty sends (5 by goelvidhi, janaiyengar, larseggert, tfpauly) https://github.com/quicwg/base-drafts/issues/3094 [-recovery] [design] = [proposal-ready]=20 - #3078 Lost Server Initial Takes Too Long to be Retransmitted (1 by lars= eggert) https://github.com/quicwg/base-drafts/issues/3078 [-recovery] [design] = - #2923 MIN_RTT management (4 by gorryfair, huitema, larseggert, martinth= omson) https://github.com/quicwg/base-drafts/issues/2923 [-recovery] [design] = [proposal-ready]=20 - #2223 When can you coalesce connections (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2223 [-http] [design]=20 - #253 HTTP/QUIC without Alt-Svc? (2 by larseggert, vrubleg) https://github.com/quicwg/base-drafts/issues/253 [-http] [design]=20 2 issues closed: - MIN_RTT management https://github.com/quicwg/base-drafts/issues/2923 [-= recovery] [design] [proposal-ready]=20 - CONNECTION_CLOSE should be allowed in 0-RTT https://github.com/quicwg/b= ase-drafts/issues/3436=20 Pull requests ------------- * quicwg/base-drafts (+9/-0/=F0=9F=92=AC5) 9 pull requests submitted: - Allow CONNECTION_CLOSE in 0-RTT (by martinthomson) https://github.com/quicwg/base-drafts/pull/3440 [-tls] [-transport] [de= sign]=20 - #3348 Clarify that you can use any issued CID at any time, even during = the handshake (by erickinnear) https://github.com/quicwg/base-drafts/pull/3438=20 - clarify that HANDSHAKE_DONE, NEW_TOKEN, PATH_RESPONSE, RCID frames MUST= NOT appear in 0-RTT (by kazuho) https://github.com/quicwg/base-drafts/pull/3431=20 - Clarify zero-length CIDs and active_connection_id_limit TP (by nharper) https://github.com/quicwg/base-drafts/pull/3426=20 - Remember active_connection_id_limit for 0-RTT (by martinthomson) https://github.com/quicwg/base-drafts/pull/3425 [-transport] [design]=20 - Point out that the payload size could decrease (by ianswett) https://github.com/quicwg/base-drafts/pull/3424=20 - Add citation to website fingerprinting draft (by ekr) https://github.com/quicwg/base-drafts/pull/3417=20 - Added a word of caution. (by huitema) https://github.com/quicwg/base-drafts/pull/3416=20 - Reset PTO and loss detection timer when discarding keys (by ianswett) https://github.com/quicwg/base-drafts/pull/3415 [-transport]=20 3 pull requests received 5 new comments: - #3431 clarify that HANDSHAKE_DONE, NEW_TOKEN, PATH_RESPONSE, RCID frame= s MUST NOT appear in 0-RTT (3 by kazuho, martinthomson) https://github.com/quicwg/base-drafts/pull/3431=20 - #3425 Remember active_connection_id_limit for 0-RTT (1 by marten-seeman= n) https://github.com/quicwg/base-drafts/pull/3425 [-transport] [design]=20 - #3162 Server sends a PING-only packet if it's limited (1 by martinduke) https://github.com/quicwg/base-drafts/pull/3162 [-recovery] [-transport= ]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============0764814649462881125== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Activity Summary)

Sunday February 09, 2020

Events without label "editorial"

Issues

quicwg/base-drafts (+11/-2/=F0=9F=92=AC92)

11 issues created:

32 issues received 92 new comments:

2 issues closed:

Pull requests

quicwg/base-drafts (+9/-0/=F0=9F=92=AC5)

9 pull requests submitted:

3 pull requests received 5 new comments:

Repositories tracked by this digest:

--===============0764814649462881125==-- From nobody Mon Feb 10 08:05:11 2020 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 D0CB612009E for ; Mon, 10 Feb 2020 01:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 iWsLq00juF1y for ; Mon, 10 Feb 2020 01:20:10 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id E092B12008C for ; Mon, 10 Feb 2020 01:20:09 -0800 (PST) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 510E41B001AB; Mon, 10 Feb 2020 09:19:46 +0000 (GMT) Subject: Re: DRAFT minutes for the Zurich interim To: QUIC WG , Lars Eggert Cc: Mark Nottingham References: From: Gorry Fairhurst Message-ID: Date: Mon, 10 Feb 2020 09:19:45 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7C49A66A99F1D72B4A2C5C7A" Content-Language: en-GB Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 09:20:13 -0000 This is a multi-part message in MIME format. --------------7C49A66A99F1D72B4A2C5C7A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 07/02/2020 23:03, Lucas Pardue wrote: > ... are available at: > https://github.com/quicwg/wg-materials/blob/master/interim-20-02/minutes.md > > As always, corrections appreciated, either as Pull Requests or e-mail. > > Thanks again to our scribes and hosts. > > Lucas Thanks - remote participation  was a 'tad /challenging/, so these notes are very welcome! When the Interim discussed the ACK generation recommendation, Issue #3304 I know we discussed one proposed extension (in this issue): https://datatracker.ietf.org/doc/draft-iyengar-quic-delayed-ack/ I don't think I heard any discussion of a possible different recommendation for a default (noted in the same issue): https://datatracker.ietf.org/doc/draft-fairhurst-quic-ack-scaling/ As I said in the issue, I see these as two parts of the same discussion - the WG could go forward with both a more suitable default and a way to make this extensible. So I'm rather disappointed that there seems to be proposal to "close with no action" based on the first, can we please think carefully about the base spec recommendation also? Should we propose text as an "ediitorial issue" ?  We'd be happy to follow-up with data and/or text initially based on some sentences from draft-fairhurst-quic-ack-scaling. Gorry --------------7C49A66A99F1D72B4A2C5C7A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 07/02/2020 23:03, Lucas Pardue wrote:
... are available at:

As always, corrections appreciated, either as Pull Requests or e-mail.

Thanks again to our scribes and hosts.

Lucas

Thanks - remote participation  was a 'tad challenging, so these notes are very welcome!


When the Interim discussed the ACK generation recommendation, Issue #3304

I know we discussed one proposed extension (in this issue):

https://datatracker.ietf.org/doc/draft-iyengar-quic-delayed-ack/

I don't think I heard any discussion of a possible different recommendation for a default (noted in the same issue):

https://datatracker.ietf.org/doc/draft-fairhurst-quic-ack-scaling/

As I said in the issue, I see these as two parts of the same discussion - the WG could go forward with both a more suitable default and a way to make this extensible.

So I'm rather disappointed that there seems to be proposal to  "close with no action" based on the first, can we please think carefully about the base spec recommendation also?

Should we propose text as an "ediitorial issue" ?  We'd be happy to follow-up with data and/or text initially based on some sentences from draft-fairhurst-quic-ack-scaling.

Gorry --------------7C49A66A99F1D72B4A2C5C7A-- From nobody Mon Feb 10 10:58:14 2020 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 4CE4E120019 for ; Mon, 10 Feb 2020 10:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDz4RmhKOVwD for ; Mon, 10 Feb 2020 10:58:11 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 3C48B12081A for ; Mon, 10 Feb 2020 10:58:11 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id r11so5908913wrq.10 for ; Mon, 10 Feb 2020 10:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XeN7kAMiBm54cs4T3Qtr2HUvDKmkEU7anA35aS6Y5c0=; b=BKxhBDCQDWYJyD5OTyX/WRyR0cWJ0awn8ot9Tkmn4nyvTnuid65NMsZXQWiSvzvAu0 Vvk3iEXljEFenltomFxPuU+HpREQor8LVnqDQJkEOHIFAb45yAHypQx1OUQFQPLPy13H tuIiKPQs801Z4uPOzhV2CI1VsqQAFzkGgvvy5FcVUYhmtizsdtKdpgxbkbXleXWs85aT inpK4gBNMyWNTZm58rq3r7Wa7/pdNPeR1dYhViXKGAmnrM2PTiBm5NJMlwpR+sDyjCLW gycCZD4clCrA/xvy6Z15+eUCua3+n2yXRx2UUAFGpmveG2tw5vJyeiWQcVUxRUyZN11x aEXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XeN7kAMiBm54cs4T3Qtr2HUvDKmkEU7anA35aS6Y5c0=; b=e2/Ap696TA4M1HUBfzW2AZEVw6VDkHo2Fj2GEyu2fL98i3czipOZQp8X79np9H4rMY Eig8XYmgLeJmMN8o6DW63DK3YhnfLLxuJm1M6hNW8ujvDuQyKOB1cESubwJf8iQrDn2j mle/S+PSIs+oBe1axqSTDIacH40NNh9d1yzHhkaN7KyEr1MGzj7iDl7VnIcP6ajNXRuf mM6kIsodpNzqjIEu//HZ+7+EoYgHOq/Cm8G67AdhXy3jJPUF9ppja/q94KXkhySdiIy3 4uNqcUwF1yrpfyjHGT2YHQIcZpystnWRYVzM4Zj6nhT+vLP/HlHi8GbC4eZkWphiNnLi q48w== X-Gm-Message-State: APjAAAU/OSME7vvMcuWIbc8adJwGc1W/t//uFzo4zvG55usednu7m4DB itMbgsCf6/Au95B96eyiSm8O7MACSXz4lwvxetM= X-Google-Smtp-Source: APXvYqy3HkLpZdbCy7hRRzCUctnMddaHnttwUL7hfjfutuaDBMYj7aBzkJOaMce0m/DVnPZwC925aPnB6YvbUzTxAQU= X-Received: by 2002:adf:fe83:: with SMTP id l3mr3551201wrr.41.1581361089756; Mon, 10 Feb 2020 10:58:09 -0800 (PST) MIME-Version: 1.0 References: <69F63EAA-B7AB-4874-9AD5-7C8F98A92C77@apple.com> In-Reply-To: From: Martin Duke Date: Mon, 10 Feb 2020 19:57:58 +0100 Message-ID: Subject: Re: QUIC re-chartering: include DNS-over-QUIC? To: Erik Kline Cc: Paul Vixie , Vidhi Goel , IETF QUIC WG , Christopher Wood , Ian Swett Content-Type: multipart/alternative; boundary="0000000000000443b5059e3d5224" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 18:58:13 -0000 --0000000000000443b5059e3d5224 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As others have said, this is great work that should be done elsewhere. If we've done a good job, the QUIC transport should be able to handle this use case without a bunch of transport-re-engineering. However, if it turns out you need a protocol tweak, please come back to us. On Thu, Feb 6, 2020 at 11:12 PM Erik Kline wrote: > > > On Thu, Feb 6, 2020 at 1:17 PM Paul Vixie wrote: > >> >> >> Vidhi Goel wrote on 2020-02-06 18:26: >> > I support DoQ for the use cases that are based on non HTTP application >> > protocol. DoQ implicitly provides benefits of QUIC which DoT doesn=E2= =80=99t >> have. >> >> i fear this may be off-topic for this mailing list; in which case, just >> tell me. i've been watching this thread carefully, and i think the >> concern about too many dns transports with no possible guidance to >> developers as to which one to try in what order. >> > > I think the add charter might be aiming to address the advice to clients > concern (https://datatracker.ietf.org/doc/charter-ietf-add/). > --0000000000000443b5059e3d5224 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As others have said, this is great work that should b= e done elsewhere. If we've done a good job, the QUIC transport should b= e able to handle this use case without a bunch of transport-re-engineering.=

However, if it turns out you need a protocol twea= k, please come back to us.

On Thu, Feb 6, 2020 at 11:12 PM Erik Kl= ine <ek.ietf@gmail.com> wrot= e:


On Thu, Feb 6, 2020 at 1:17 PM Paul Vixie <paul@redbarn.org> = wrote:


Vidhi Goel wrote on 2020-02-06 18:26:
> I support DoQ for the use cases that are based on non HTTP application=
> protocol. DoQ implicitly provides benefits of QUIC which DoT doesn=E2= =80=99t have.

i fear this may be off-topic for this mailing list; in which case, just tell me. i've been watching this thread carefully, and i think the
concern about too many dns transports with no possible guidance to
developers as to which one to try in what order.

<= /div>
I think the add charter might be aiming to address the advice to = clients concern (https://datatracker.ietf.org/doc/charter-ietf-add/).
--0000000000000443b5059e3d5224-- From nobody Mon Feb 10 12:52:31 2020 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 B347212084E for ; Mon, 10 Feb 2020 12:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5WLE4mN0Qug for ; Mon, 10 Feb 2020 12:52:28 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 34C94120018 for ; Mon, 10 Feb 2020 12:52:28 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id a5so786282wmb.0 for ; Mon, 10 Feb 2020 12:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vEIm/Dp5qNLHLfmIkixAvuswERTqFdICEvcR2ZYrbc0=; b=LQKF4eS0lqRYJhSYiNPxTSZsJ7JvMm2p/oyORoQY9cLnkGRfXzGC//kqSZe8KOoVRv HOCksT7SG9i20eGN+LS1JIt2djy568NoXpmeWpf1s7pYluNmNrqIJgiItxckTuxkRS4m h1Ifl0t/p9O51HvwZqEzo3wvOWjzBq7iS2NADt4yKcOcmcIbvxlbOVPjWjePBMbDKbnf sPz0kJMBy7sCmVaOZQ/gVGxm4fhV77brzXV/pXjntt7KqXl9RLVbEYnY/+INcRGkAJCg V+3ZWKujoCm+9KII2W2Ru13fwcV9NKTSxCVp1eZ9toGfGbmyKWYtn7/Cyp0L2ew85WBO ZK+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vEIm/Dp5qNLHLfmIkixAvuswERTqFdICEvcR2ZYrbc0=; b=kYJL4ozoqT4phJgz3YGeJ6NGbdWQNd1tkHMYn5Wr/uqgHu2Oe/RmXapiW8nIsx0aUx 3i6R1PyhTzCfh50IiLxTHii4lvws7oqdLo0JyQKKiPjHd54dXTD9aEAMs3l2G6Ma6BrK QYX65HmdtmK0z6Q0qm9GZkO6/xuSLIshtFVSCv4xS5CESU41zObqmxHmGQy2UapHyQIC n0AdyMafo6r6u6h//wRd7OtAr6I8hcLJVgYqZZCtQ8PF9tR14rZHI3bMVsxh/5QZyoi+ EHa0MSSY/9qVieF/lGNCj2nQov8WqTaRv7Ck5JA5IU5zWMHiE5V2XWeN4abtbhu5D9SA AO7Q== X-Gm-Message-State: APjAAAUp4SrLWMcaHTbgTw45K2luduBHE8xKMygzvUo4xytREszi69R9 7oD1DPHeYMs+HVMKEaQOeEViNr0J/UiXrfqeHUE= X-Google-Smtp-Source: APXvYqwZnPJzYSgVe9gVEBOP0yIkEWqGlhGa7cEQvBHrFtvVQGB+XkK0yK4cXoBWrbn+7vuS3KNXu+u6WavZRBrsu8s= X-Received: by 2002:a1c:7215:: with SMTP id n21mr894567wmc.154.1581367946654; Mon, 10 Feb 2020 12:52:26 -0800 (PST) MIME-Version: 1.0 References: <157470946896.14159.17248985824634821547.idtracker@ietfa.amsl.com> <6A334674-0D30-4FB6-A4BE-4D2BBAF344A4@ericsson.com> In-Reply-To: <6A334674-0D30-4FB6-A4BE-4D2BBAF344A4@ericsson.com> From: Martin Duke Date: Mon, 10 Feb 2020 21:52:14 +0100 Message-ID: Subject: Re: New Version Notification for draft-duke-quic-natsupp-00.txt To: Mirja Kuehlewind Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b839dd059e3eea2e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 20:52:31 -0000 --000000000000b839dd059e3eea2e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Responses inline: On Thu, Jan 30, 2020 at 10:53 AM Mirja Kuehlewind < mirja.kuehlewind@ericsson.com> wrote: > > > I somehow was initially only think about out-going packet and no incoming > packets=E2=80=A6 so, yes, the NAT needs to discard this packet. However, = you say > the NAT is out of addresses/ports, thus not using the CID would have mean= t > that it would have to discard the connection right at the beginning. Not > sure if that is any better=E2=80=A6? > It's a good point that immediately dropping is not great either. However, - this would create an ossification vector where CID changes may break the protocol. - it's better for QUIC to fail right away (enabling TCP fallback) than to black hole suddenly. > > > > > Section 4.2. > > - Server deployment has 4-tuple routing and it is expensive to change > > - IT installs a NAT at the front of the infrastructure that stores a > mapping of CIDs to inbound source address and port. > > > > This step was also not fully clear to me from the draft. Now that I look > at it again, I understand what=E2=80=99s meant but I think it could be cl= earer in > the draft. > > > > So is 4-tuple routing actually common? Why is the 4-tuple used instead of > only routing based on the destination address/port? > Yes it's common. If we're fronting a single website there may be a single destination IP and well-known port, so the destination doesn't add any entropy. > > > - If a packet arrives with a known CID but a different source > address/port, the NAT will rewrite the source/address port to the old > value, and thus the packet will route to the correct back-end server. Thu= s > the infrastructure is robust to NAT rebinding, if not intentional migrati= on > with a new CID. > > - While this "works", it has security implications as discussed. > > > > I think you need to further explain the attack case here in the draft =E2= =80=93 > that an attacker might spoof the IP address and therefore can DDoS a targ= et > as the server might keep sending a large amount of data to that new IP > address. However, I think this should probably be discussed in the securi= ty > section of the transport draft a bit more as this is only possible becaus= e > of migration which is a new feature in QUIC. > I believe Eric Kinnear has already written a ton about how to handle new addresses in the transport draft. I'll rewrite the paragraph as you suggest= . > > > However, given that if someone anyway decided to implement this setup, th= e > endpoints have no way to detect that an address changed and was > respectively re-written then again, should we maybe start think about a w= ay > to improve the situation=E2=80=A6? > > The signal here is that absolutely nothing in the packet has changed, so I'm not sure how endpoints could possibly detect this. > --000000000000b839dd059e3eea2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Responses inline:

On Thu, Jan 30, 2020= at 10:53 AM Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> wrote:

=C2=A0

I somehow was initially only th= ink about out-going packet and no incoming packets=E2=80=A6 so, yes, the NA= T needs to discard this packet. However, you say the NAT is out of addresse= s/ports, thus not using the CID would have meant that it would have to discard the connection right at the beginning. Not s= ure if that is any better=E2=80=A6?


It's a good point that immediately dropping= is not great either. However,
  • this would create an = ossification vector where CID changes may break the protocol.
  • it= 9;s better for QUIC to fail right away (enabling TCP fallback) than to blac= k hole suddenly.

=C2=A0

=C2=A0

=C2=A0

Section 4.2.

- Server deployment has 4= -tuple routing and it is expensive to change

- IT installs a NAT at th= e front of the infrastructure that stores a mapping of CIDs to inbound sour= ce address and port.

=C2=A0

This step was also not fully cl= ear to me from the draft. Now that I look at it again, I understand what=E2= =80=99s meant but I think it could be clearer in the draft.

=C2=A0

So is 4-tuple routing actually = common? Why is the 4-tuple used instead of only routing based on the destin= ation address/port?

Yes it's common. If we're fronting a single website the= re may be a single destination IP and well-known port, so the destination d= oesn't add any entropy.
=C2=A0

=C2=A0

- If a packet arrives wit= h a known CID but a different source address/port, the NAT will rewrite the= source/address port to the old value, and thus the packet will route to th= e correct back-end server. Thus the infrastructure is robust to NAT rebinding, if not intentional migration wi= th a new CID.

- While this "works&= quot;, it has security implications as discussed.

=C2=A0

I think you need to further exp= lain the attack case here in the draft =E2=80=93 that an attacker might spo= of the IP address and therefore can DDoS a target as the server might keep = sending a large amount of data to that new IP address. However, I think this should probably be discussed in the securit= y section of the transport draft a bit more as this is only possible becaus= e of migration which is a new feature in QUIC.

=

I believe Eric Kinnear has already w= ritten a ton about how to handle new addresses in the transport draft. I= 9;ll rewrite the paragraph as you suggest.
=C2=A0

=C2=A0

However, given that if someone = anyway decided to implement this setup, the endpoints have no way to detect= that an address changed and was respectively re-written then again, should= we maybe start think about a way to improve the situation=E2=80=A6?


The= signal here is that absolutely nothing in the packet has changed, so I'= ;m not sure how endpoints could possibly detect this.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
--000000000000b839dd059e3eea2e-- From nobody Mon Feb 10 13:36:05 2020 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 CDDF9120863; Mon, 10 Feb 2020 13:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28wQP72gMISP; Mon, 10 Feb 2020 13:35:59 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 3812C120858; Mon, 10 Feb 2020 13:35:59 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id n18so9111638ljo.7; Mon, 10 Feb 2020 13:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QTRZUNakMQP7FkrpUDHGrldgsS9qcvBKgMkHKNspAMU=; b=YYUmSv1tLrIXjWIRj2yP1rbSAXsxmnbh+CChvGnUbh+YZmAPENEQ1osRPvl+xKwlr4 w/sPWqN1AfegWLpUH2JwNS8h8gR/wOkdbK04ykGVpaUVl0D/VvX8/EZqie/J+z5/sIEs 9ilPsuk+s/xDLOCD/r6bUyX8z1tQ6SjXrmCnstS7BaLkVZT3pr19M9Y6mBzZc2mRPwyd TUZJr8llprpvDLwZeHuZ9SCznq6dxmh4l0hmbViIZ+GkUjaNsXI/D0VlJVwY2MFLG97K EIqE0xLD2LXqTsrsGEcSV9fk96zBLsbuKL9VoGcMP9WBZ73Q1AY3SJu7glABwxWjMOVM g8dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QTRZUNakMQP7FkrpUDHGrldgsS9qcvBKgMkHKNspAMU=; b=H5YoTuoDrq5brH+Z77NeguwhFKKQJA1TWM5dxWWs6E4fLAwvvcShpGENeeR/zujnbq UrBACmm7Hn9rYCZ2zMwaHjdM/l8+Gxly+AtJ1rDtb0jF8hlgdr451T1yenVqxkyXY9Wt Bblr0gOQlwRgwYNvZn8aXmQ6MCUruKGW7SAN7YtZKpnbpXVd5kEKnOJqbzd5U1lO97wM GCLqSPW4BDNIiuQyfvQqeiJ+61+x6RjZcMB0qN9wuDI136A/9npLTZFglDekBabmXSDl aUv4/aFC0KNHwCrQO+9oz/gZ0wYj1ZBSlmNKMPMblB0rp+KXVO35FVX3xHL7JXdkL3bu LvmQ== X-Gm-Message-State: APjAAAUyG8xjfDPDXKzKgj0k1/ikDJlnnl1QHHg9d5qJKWIcuBAhiVNL Stf2GbFFzb/Wi66wjmopzhzLE6atNfE48EG28sVkh7niRa4= X-Google-Smtp-Source: APXvYqxVQv1sFMrBxgxXrQLuaLOnBzBCLuP4eFl74NmCuJDeD/aIwTh3XPeMOqWKBbz1+QuC2vwMru7aubt6zMx0j9s= X-Received: by 2002:a2e:300e:: with SMTP id w14mr2142973ljw.222.1581370557044; Mon, 10 Feb 2020 13:35:57 -0800 (PST) MIME-Version: 1.0 References: <158109575881.11589.7522751407809468206.idtracker@ietfa.amsl.com> In-Reply-To: <158109575881.11589.7522751407809468206.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Mon, 10 Feb 2020 15:35:30 -0600 Message-ID: Subject: Re: WG Review: QUIC (quic) To: The IESG Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000004f9a2e059e3f867d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 21:36:04 -0000 --0000000000004f9a2e059e3f867d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear IESG, I don't have any concerns about the direction for this charter, but I do have some suggestions on wording. Best, Spencer On Fri, Feb 7, 2020 at 11:16 AM The IESG wrote: > The QUIC (quic) WG in the Transport Area of the IETF is undergoing > rechartering. The IESG has not made any determination yet. The following > draft charter was submitted, and is provided for informational purposes > only. > Please send your comments to the IESG mailing list (iesg@ietf.org) by > 2020-02-17. > > QUIC (quic) > ----------------------------------------------------------------------- > Current status: Active WG > > Chairs: > Mark Nottingham > Lars Eggert > Lucas Pardue > > Assigned Area Director: > Magnus Westerlund > > Transport Area Directors: > Mirja K=C3=BChlewind > Magnus Westerlund > > Mailing list: > Address: quic@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/quic > Archive: https://mailarchive.ietf.org/arch/browse/quic/ > > Group page: https://datatracker.ietf.org/group/quic/ > > Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/ > > The QUIC working group will provide standards-track specifications for a > UDP-based, stream-multiplexing, encrypted transport protocol, based on > pre-standardization implementation and deployment experience. > > Key goals for QUIC are: > I'm wondering when these change from goals to attributes, but maybe the next major revision is the right time ... > - Minimizing connection establishment and overall transport latency for > applications, starting with HTTP; > > - Providing multiplexing without head-of-line blocking; > > - Requiring only changes to path endpoints to enable deployment; > > - Enabling multipath and forward error correction extensions; and > > - Providing always-secure transport, using TLS 1.3 by default. > > The work of the group will have five main focus areas, corresponding to > five > core deliverables. > > The first of these is the core transport work, which will describe the wi= re > I wonder when the charter moves from future tense (which was accurate in 2016) to present tense, but perhaps after version 1 is complete would be a good time. > format, along with the mechanisms for connection establishment, stream > multiplexing, data reliability, loss detection and recovery, congestion > control, and options negotiation. Work on congestion control will describ= e > use of a standardized congestion controller as a default scheme for QUIC. > Defining new congestion control schemes is explicitly out of scope for th= is > group. QUIC is expected to support rapid, distributed development and > testing > of features. > > The second of these focus areas is security. This work will describe how > the > protocol uses TLS 1.3 for key negotiation and will also describe how thos= e > keys are used to provide confidentiality and integrity protection of both > application data and QUIC headers. This work will ensure that QUIC has > security and privacy properties that are at least as good as a stack > composed > of TLS 1.3 using TCP (or MPTCP when using multipath). > > The third focus area describes the mapping between the HTTP application > protocol and the transport facilities of QUIC. This mapping will have > performance characteristics comparable with HTTP/2, and provide extension > mechanisms similar to HTTP/2. Upon completion of this mapping, work to > define > additional mappings may be included by updates to this charter, or may be > worked on by other working groups. > When QUIC was chartered, my hope (and I don't think I was the only one) was that we would end up with HTTP/2 over QUIC. For good reasons, we ended up with HTTP/3 over QUIC, and it seems odd that there's no mention of HTTP/3 in the 2020 QUIC charter, but it IS mentioned in https://datatracker.ietf.org/doc/charter-ietf-httpbis/. > The fourth focus area will be on extensions to core protocol facilities, = to > enable datagram delivery, version negotiation, and multipath capabilities= . > Other extensions are out of the scope of this charter. > > The fifth focus area will provide an Applicability and Manageability > Statement, describing how, and under what circumstances, QUIC may be safe= ly > used, and describing deployment and manageability implications of the > protocol. Additionally, the Working Group will provide guidance on how to > handle QUIC traffic in load balancers. > > Current practices for network management of transport protocols include t= he > ability to apply access control lists (ACLs), hashing of flows for > equal-cost > multipath routing (ECMP), directional signaling of flows, signaling of fl= ow > setup and teardown, and the ability to export information about flows for > accounting purposes. The QUIC protocol need not be defined to enable each > of > these abilities, or enable them in the same way as they are enabled by TC= P > when used with TLS 1.3, but the working group must consider the impact of > the > protocol on network management practices, reflecting the tensions describ= ed > in RFC 7258. > > 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. > This paragraph ^ was inserted to say "the way Google QUIC happens to work in 2016" (which was the only QUIC we had) "isn't binding on the working group producing IETF QUIC". That was worth saying in 2016 - and we might have said it more clearly - but in 2020, the obvious meaning of "current protocol mechanisms" is IETF QUICv1. I don't think this paragraph means anything helpful now, and anyone who tries to be guided by it, is probably headed into the weeds. I'd delete it. > The QUIC working group will work closely with the HTTPbis working group, > especially on the QUIC mapping for HTTP. > > Milestones: > > Jul 2020 - Core Protocol document to IESG > > Jul 2020 - Loss detection and Congestion Control document to IESG > > Jul 2020 - TLS 1.3 Mapping document to IESG > > Jul 2020 - HTTP/2 mapping document to IESG > > Jul 2020 - QUIC Applicability and Manageability Statement to IESG > Just making sure I understand - the load balancing advice would be included in this statement, is that right? Jul 2020 - Version-Independent Properties of QUIC to IESG > > Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG > > Dec 2020 - Working group adoption of Multipath extension document > > Mar 2021 - Datagram Extension to IESG > > Mar 2021 - Version Negotiation Extension to IESG > > Dec 2021 - Multipath extension document to IESG > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --0000000000004f9a2e059e3f867d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear IESG,=C2=A0

I don't= have any concerns about the direction for this charter, but I do have some= suggestions on wording.=C2=A0

Best,
Spencer

On Fri, Feb 7, 2020 at 11:16 AM The IESG <iesg-secretary@ietf.org> wrote:
<= /div>
The QUIC (quic) WG i= n the Transport Area of the IETF is undergoing
rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes onl= y.
Please send your comments to the IESG mailing list (iesg@ietf.org) by
2020-02-17.

QUIC (quic)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
=C2=A0 Mark Nottingham <mnot@mnot.net>
=C2=A0 Lars Eggert <lars@eggert.org>
=C2=A0 Lucas Pardue <lucaspardue.24.7@gmail.com>

Assigned Area Director:
=C2=A0 Magnus Westerlund <magnus.westerlund@ericsson.com>

Transport Area Directors:
=C2=A0 Mirja K=C3=BChlewind <ietf@kuehlewind.net>
=C2=A0 Magnus Westerlund <magnus.westerlund@ericsson.com>

Mailing list:
=C2=A0 Address: quic@iet= f.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/listinfo= /quic
=C2=A0 Archive: https://mailarchive.ietf.org/arch/brow= se/quic/

Group page: https://datatracker.ietf.org/group/quic/

Charter: https://datatracker.ietf.org/doc/charter= -ietf-quic/

The QUIC working group will provide standards-track specifications for a UDP-based, stream-multiplexing, encrypted transport protocol, based on
pre-standardization implementation and deployment experience.

Key goals for QUIC are:

I'm wonderi= ng when these change from goals to attributes, but maybe the next major rev= ision is the right time ...
=C2=A0
=C2=A0- Minimizing connection establishment and ov= erall transport latency for
=C2=A0applications, starting with HTTP;

=C2=A0- Providing multiplexing without head-of-line blocking;

=C2=A0- Requiring only changes to path endpoints to enable deployment;

=C2=A0- Enabling multipath and forward error correction extensions; and

=C2=A0- Providing always-secure transport, using TLS 1.3 by default.

The work of the group will have five main focus areas, corresponding to fiv= e
core deliverables.

The first of these is the core transport work, which will describe the wire=

I wonder when the charter moves from f= uture tense (which was accurate in 2016) to present tense, but perhaps afte= r version 1 is complete would be a good time.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> format, along with the mechanisms for connection establishment, stream
multiplexing, data reliability, loss detection and recovery, congestion
control, and options negotiation. Work on congestion control will describe<= br> use of a standardized congestion controller as a default scheme for QUIC. Defining new congestion control schemes is explicitly out of scope for this=
group. QUIC is expected to support rapid, distributed development and testi= ng
of features.

The second of these focus areas is security. This work will describe how th= e
protocol uses TLS 1.3 for key negotiation and will also describe how those<= br> keys are used to provide confidentiality and integrity protection of both application data and QUIC headers. This work will ensure that QUIC has
security and privacy properties that are at least as good as a stack compos= ed
of TLS 1.3 using TCP (or MPTCP when using multipath).

The third focus area describes the mapping between the HTTP application
protocol and the transport facilities of QUIC. This mapping will have
performance characteristics comparable with HTTP/2, and provide extension mechanisms similar to HTTP/2. Upon completion of this mapping, work to defi= ne
additional mappings may be included by updates to this charter, or may be worked on by other working groups.

When= QUIC was chartered, my hope (and I don't think I was the only one) was= that we would end up with HTTP/2 over QUIC. For good reasons, we ended up = with HTTP/3 over QUIC, and it seems odd that there's no mention of HTTP= /3 in the 2020 QUIC charter, but it IS mentioned in=C2=A0https://datatracker.ietf.o= rg/doc/charter-ietf-httpbis/.=C2=A0
=C2=A0
The fourth focus area will be on exten= sions to core protocol facilities, to
enable datagram delivery, version negotiation, and multipath capabilities.<= br> Other extensions are out of the scope of this charter.

The fifth focus area will provide an Applicability and Manageability
Statement, describing how, and under what circumstances, QUIC may be safely=
used, and describing deployment and manageability implications of the
protocol. Additionally, the Working Group will provide guidance on how to handle QUIC traffic in load balancers.

Current practices for network management of transport protocols include the=
ability to apply access control lists (ACLs), hashing of flows for equal-co= st
multipath routing (ECMP), directional signaling of flows, signaling of flow=
setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each o= f
these abilities, or enable them in the same way as they are enabled by TCP<= br> when used with TLS 1.3, but the working group must consider the impact of t= he
protocol on network management practices, reflecting the tensions described=
in RFC 7258.

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.

This paragraph ^ was inserted to say "the way Goo= gle QUIC happens to work in 2016" (which was the only QUIC we had) &qu= ot;isn't binding on the working group producing IETF QUIC". That w= as worth saying in 2016 - and we might have said it more clearly - but in 2= 020, the obvious meaning of "current protocol mechanisms" is IETF= QUICv1. I don't think this paragraph means anything helpful now, and a= nyone who tries to be guided by it, is probably headed into the weeds. I= 9;d delete it.=C2=A0
=C2=A0
The QUIC working group will work closely with the HTTPbis= working group,
especially on the QUIC mapping for HTTP.

Milestones:

=C2=A0 Jul 2020 - Core Protocol document to IESG

=C2=A0 Jul 2020 - Loss detection and Congestion Control document to IESG
=C2=A0 Jul 2020 - TLS 1.3 Mapping document to IESG

=C2=A0 Jul 2020 - HTTP/2 mapping document to IESG

=C2=A0 Jul 2020 - QUIC Applicability and Manageability Statement to IESG

Just making sure I understand - the load = balancing advice would be included in this statement, is that right?=C2=A0<= /div>

=C2= =A0 Jul 2020 - Version-Independent Properties of QUIC to IESG

=C2=A0 Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG

=C2=A0 Dec 2020 - Working group adoption of Multipath extension document
=C2=A0 Mar 2021 - Datagram Extension to IESG

=C2=A0 Mar 2021 - Version Negotiation Extension to IESG

=C2=A0 Dec 2021 - Multipath extension document to IESG


_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--0000000000004f9a2e059e3f867d-- From nobody Mon Feb 10 13:40:26 2020 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 A8A10120866; Mon, 10 Feb 2020 13:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xmNwr8PKjvb; Mon, 10 Feb 2020 13:40:20 -0800 (PST) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 78E57120863; Mon, 10 Feb 2020 13:40:20 -0800 (PST) Received: by mail-vk1-xa34.google.com with SMTP id g7so2294556vkl.12; Mon, 10 Feb 2020 13:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DviJoaBuTM8h/JAVvxqxZcL2g7CuXknSPR6bnIkaOHY=; b=It7TpwVZxGtxOuYNygwcz56dR4eeGFN8E0VekiEadNVF83G0+A/W4JA8ktLgxGYkcL cpVELHZgKoihMzTJYsVZ1a1jkWWYQkrPYizuL19losiF434p4exOhoSXk1KCMcsmfXYd ik5TM6NLXmY1/hftBpv8yzlox+jh3x8hv7mF/JdHdXSxIToNJVOHPjzvpbIM44w5YUlO tUEgK1dOqOInNzlaUVpRLHFF6XX9+47TWuB+Iv95XBGhxgA+ux3lXqzlyhbsiRi5hZJK N534vzdk+MtXx9e0EwS5FprvahVSpYcBUHmujtvLm5mi/dea0FdGsJ9qdt00YVbcJ1KF xUjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DviJoaBuTM8h/JAVvxqxZcL2g7CuXknSPR6bnIkaOHY=; b=t/6I8PK8MqMcUdKhQXMSEKJ0w6KelTgFkrglxznR3FuqckrkKSNoZEoy0ahe1GHHff e39/KFQ8axSErc1J9tly8/lV7VoZrxkTQ4NfDK1hcEU5Ou1QhrHPPl3EyuQNmK1FnEQP 4XX8qjNACtVjSckWyYTfwWMXS3/sSfUXTxGAk5Wz7jpc5dzmx5zlzG7IBIx7+PH3ZwMP Hy9zwhiSioblCDhK/l9K/RhjkQtqSvzZRWabJ/5Xnand0UkAZwNzpCtKnjsxdPdyc8W5 R139dqppRATBd2olhK4LTmiV8EUAeyBeOYjkL8YKZer4Y/uxgKJIfswI5RWqBtDB7Mw5 d5VQ== X-Gm-Message-State: APjAAAUC0HKx7hGuzmkC//HMBLBO7urvce2mvnEqUFSYIYQTQ+ZfVEzP Qx4E9A3YegHsb/qt9xglgV9LfZjW3anuCtIUrGE= X-Google-Smtp-Source: APXvYqy6NH6b4dEC7NtwjhbPKrNTRM4ntMrSG8Cs7p4RBCZCa6Otf2VR3mY+lYsDZtdQo9BUPdk06gO2JCT24lZvwlM= X-Received: by 2002:a1f:4193:: with SMTP id o141mr2369816vka.19.1581370819108; Mon, 10 Feb 2020 13:40:19 -0800 (PST) MIME-Version: 1.0 References: <158109575881.11589.7522751407809468206.idtracker@ietfa.amsl.com> In-Reply-To: From: Giorgio Zoppi Date: Mon, 10 Feb 2020 22:40:07 +0100 Message-ID: Subject: Re: WG Review: QUIC (quic) To: Spencer Dawkins at IETF Cc: The IESG , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000ee6302059e3f9575" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 21:40:25 -0000 --000000000000ee6302059e3f9575 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, when will be the next meeting? I know that the last was in Zurich. BR, Giorgio El lun., 10 feb. 2020 a las 22:36, Spencer Dawkins at IETF (< spencerdawkins.ietf@gmail.com>) escribi=C3=B3: > Dear IESG, > > I don't have any concerns about the direction for this charter, but I do > have some suggestions on wording. > > Best, > > Spencer > > On Fri, Feb 7, 2020 at 11:16 AM The IESG wrote: > >> The QUIC (quic) WG in the Transport Area of the IETF is undergoing >> rechartering. The IESG has not made any determination yet. The following >> draft charter was submitted, and is provided for informational purposes >> only. >> Please send your comments to the IESG mailing list (iesg@ietf.org) by >> 2020-02-17. >> >> QUIC (quic) >> ----------------------------------------------------------------------- >> Current status: Active WG >> >> Chairs: >> Mark Nottingham >> Lars Eggert >> Lucas Pardue >> >> Assigned Area Director: >> Magnus Westerlund >> >> Transport Area Directors: >> Mirja K=C3=BChlewind >> Magnus Westerlund >> >> Mailing list: >> Address: quic@ietf.org >> To subscribe: https://www.ietf.org/mailman/listinfo/quic >> Archive: https://mailarchive.ietf.org/arch/browse/quic/ >> >> Group page: https://datatracker.ietf.org/group/quic/ >> >> Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/ >> >> The QUIC working group will provide standards-track specifications for a >> UDP-based, stream-multiplexing, encrypted transport protocol, based on >> pre-standardization implementation and deployment experience. >> >> Key goals for QUIC are: >> > > I'm wondering when these change from goals to attributes, but maybe the > next major revision is the right time ... > > >> - Minimizing connection establishment and overall transport latency for >> applications, starting with HTTP; >> >> - Providing multiplexing without head-of-line blocking; >> >> - Requiring only changes to path endpoints to enable deployment; >> >> - Enabling multipath and forward error correction extensions; and >> >> - Providing always-secure transport, using TLS 1.3 by default. >> >> The work of the group will have five main focus areas, corresponding to >> five >> core deliverables. >> >> The first of these is the core transport work, which will describe the >> wire >> > > I wonder when the charter moves from future tense (which was accurate in > 2016) to present tense, but perhaps after version 1 is complete would be = a > good time. > > >> format, along with the mechanisms for connection establishment, stream >> multiplexing, data reliability, loss detection and recovery, congestion >> control, and options negotiation. Work on congestion control will descri= be >> use of a standardized congestion controller as a default scheme for QUIC= . >> Defining new congestion control schemes is explicitly out of scope for >> this >> group. QUIC is expected to support rapid, distributed development and >> testing >> of features. >> >> The second of these focus areas is security. This work will describe how >> the >> protocol uses TLS 1.3 for key negotiation and will also describe how tho= se >> keys are used to provide confidentiality and integrity protection of bot= h >> application data and QUIC headers. This work will ensure that QUIC has >> security and privacy properties that are at least as good as a stack >> composed >> of TLS 1.3 using TCP (or MPTCP when using multipath). >> >> The third focus area describes the mapping between the HTTP application >> protocol and the transport facilities of QUIC. This mapping will have >> performance characteristics comparable with HTTP/2, and provide extensio= n >> mechanisms similar to HTTP/2. Upon completion of this mapping, work to >> define >> additional mappings may be included by updates to this charter, or may b= e >> worked on by other working groups. >> > > When QUIC was chartered, my hope (and I don't think I was the only one) > was that we would end up with HTTP/2 over QUIC. For good reasons, we ende= d > up with HTTP/3 over QUIC, and it seems odd that there's no mention of > HTTP/3 in the 2020 QUIC charter, but it IS mentioned in > https://datatracker.ietf.org/doc/charter-ietf-httpbis/. > > >> The fourth focus area will be on extensions to core protocol facilities, >> to >> enable datagram delivery, version negotiation, and multipath capabilitie= s. >> Other extensions are out of the scope of this charter. >> >> The fifth focus area will provide an Applicability and Manageability >> Statement, describing how, and under what circumstances, QUIC may be >> safely >> used, and describing deployment and manageability implications of the >> protocol. Additionally, the Working Group will provide guidance on how t= o >> handle QUIC traffic in load balancers. >> >> Current practices for network management of transport protocols include >> the >> ability to apply access control lists (ACLs), hashing of flows for >> equal-cost >> multipath routing (ECMP), directional signaling of flows, signaling of >> flow >> setup and teardown, and the ability to export information about flows fo= r >> accounting purposes. The QUIC protocol need not be defined to enable eac= h >> of >> these abilities, or enable them in the same way as they are enabled by T= CP >> when used with TLS 1.3, but the working group must consider the impact o= f >> the >> protocol on network management practices, reflecting the tensions >> described >> in RFC 7258. >> >> 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. >> > > This paragraph ^ was inserted to say "the way Google QUIC happens to work > in 2016" (which was the only QUIC we had) "isn't binding on the working > group producing IETF QUIC". That was worth saying in 2016 - and we might > have said it more clearly - but in 2020, the obvious meaning of "current > protocol mechanisms" is IETF QUICv1. I don't think this paragraph means > anything helpful now, and anyone who tries to be guided by it, is probabl= y > headed into the weeds. I'd delete it. > > >> The QUIC working group will work closely with the HTTPbis working group, >> especially on the QUIC mapping for HTTP. >> >> Milestones: >> >> Jul 2020 - Core Protocol document to IESG >> >> Jul 2020 - Loss detection and Congestion Control document to IESG >> >> Jul 2020 - TLS 1.3 Mapping document to IESG >> >> Jul 2020 - HTTP/2 mapping document to IESG >> >> Jul 2020 - QUIC Applicability and Manageability Statement to IESG >> > > Just making sure I understand - the load balancing advice would be > included in this statement, is that right? > > Jul 2020 - Version-Independent Properties of QUIC to IESG >> >> Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG >> >> Dec 2020 - Working group adoption of Multipath extension document >> >> Mar 2021 - Datagram Extension to IESG >> >> Mar 2021 - Version Negotiation Extension to IESG >> >> Dec 2021 - Multipath extension document to IESG >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> > --=20 Life is a chess game - Anonymous. --000000000000ee6302059e3f9575 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,
when will be the next meeting? I = know that the last was in Zurich.
BR,
Giorgio
=

= El lun., 10 feb. 2020 a las 22:36, Spencer Dawkins at IETF (<spencerdawkins.ietf@gmail.com>= ) escribi=C3=B3:
Dear IESG,=C2=A0

I don'= t have any concerns about the direction for this charter, but I do have som= e suggestions on wording.=C2=A0

Best,
Spencer

On Fri, Feb 7, 2020 at 11:16 AM The IESG <iesg-secretary@ietf.org<= /a>> wrote:
T= he QUIC (quic) WG in the Transport Area of the IETF is undergoing
rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes onl= y.
Please send your comments to the IESG mailing list (iesg@ietf.org) by
2020-02-17.

QUIC (quic)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
=C2=A0 Mark Nottingham <mnot@mnot.net>
=C2=A0 Lars Eggert <lars@eggert.org>
=C2=A0 Lucas Pardue <lucaspardue.24.7@gmail.com>

Assigned Area Director:
=C2=A0 Magnus Westerlund <magnus.westerlund@ericsson.com>

Transport Area Directors:
=C2=A0 Mirja K=C3=BChlewind <ietf@kuehlewind.net>
=C2=A0 Magnus Westerlund <magnus.westerlund@ericsson.com>

Mailing list:
=C2=A0 Address: quic@iet= f.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/listinfo= /quic
=C2=A0 Archive: https://mailarchive.ietf.org/arch/brow= se/quic/

Group page: https://datatracker.ietf.org/group/quic/

Charter: https://datatracker.ietf.org/doc/charter= -ietf-quic/

The QUIC working group will provide standards-track specifications for a UDP-based, stream-multiplexing, encrypted transport protocol, based on
pre-standardization implementation and deployment experience.

Key goals for QUIC are:

I'm wonderi= ng when these change from goals to attributes, but maybe the next major rev= ision is the right time ...
=C2=A0
=C2=A0- Minimizing connection establishment and ov= erall transport latency for
=C2=A0applications, starting with HTTP;

=C2=A0- Providing multiplexing without head-of-line blocking;

=C2=A0- Requiring only changes to path endpoints to enable deployment;

=C2=A0- Enabling multipath and forward error correction extensions; and

=C2=A0- Providing always-secure transport, using TLS 1.3 by default.

The work of the group will have five main focus areas, corresponding to fiv= e
core deliverables.

The first of these is the core transport work, which will describe the wire=

I wonder when the charter moves from f= uture tense (which was accurate in 2016) to present tense, but perhaps afte= r version 1 is complete would be a good time.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> format, along with the mechanisms for connection establishment, stream
multiplexing, data reliability, loss detection and recovery, congestion
control, and options negotiation. Work on congestion control will describe<= br> use of a standardized congestion controller as a default scheme for QUIC. Defining new congestion control schemes is explicitly out of scope for this=
group. QUIC is expected to support rapid, distributed development and testi= ng
of features.

The second of these focus areas is security. This work will describe how th= e
protocol uses TLS 1.3 for key negotiation and will also describe how those<= br> keys are used to provide confidentiality and integrity protection of both application data and QUIC headers. This work will ensure that QUIC has
security and privacy properties that are at least as good as a stack compos= ed
of TLS 1.3 using TCP (or MPTCP when using multipath).

The third focus area describes the mapping between the HTTP application
protocol and the transport facilities of QUIC. This mapping will have
performance characteristics comparable with HTTP/2, and provide extension mechanisms similar to HTTP/2. Upon completion of this mapping, work to defi= ne
additional mappings may be included by updates to this charter, or may be worked on by other working groups.

When= QUIC was chartered, my hope (and I don't think I was the only one) was= that we would end up with HTTP/2 over QUIC. For good reasons, we ended up = with HTTP/3 over QUIC, and it seems odd that there's no mention of HTTP= /3 in the 2020 QUIC charter, but it IS mentioned in=C2=A0https://= datatracker.ietf.org/doc/charter-ietf-httpbis/.=C2=A0
=C2=A0<= /div>
The fourth focus are= a will be on extensions to core protocol facilities, to
enable datagram delivery, version negotiation, and multipath capabilities.<= br> Other extensions are out of the scope of this charter.

The fifth focus area will provide an Applicability and Manageability
Statement, describing how, and under what circumstances, QUIC may be safely=
used, and describing deployment and manageability implications of the
protocol. Additionally, the Working Group will provide guidance on how to handle QUIC traffic in load balancers.

Current practices for network management of transport protocols include the=
ability to apply access control lists (ACLs), hashing of flows for equal-co= st
multipath routing (ECMP), directional signaling of flows, signaling of flow=
setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each o= f
these abilities, or enable them in the same way as they are enabled by TCP<= br> when used with TLS 1.3, but the working group must consider the impact of t= he
protocol on network management practices, reflecting the tensions described=
in RFC 7258.

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.

This paragraph ^ was inserted to say "the way Goo= gle QUIC happens to work in 2016" (which was the only QUIC we had) &qu= ot;isn't binding on the working group producing IETF QUIC". That w= as worth saying in 2016 - and we might have said it more clearly - but in 2= 020, the obvious meaning of "current protocol mechanisms" is IETF= QUICv1. I don't think this paragraph means anything helpful now, and a= nyone who tries to be guided by it, is probably headed into the weeds. I= 9;d delete it.=C2=A0
=C2=A0
The QUIC working group will work closely with the HTTPbis= working group,
especially on the QUIC mapping for HTTP.

Milestones:

=C2=A0 Jul 2020 - Core Protocol document to IESG

=C2=A0 Jul 2020 - Loss detection and Congestion Control document to IESG
=C2=A0 Jul 2020 - TLS 1.3 Mapping document to IESG

=C2=A0 Jul 2020 - HTTP/2 mapping document to IESG

=C2=A0 Jul 2020 - QUIC Applicability and Manageability Statement to IESG

Just making sure I understand - the load = balancing advice would be included in this statement, is that right?=C2=A0<= /div>

=C2= =A0 Jul 2020 - Version-Independent Properties of QUIC to IESG

=C2=A0 Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG

=C2=A0 Dec 2020 - Working group adoption of Multipath extension document
=C2=A0 Mar 2021 - Datagram Extension to IESG

=C2=A0 Mar 2021 - Version Negotiation Extension to IESG

=C2=A0 Dec 2021 - Multipath extension document to IESG


_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce


--
Life is a chess game - Anonymous.
--000000000000ee6302059e3f9575-- From nobody Mon Feb 10 19:05:54 2020 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 CFEE1120052; Mon, 10 Feb 2020 19:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 ucH5sSgAp6Cz; Mon, 10 Feb 2020 19:05:00 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 8B785120058; Mon, 10 Feb 2020 19:04:59 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id q8so9800707ljj.11; Mon, 10 Feb 2020 19:04:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6L20v6QNtOnqq5JKz7O2MY8J2JRqPUJrDi7E4ZNvgHc=; b=Z5a9EMdCOAB409lGqe/3fjfYFqXtaAeEaI+pjm+IDb0wWDHL7c5qX3qH9mUFtbduVi fhmHpC+vfy2zkHaKwBfMm++s3u5tBdz4kv8rYG6nJTXg2y0n0tenUuZhDkVXBO8e18x9 aFYwVr1Q0ZMuO/Uf+RZ94bJJS0klAyS1B9fJHO0Q7qeSNT7n0gxYHFovZ3SXUtGQnG1k ZzfsCDXHLrUHp3Z2nxNR898apkfC/RFC2dsQa4Fq+f94aQedOGSfBKxSseDkVwXmNl+F 21rfjuiNKt5C0BCtT6610Nqs+IL6UuLmKbGVQ1td0f6x1PBgkjDSr2qHBvWk9extCh4p QOxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6L20v6QNtOnqq5JKz7O2MY8J2JRqPUJrDi7E4ZNvgHc=; b=odDmoBcmBYocPne9LZIdnmi3qzh/RxxFWF+qDT606absAzX5txrilXZLNEeeWcQ5Xv ZiSHFJzvG7gweRafDaySGfXcU9QWRJbm7q+59Adhp8X0cg3qIEqiDz4oQAXVWA0ijBpR HvLScSn9yk3eM8UBdAaVvyWhe/KuRsEkIoCtDgFNI4sGxLXUzPWam8yLlwG8PwCzA/b0 ydonp3OTwoD7J0UdBuc/4ytGsu6vkcr5HkInvFJnWiNCDVKErl8JQGWMhpCfE3JL6cPl An+kQGZelNuCdq2fNT1pmbSYKig/HEKYZVtyjytZuYcjdEFuyGFrwULOJVYCidq9a9Do 80jg== X-Gm-Message-State: APjAAAWiUe0TKK0PMqhLA0iOrsKh1hsxHukFPEcXK7T0Hq6hhVNgyHtF ueqFD1DkjNf4Ot3W1A50jBojYFeCz7pdFEmhLdEYn/ts X-Google-Smtp-Source: APXvYqzsSFy96zzf62L6ibE39cs8KRto6REzmNoyWP4MmyaLorg6kjkWD7Jznnoy7840m1VIrHzZ3C+/1EF2JfWLqqc= X-Received: by 2002:a2e:94c8:: with SMTP id r8mr2880376ljh.28.1581390297546; Mon, 10 Feb 2020 19:04:57 -0800 (PST) MIME-Version: 1.0 References: <158109575881.11589.7522751407809468206.idtracker@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Mon, 10 Feb 2020 21:04:30 -0600 Message-ID: Subject: Fwd: WG Review: QUIC (quic) To: IESG Cc: IETF QUIC WG , quic-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000efc3b0059e441e6b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 03:05:03 -0000 --000000000000efc3b0059e441e6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear IESG, I sent this to IESG-Secretary, which is where replies to announcements from the datatracker go, and Cindy asked me to send it to you, so that someone besides Cindy would see it :-) Best, Spencer ---------- Forwarded message --------- From: Spencer Dawkins at IETF Date: Mon, Feb 10, 2020 at 3:35 PM Subject: Re: WG Review: QUIC (quic) To: The IESG Cc: IETF QUIC WG Dear IESG, I don't have any concerns about the direction for this charter, but I do have some suggestions on wording. Best, Spencer On Fri, Feb 7, 2020 at 11:16 AM The IESG wrote: > The QUIC (quic) WG in the Transport Area of the IETF is undergoing > rechartering. The IESG has not made any determination yet. The following > draft charter was submitted, and is provided for informational purposes > only. > Please send your comments to the IESG mailing list (iesg@ietf.org) by > 2020-02-17. > > QUIC (quic) > ----------------------------------------------------------------------- > Current status: Active WG > > Chairs: > Mark Nottingham > Lars Eggert > Lucas Pardue > > Assigned Area Director: > Magnus Westerlund > > Transport Area Directors: > Mirja K=C3=BChlewind > Magnus Westerlund > > Mailing list: > Address: quic@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/quic > Archive: https://mailarchive.ietf.org/arch/browse/quic/ > > Group page: https://datatracker.ietf.org/group/quic/ > > Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/ > > The QUIC working group will provide standards-track specifications for a > UDP-based, stream-multiplexing, encrypted transport protocol, based on > pre-standardization implementation and deployment experience. > > Key goals for QUIC are: > I'm wondering when these change from goals to attributes, but maybe the next major revision is the right time ... > - Minimizing connection establishment and overall transport latency for > applications, starting with HTTP; > > - Providing multiplexing without head-of-line blocking; > > - Requiring only changes to path endpoints to enable deployment; > > - Enabling multipath and forward error correction extensions; and > > - Providing always-secure transport, using TLS 1.3 by default. > > The work of the group will have five main focus areas, corresponding to > five > core deliverables. > > The first of these is the core transport work, which will describe the wi= re > I wonder when the charter moves from future tense (which was accurate in 2016) to present tense, but perhaps after version 1 is complete would be a good time. > format, along with the mechanisms for connection establishment, stream > multiplexing, data reliability, loss detection and recovery, congestion > control, and options negotiation. Work on congestion control will describ= e > use of a standardized congestion controller as a default scheme for QUIC. > Defining new congestion control schemes is explicitly out of scope for th= is > group. QUIC is expected to support rapid, distributed development and > testing > of features. > > The second of these focus areas is security. This work will describe how > the > protocol uses TLS 1.3 for key negotiation and will also describe how thos= e > keys are used to provide confidentiality and integrity protection of both > application data and QUIC headers. This work will ensure that QUIC has > security and privacy properties that are at least as good as a stack > composed > of TLS 1.3 using TCP (or MPTCP when using multipath). > > The third focus area describes the mapping between the HTTP application > protocol and the transport facilities of QUIC. This mapping will have > performance characteristics comparable with HTTP/2, and provide extension > mechanisms similar to HTTP/2. Upon completion of this mapping, work to > define > additional mappings may be included by updates to this charter, or may be > worked on by other working groups. > When QUIC was chartered, my hope (and I don't think I was the only one) was that we would end up with HTTP/2 over QUIC. For good reasons, we ended up with HTTP/3 over QUIC, and it seems odd that there's no mention of HTTP/3 in the 2020 QUIC charter, but it IS mentioned in https://datatracker.ietf.org/doc/charter-ietf-httpbis/. > The fourth focus area will be on extensions to core protocol facilities, = to > enable datagram delivery, version negotiation, and multipath capabilities= . > Other extensions are out of the scope of this charter. > > The fifth focus area will provide an Applicability and Manageability > Statement, describing how, and under what circumstances, QUIC may be safe= ly > used, and describing deployment and manageability implications of the > protocol. Additionally, the Working Group will provide guidance on how to > handle QUIC traffic in load balancers. > > Current practices for network management of transport protocols include t= he > ability to apply access control lists (ACLs), hashing of flows for > equal-cost > multipath routing (ECMP), directional signaling of flows, signaling of fl= ow > setup and teardown, and the ability to export information about flows for > accounting purposes. The QUIC protocol need not be defined to enable each > of > these abilities, or enable them in the same way as they are enabled by TC= P > when used with TLS 1.3, but the working group must consider the impact of > the > protocol on network management practices, reflecting the tensions describ= ed > in RFC 7258. > > 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. > This paragraph ^ was inserted to say "the way Google QUIC happens to work in 2016" (which was the only QUIC we had) "isn't binding on the working group producing IETF QUIC". That was worth saying in 2016 - and we might have said it more clearly - but in 2020, the obvious meaning of "current protocol mechanisms" is IETF QUICv1. I don't think this paragraph means anything helpful now, and anyone who tries to be guided by it, is probably headed into the weeds. I'd delete it. > The QUIC working group will work closely with the HTTPbis working group, > especially on the QUIC mapping for HTTP. > > Milestones: > > Jul 2020 - Core Protocol document to IESG > > Jul 2020 - Loss detection and Congestion Control document to IESG > > Jul 2020 - TLS 1.3 Mapping document to IESG > > Jul 2020 - HTTP/2 mapping document to IESG > > Jul 2020 - QUIC Applicability and Manageability Statement to IESG > Just making sure I understand - the load balancing advice would be included in this statement, is that right? Jul 2020 - Version-Independent Properties of QUIC to IESG > > Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG > > Dec 2020 - Working group adoption of Multipath extension document > > Mar 2021 - Datagram Extension to IESG > > Mar 2021 - Version Negotiation Extension to IESG > > Dec 2021 - Multipath extension document to IESG > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --000000000000efc3b0059e441e6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear IESG,

I sent this to IESG-Secretar= y, which is where replies to announcements from the datatracker go, and Cin= dy asked me to send it to you, so that someone besides Cindy would see it := -)

Best,

Spencer

<= div class=3D"gmail_quote">
---------- = Forwarded message ---------
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com= >
Date: Mon, Feb 10, 2020 at 3:35 PM
Subject: Re: WG Review= : QUIC (quic)
To: The IESG <iesg-secretary@ietf.org>
Cc: IETF QUIC WG <quic@ietf.org>


Dear IESG,=C2=A0

I don't have any concerns a= bout the direction for this charter, but I do have some suggestions on word= ing.=C2=A0

Best,

Spencer<= /div>
O= n Fri, Feb 7, 2020 at 11:16 AM The IESG <iesg-secretary@ietf.org> wrote:
The QUIC (quic) WG in = the Transport Area of the IETF is undergoing
rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes onl= y.
Please send your comments to the IESG mailing list (iesg@ietf.org) by
2020-02-17.

QUIC (quic)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
=C2=A0 Mark Nottingham <mnot@mnot.net>
=C2=A0 Lars Eggert <lars@eggert.org>
=C2=A0 Lucas Pardue <lucaspardue.24.7@gmail.com>

Assigned Area Director:
=C2=A0 Magnus Westerlund <magnus.westerlund@ericsson.com>

Transport Area Directors:
=C2=A0 Mirja K=C3=BChlewind <ietf@kuehlewind.net>
=C2=A0 Magnus Westerlund <magnus.westerlund@ericsson.com>

Mailing list:
=C2=A0 Address: quic@iet= f.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/listinfo= /quic
=C2=A0 Archive: https://mailarchive.ietf.org/arch/brow= se/quic/

Group page: https://datatracker.ietf.org/group/quic/

Charter: https://datatracker.ietf.org/doc/charter= -ietf-quic/

The QUIC working group will provide standards-track specifications for a UDP-based, stream-multiplexing, encrypted transport protocol, based on
pre-standardization implementation and deployment experience.

Key goals for QUIC are:

I'm wonderi= ng when these change from goals to attributes, but maybe the next major rev= ision is the right time ...
=C2=A0
=C2=A0- Minimizing connection establishment and ov= erall transport latency for
=C2=A0applications, starting with HTTP;

=C2=A0- Providing multiplexing without head-of-line blocking;

=C2=A0- Requiring only changes to path endpoints to enable deployment;

=C2=A0- Enabling multipath and forward error correction extensions; and

=C2=A0- Providing always-secure transport, using TLS 1.3 by default.

The work of the group will have five main focus areas, corresponding to fiv= e
core deliverables.

The first of these is the core transport work, which will describe the wire=

I wonder when the charter moves from f= uture tense (which was accurate in 2016) to present tense, but perhaps afte= r version 1 is complete would be a good time.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> format, along with the mechanisms for connection establishment, stream
multiplexing, data reliability, loss detection and recovery, congestion
control, and options negotiation. Work on congestion control will describe<= br> use of a standardized congestion controller as a default scheme for QUIC. Defining new congestion control schemes is explicitly out of scope for this=
group. QUIC is expected to support rapid, distributed development and testi= ng
of features.

The second of these focus areas is security. This work will describe how th= e
protocol uses TLS 1.3 for key negotiation and will also describe how those<= br> keys are used to provide confidentiality and integrity protection of both application data and QUIC headers. This work will ensure that QUIC has
security and privacy properties that are at least as good as a stack compos= ed
of TLS 1.3 using TCP (or MPTCP when using multipath).

The third focus area describes the mapping between the HTTP application
protocol and the transport facilities of QUIC. This mapping will have
performance characteristics comparable with HTTP/2, and provide extension mechanisms similar to HTTP/2. Upon completion of this mapping, work to defi= ne
additional mappings may be included by updates to this charter, or may be worked on by other working groups.

When= QUIC was chartered, my hope (and I don't think I was the only one) was= that we would end up with HTTP/2 over QUIC. For good reasons, we ended up = with HTTP/3 over QUIC, and it seems odd that there's no mention of HTTP= /3 in the 2020 QUIC charter, but it IS mentioned in=C2=A0https://= datatracker.ietf.org/doc/charter-ietf-httpbis/.=C2=A0
=C2=A0<= /div>
The fourth focus are= a will be on extensions to core protocol facilities, to
enable datagram delivery, version negotiation, and multipath capabilities.<= br> Other extensions are out of the scope of this charter.

The fifth focus area will provide an Applicability and Manageability
Statement, describing how, and under what circumstances, QUIC may be safely=
used, and describing deployment and manageability implications of the
protocol. Additionally, the Working Group will provide guidance on how to handle QUIC traffic in load balancers.

Current practices for network management of transport protocols include the=
ability to apply access control lists (ACLs), hashing of flows for equal-co= st
multipath routing (ECMP), directional signaling of flows, signaling of flow=
setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each o= f
these abilities, or enable them in the same way as they are enabled by TCP<= br> when used with TLS 1.3, but the working group must consider the impact of t= he
protocol on network management practices, reflecting the tensions described=
in RFC 7258.

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.

This paragraph ^ was inserted to say "the way Goo= gle QUIC happens to work in 2016" (which was the only QUIC we had) &qu= ot;isn't binding on the working group producing IETF QUIC". That w= as worth saying in 2016 - and we might have said it more clearly - but in 2= 020, the obvious meaning of "current protocol mechanisms" is IETF= QUICv1. I don't think this paragraph means anything helpful now, and a= nyone who tries to be guided by it, is probably headed into the weeds. I= 9;d delete it.=C2=A0
=C2=A0
The QUIC working group will work closely with the HTTPbis= working group,
especially on the QUIC mapping for HTTP.

Milestones:

=C2=A0 Jul 2020 - Core Protocol document to IESG

=C2=A0 Jul 2020 - Loss detection and Congestion Control document to IESG
=C2=A0 Jul 2020 - TLS 1.3 Mapping document to IESG

=C2=A0 Jul 2020 - HTTP/2 mapping document to IESG

=C2=A0 Jul 2020 - QUIC Applicability and Manageability Statement to IESG

Just making sure I understand - the load = balancing advice would be included in this statement, is that right?=C2=A0<= /div>

=C2= =A0 Jul 2020 - Version-Independent Properties of QUIC to IESG

=C2=A0 Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG

=C2=A0 Dec 2020 - Working group adoption of Multipath extension document
=C2=A0 Mar 2021 - Datagram Extension to IESG

=C2=A0 Mar 2021 - Version Negotiation Extension to IESG

=C2=A0 Dec 2021 - Multipath extension document to IESG


_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--000000000000efc3b0059e441e6b-- From nobody Tue Feb 11 00:35:25 2020 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 E44331201E3 for ; Tue, 11 Feb 2020 00:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 KG3zbt62aKyU for ; Tue, 11 Feb 2020 00:35:21 -0800 (PST) Received: from vs25.mail.saunalahti.fi (vs25.mail.saunalahti.fi [62.142.117.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0873D120091 for ; Tue, 11 Feb 2020 00:35:21 -0800 (PST) Received: from vs25.mail.saunalahti.fi (localhost [127.0.0.1]) by vs25.mail.saunalahti.fi (Postfix) with ESMTP id 3BF3520F4D; Tue, 11 Feb 2020 10:35:18 +0200 (EET) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs25.mail.saunalahti.fi (Postfix) with ESMTP id 30B6D20F1C; Tue, 11 Feb 2020 10:35:18 +0200 (EET) Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw01.mail.saunalahti.fi (Postfix) with ESMTPSA id 105AD40005; Tue, 11 Feb 2020 10:35:12 +0200 (EET) Received: from dhcp-100-247.eduroam.aalto.fi (dhcp-100-247.eduroam.aalto.fi [130.233.100.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 481C36163A4; Tue, 11 Feb 2020 10:35:05 +0200 (EET) From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_CFD1F578-C992-4D65-838C-49BAEFAE69D7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt Date: Tue, 11 Feb 2020 10:35:04 +0200 In-Reply-To: <180dde305bf149efb19a88e61967a87a@ustx2ex-dag1mb5.msg.corp.akamai.com> Cc: IETF QUIC WG , HAMCHAOUI Isabelle IMT/OLN , "alexandre.ferrieux@orange.com" , Dmitri Tikhonov To: "Lubashev, Igor" References: <157921301012.26216.13677469865378306147.idtracker@ietfa.amsl.com> <180dde305bf149efb19a88e61967a87a@ustx2ex-dag1mb5.msg.corp.akamai.com> X-MailScanner-ID: 481C36163A4.A3CDA X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 08:35:23 -0000 --Apple-Mail=_CFD1F578-C992-4D65-838C-49BAEFAE69D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, (chair hat off) the draft points to the CONEX work and says this: This loss signaling is similar to loss signaling in [RFC7713], except the Loss Event bit is reporting the exact number of lost packets, whereas the Echo Loss bit in [RFC7713] is reporting an approximate number of lost bytes. What it doesn't say is why the CONEX functionality is being proposed to = be incorporated into QUIC, rather than staying at the IP level where it = arguably belongs? Thanks, Lars --Apple-Mail=_CFD1F578-C992-4D65-838C-49BAEFAE69D7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl5CZzgACgkQVLXDCb9w wVdCwRAAsOHu1dcX7bz0VwtsF8QYLkVfr53lIAcJSYy8G19X0rXd/x1cXQwM8ejd qjzPEupxYQ6QGcWSIHzMvZu58KYpiFKOdw4ZQXqTV9PMqKQXZ/kDiwOthQTJJf67 gZNMpzMR2kOrbHh7AHEz8yAHMsHhHVBc9p8nRJtV6ctSZ1rcmGufbIa0R7ZnpUtW 3bPPtcSzFREvdTUnAmkB/tyzlJzjdUOrM+YC9n3eX2vyYL0WQ+ZwDzS7eoK+j9jv owH+Kn0Wm7o2GoqQEUJIHJF7nHXc6YziKSYO0hJIJb+8x8g0v2ZhmQBPmF8QjFIn 8G4ezDdcpRpFhYRmPYDBje7bfsJBsnKQg0JcqCZ/4yd3CE6dSDuPJBXtxDS/Ru8j aVhSZTs4OuDA8siTLxSI6Zpgq87WjdoJpQK8jMo4xxIpPjauGPazuwhDSF9L2kZO z/ySubRh8YojZpPvidXBTy6ianl9n8ar6ycrQcpBdQsIyitdI2Uzu+AGhlD46L6q iO+c0FM7fCpVuKfJVC7c2nl+Yfuv+kCR8LIa83S3YfAXmg0Of5O8TZsG7xN3N25i zSau+VoIyXmWjli5S99BgOF8xPIjP538WUcwhw+42Yroao88hbHlHEeKWdDuGIlD ybtbGtDnPyvHTvFZHQ9wtYhan8bBbqZQz/49PiOZnRau6K5Jjww= =TlxF -----END PGP SIGNATURE----- --Apple-Mail=_CFD1F578-C992-4D65-838C-49BAEFAE69D7-- From nobody Tue Feb 11 01:35:12 2020 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 3C4191201E0 for ; Tue, 11 Feb 2020 01:35:11 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 (1024-bit key) header.d=ericsson.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 ZLwqGnF2FG9r for ; Tue, 11 Feb 2020 01:35:09 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2055.outbound.protection.outlook.com [40.107.22.55]) (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 7FE58120020 for ; Tue, 11 Feb 2020 01:35:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nnvOAzb/ZRTDogV8xeVXp4e5YXJ4p8R1NOKWcoaLbCFaQo91Pj81TqografH9QB7jqAAMzwVNCB2mQCdxtUtqMqk9rjJs0XggoNxapfP9QK6cJA50AjuiefiVfHEJtyYmsO9R9L6CPOdmzlvJ1BmtxH4hFvyh3PEMPGJ0QtX8Ndw9tzNjGm8yAR0R5yP2DNWCFSdtT8j7phupB03HGxYLI6L7dlwmO3z/6yC4vk/YiEsRv97b+4kPw84K92JwmGUctbTmKN8m07fyMHKlaiB7eLdwPQ7hzVb05V7asEwyYUvvS0WHOC0EatXnvz6+grJ+ploTyCubkU45TPh6yCbQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0uzlHZWlSn9ayHvQcXjXqJUT+ryKrySb37uR5ps0UHg=; b=QXIYtww3KI2nOnL3inV/aDlzKWzjdWJMX9Omf7lKV3mFxRRH6+y1hlZF7XkQUGX9rpAPylj6JiciNPaiLIdrKURiPJDZLpi30TUO+KjMzeibh6ggLddP3bCf6nShrbtdg0EM8/z3yCWk0anAnLCSLGRPBxtyD4LDmoH4Vi2HQsaD6eLXrZgxGjGe0n77/jRQ97kgYCeM/5rM8cEBtQP2iT+n71WTnnire+e5B25TZcx8NHejA8mMJ81JbKmAp3eQkKqzbckuBgoCoUpmWAFAxdcuFCIa+M/nj5RiNMpxscoIGyUkcXkVXUENf3dJTXfNU6GBRV2FJjysscc7afjbIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0uzlHZWlSn9ayHvQcXjXqJUT+ryKrySb37uR5ps0UHg=; b=X55mXqQB+zckcEJN0+8k3R9P92UH/ChjKVXAYi2YWT4Qy6dO4oO7MWO+yI9kFx+oeUNzhyvtq4xPgRdxmI5is7pSnv4n8yqbuDtEp4duFkPd12o6T0T08DO8i3s7xDBxmSOA8Fr4OO0TNhZ2GsZgIIoBdzgxgL/n0nY94V9nDxU= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB4162.eurprd07.prod.outlook.com (52.133.55.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.16; Tue, 11 Feb 2020 09:35:06 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4879:46ae:16e:f5b7]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4879:46ae:16e:f5b7%7]) with mapi id 15.20.2729.021; Tue, 11 Feb 2020 09:35:06 +0000 From: Mirja Kuehlewind To: Martin Duke CC: IETF QUIC WG Subject: Re: New Version Notification for draft-duke-quic-natsupp-00.txt Thread-Topic: New Version Notification for draft-duke-quic-natsupp-00.txt Thread-Index: AQHV1gjboi/pVkkeTEm5AkAzYIUU46gBcaSAgABwEYCAASk+gIAR8O0AgADl5oA= Date: Tue, 11 Feb 2020 09:35:06 +0000 Message-ID: <571B2506-AA27-411A-AE5D-D0E780FD889B@ericsson.com> References: <157470946896.14159.17248985824634821547.idtracker@ietfa.amsl.com> <6A334674-0D30-4FB6-A4BE-4D2BBAF344A4@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; x-originating-ip: [2001:16b8:2c13:d000:7056:c073:a2e2:17e4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3e9e899f-f029-4dbc-6823-08d7aed5adbf x-ms-traffictypediagnostic: AM0PR07MB4162: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0310C78181 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(366004)(39860400002)(376002)(346002)(199004)(189003)(86362001)(6506007)(53546011)(186003)(33656002)(8936002)(15650500001)(478600001)(5660300002)(6916009)(91956017)(66556008)(6486002)(71200400001)(66946007)(66476007)(76116006)(64756008)(66446008)(316002)(8676002)(36756003)(6512007)(81166006)(2616005)(81156014)(2906002)(44832011)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4162; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MSLHCaCzI9C8LJ8sUGgQG7Di/fj+FNoeAoh+y5In2Xeu5V/H8WMb4HeebqXek0I6XRWCJrEyGEgL0M9cKEEFFnsgohViD8FcS0nGp2RGLZK5e/ZmcG6Xr654b2kxmzcMGuw1VhkMcB4+m7riT85hjTcrab6HCc6X+dZ0R/CAE1cvpuZ43WoFHbBSHs0fK4yBR+WrZQPm4XvIAqS+OFOTfqv1OsH8v12womW1OyWh3d/sHd7DfOKJFJbaTnpW6KC41NKsOc/WM653J45BYm/91yOFakv1yEdzChXgrnpaKW1KnehHfWMJqeiTtUH6uNZZZasMjxNsADlY+NtWoVah1SVt9517nH7ggSBBCVquVt4y/ZN7Mr3ugTVBnaV3zOFp7TDWa33i43/TwiKukryDR6G+gVCYoKVA4eukFbIn80YRVMIfQj/cG8bl61dWe42A x-ms-exchange-antispam-messagedata: kwuCbBRBRTfhdo0IT4sg3y74+Ki43PBWE1hrLmFe1rCfNuZhMIbAILScxx215iJhwgzJOdq3uMvzMf9JywMBD5mCoO9XyAChqZ9nEYTPB4yGT+vw2JuYZsDLDgXiyLjHGYM8bioXHROYpAm4n/qwwx9Dor2Sb4ZDG6S49+XsRQU/Fkz3fDPaQjYPrWDnBF57PvkQQuo+JpVP/0hh3hGQIA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_571B2506AA27411AAE5DD0E780FD889Bericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e9e899f-f029-4dbc-6823-08d7aed5adbf X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2020 09:35:06.1904 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VWM8ksgLkapfCYmvDqP0sy7cVPqr+nZpuzCAG6DNuFjUHIiIKh6arFvhPQsdvERu0/WvFjEOeQ3sh7T5iAx5ywAAFatdEX4CNCVQWyBC61w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4162 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 09:35:11 -0000 --_000_571B2506AA27411AAE5DD0E780FD889Bericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluLA0KDQpzaG9ydCByZXBseTogc291bmRzIGdvb2QhIE90aGVyd2lzZSBzZWUgaW5s aW5lLg0KDQpNaXJqYQ0KDQpGcm9tOiBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5j b20+DQpEYXRlOiBNb25kYXksIDEwLiBGZWJydWFyeSAyMDIwIGF0IDIxOjUyDQpUbzogTWlyamEg S3VlaGxld2luZCA8bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20+DQpDYzogSUVURiBRVUlD IFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtZHVrZS1xdWljLW5hdHN1cHAtMDAudHh0DQoNClJlc3BvbnNlcyBpbmxpbmU6 DQoNCk9uIFRodSwgSmFuIDMwLCAyMDIwIGF0IDEwOjUzIEFNIE1pcmphIEt1ZWhsZXdpbmQgPG1p cmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPG1haWx0bzptaXJqYS5rdWVobGV3aW5kQGVyaWNz c29uLmNvbT4+IHdyb3RlOg0KDQpJIHNvbWVob3cgd2FzIGluaXRpYWxseSBvbmx5IHRoaW5rIGFi b3V0IG91dC1nb2luZyBwYWNrZXQgYW5kIG5vIGluY29taW5nIHBhY2tldHPigKYgc28sIHllcywg dGhlIE5BVCBuZWVkcyB0byBkaXNjYXJkIHRoaXMgcGFja2V0LiBIb3dldmVyLCB5b3Ugc2F5IHRo ZSBOQVQgaXMgb3V0IG9mIGFkZHJlc3Nlcy9wb3J0cywgdGh1cyBub3QgdXNpbmcgdGhlIENJRCB3 b3VsZCBoYXZlIG1lYW50IHRoYXQgaXQgd291bGQgaGF2ZSB0byBkaXNjYXJkIHRoZSBjb25uZWN0 aW9uIHJpZ2h0IGF0IHRoZSBiZWdpbm5pbmcuIE5vdCBzdXJlIGlmIHRoYXQgaXMgYW55IGJldHRl cuKApj8NCg0KSXQncyBhIGdvb2QgcG9pbnQgdGhhdCBpbW1lZGlhdGVseSBkcm9wcGluZyBpcyBu b3QgZ3JlYXQgZWl0aGVyLiBIb3dldmVyLA0KwrcgICAgICAgICB0aGlzIHdvdWxkIGNyZWF0ZSBh biBvc3NpZmljYXRpb24gdmVjdG9yIHdoZXJlIENJRCBjaGFuZ2VzIG1heSBicmVhayB0aGUgcHJv dG9jb2wuDQrCtyAgICAgICAgIGl0J3MgYmV0dGVyIGZvciBRVUlDIHRvIGZhaWwgcmlnaHQgYXdh eSAoZW5hYmxpbmcgVENQIGZhbGxiYWNrKSB0aGFuIHRvIGJsYWNrIGhvbGUgc3VkZGVubHkuDQpb TUtdIFJpZ2h0LCB0aGUgc2Vjb25kIHBvaW50IGhlcmUgaXMgYWN0dWFsbHkgaW1wb3J0YW50LiBQ cm9iYWJseSBhbHNvIHNvbWV0aGluZyB0byBtZW50aW9uIGluIHRoZSBkcmFmdC4NCg0KDQpTZWN0 aW9uIDQuMi4NCi0gU2VydmVyIGRlcGxveW1lbnQgaGFzIDQtdHVwbGUgcm91dGluZyBhbmQgaXQg aXMgZXhwZW5zaXZlIHRvIGNoYW5nZQ0KLSBJVCBpbnN0YWxscyBhIE5BVCBhdCB0aGUgZnJvbnQg b2YgdGhlIGluZnJhc3RydWN0dXJlIHRoYXQgc3RvcmVzIGEgbWFwcGluZyBvZiBDSURzIHRvIGlu Ym91bmQgc291cmNlIGFkZHJlc3MgYW5kIHBvcnQuDQoNClRoaXMgc3RlcCB3YXMgYWxzbyBub3Qg ZnVsbHkgY2xlYXIgdG8gbWUgZnJvbSB0aGUgZHJhZnQuIE5vdyB0aGF0IEkgbG9vayBhdCBpdCBh Z2FpbiwgSSB1bmRlcnN0YW5kIHdoYXTigJlzIG1lYW50IGJ1dCBJIHRoaW5rIGl0IGNvdWxkIGJl IGNsZWFyZXIgaW4gdGhlIGRyYWZ0Lg0KDQpTbyBpcyA0LXR1cGxlIHJvdXRpbmcgYWN0dWFsbHkg Y29tbW9uPyBXaHkgaXMgdGhlIDQtdHVwbGUgdXNlZCBpbnN0ZWFkIG9mIG9ubHkgcm91dGluZyBi YXNlZCBvbiB0aGUgZGVzdGluYXRpb24gYWRkcmVzcy9wb3J0Pw0KDQpZZXMgaXQncyBjb21tb24u IElmIHdlJ3JlIGZyb250aW5nIGEgc2luZ2xlIHdlYnNpdGUgdGhlcmUgbWF5IGJlIGEgc2luZ2xl IGRlc3RpbmF0aW9uIElQIGFuZCB3ZWxsLWtub3duIHBvcnQsIHNvIHRoZSBkZXN0aW5hdGlvbiBk b2Vzbid0IGFkZCBhbnkgZW50cm9weS4NCg0KW01LXSBUaGF0IG1ha2VzIHNlbnNlLg0KDQoNCi0g SWYgYSBwYWNrZXQgYXJyaXZlcyB3aXRoIGEga25vd24gQ0lEIGJ1dCBhIGRpZmZlcmVudCBzb3Vy Y2UgYWRkcmVzcy9wb3J0LCB0aGUgTkFUIHdpbGwgcmV3cml0ZSB0aGUgc291cmNlL2FkZHJlc3Mg cG9ydCB0byB0aGUgb2xkIHZhbHVlLCBhbmQgdGh1cyB0aGUgcGFja2V0IHdpbGwgcm91dGUgdG8g dGhlIGNvcnJlY3QgYmFjay1lbmQgc2VydmVyLiBUaHVzIHRoZSBpbmZyYXN0cnVjdHVyZSBpcyBy b2J1c3QgdG8gTkFUIHJlYmluZGluZywgaWYgbm90IGludGVudGlvbmFsIG1pZ3JhdGlvbiB3aXRo IGEgbmV3IENJRC4NCi0gV2hpbGUgdGhpcyAid29ya3MiLCBpdCBoYXMgc2VjdXJpdHkgaW1wbGlj YXRpb25zIGFzIGRpc2N1c3NlZC4NCg0KSSB0aGluayB5b3UgbmVlZCB0byBmdXJ0aGVyIGV4cGxh aW4gdGhlIGF0dGFjayBjYXNlIGhlcmUgaW4gdGhlIGRyYWZ0IOKAkyB0aGF0IGFuIGF0dGFja2Vy IG1pZ2h0IHNwb29mIHRoZSBJUCBhZGRyZXNzIGFuZCB0aGVyZWZvcmUgY2FuIEREb1MgYSB0YXJn ZXQgYXMgdGhlIHNlcnZlciBtaWdodCBrZWVwIHNlbmRpbmcgYSBsYXJnZSBhbW91bnQgb2YgZGF0 YSB0byB0aGF0IG5ldyBJUCBhZGRyZXNzLiBIb3dldmVyLCBJIHRoaW5rIHRoaXMgc2hvdWxkIHBy b2JhYmx5IGJlIGRpc2N1c3NlZCBpbiB0aGUgc2VjdXJpdHkgc2VjdGlvbiBvZiB0aGUgdHJhbnNw b3J0IGRyYWZ0IGEgYml0IG1vcmUgYXMgdGhpcyBpcyBvbmx5IHBvc3NpYmxlIGJlY2F1c2Ugb2Yg bWlncmF0aW9uIHdoaWNoIGlzIGEgbmV3IGZlYXR1cmUgaW4gUVVJQy4NCg0KSSBiZWxpZXZlIEVy aWMgS2lubmVhciBoYXMgYWxyZWFkeSB3cml0dGVuIGEgdG9uIGFib3V0IGhvdyB0byBoYW5kbGUg bmV3IGFkZHJlc3NlcyBpbiB0aGUgdHJhbnNwb3J0IGRyYWZ0LiBJJ2xsIHJld3JpdGUgdGhlIHBh cmFncmFwaCBhcyB5b3Ugc3VnZ2VzdC4NCg0KW01LXSBUaGFua3MhDQoNCkhvd2V2ZXIsIGdpdmVu IHRoYXQgaWYgc29tZW9uZSBhbnl3YXkgZGVjaWRlZCB0byBpbXBsZW1lbnQgdGhpcyBzZXR1cCwg dGhlIGVuZHBvaW50cyBoYXZlIG5vIHdheSB0byBkZXRlY3QgdGhhdCBhbiBhZGRyZXNzIGNoYW5n ZWQgYW5kIHdhcyByZXNwZWN0aXZlbHkgcmUtd3JpdHRlbiB0aGVuIGFnYWluLCBzaG91bGQgd2Ug bWF5YmUgc3RhcnQgdGhpbmsgYWJvdXQgYSB3YXkgdG8gaW1wcm92ZSB0aGUgc2l0dWF0aW9u4oCm Pw0KDQpUaGUgc2lnbmFsIGhlcmUgaXMgdGhhdCBhYnNvbHV0ZWx5IG5vdGhpbmcgaW4gdGhlIHBh Y2tldCBoYXMgY2hhbmdlZCwgc28gSSdtIG5vdCBzdXJlIGhvdyBlbmRwb2ludHMgY291bGQgcG9z c2libHkgZGV0ZWN0IHRoaXMuDQpZZXMsIGJ1dCBtYXliZSB0aGVyZSBhcmUgb3RoZXIgdGhpbmdz LiBOb3QgcHJvcG9zaW5nIHRoaXMgYXMgYSBzb2x1dGlvbiBidXQgZS5nLiBvbmUgY291bGQgZGV0 ZWN0IGFuIGFkZHJlc3MgY2hhbmdlIHVzaW5nIFRVUk7igKYgYW55d2F5IEkgZ3Vlc3MgeW91IGFy ZSByaWdodCB0aGF0IHRoZXJlIGlzIG5vdCBlYXN5IHdheeKApg0KDQo= --_000_571B2506AA27411AAE5DD0E780FD889Bericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <52C6842078CCC34FA9D58EC8FE86CB29@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjk4MDIyNzQ5MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 Mzk4NDk4MDYyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1ERSIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkg TWFydGluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkRFIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPnNob3J0IHJlcGx5OiBzb3VuZHMg Z29vZCEgT3RoZXJ3aXNlIHNlZSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+TWlyamE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+TWFydGluIER1a2UgJmx0O21hcnRpbi5oLmR1a2VAZ21haWwu Y29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIDEwLiBGZWJydWFyeSAyMDIwIGF0IDIx OjUyPGJyPg0KPGI+VG86IDwvYj5NaXJqYSBLdWVobGV3aW5kICZsdDttaXJqYS5rdWVobGV3aW5k QGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPklFVEYgUVVJQyBXRyAmbHQ7cXVpY0Bp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtZHVrZS1xdWljLW5hdHN1cHAtMDAudHh0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+UmVzcG9uc2Vz IGlubGluZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIFRo dSwgSmFuIDMwLCAyMDIwIGF0IDEwOjUzIEFNIE1pcmphIEt1ZWhsZXdpbmQgJmx0OzxhIGhyZWY9 Im1haWx0bzptaXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbSI+bWlyamEua3VlaGxld2luZEBl cmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SSBzb21l aG93IHdhcyBpbml0aWFsbHkgb25seSB0aGluayBhYm91dCBvdXQtZ29pbmcgcGFja2V0IGFuZCBu byBpbmNvbWluZyBwYWNrZXRz4oCmIHNvLCB5ZXMsIHRoZSBOQVQgbmVlZHMgdG8gZGlzY2FyZCB0 aGlzIHBhY2tldC4gSG93ZXZlciwgeW91IHNheSB0aGUgTkFUIGlzIG91dCBvZiBhZGRyZXNzZXMv cG9ydHMsIHRodXMgbm90IHVzaW5nIHRoZSBDSUQgd291bGQgaGF2ZSBtZWFudCB0aGF0IGl0IHdv dWxkIGhhdmUNCiB0byBkaXNjYXJkIHRoZSBjb25uZWN0aW9uIHJpZ2h0IGF0IHRoZSBiZWdpbm5p bmcuIE5vdCBzdXJlIGlmIHRoYXQgaXMgYW55IGJldHRlcuKApj88L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPkl0J3MgYSBnb29kIHBvaW50IHRoYXQgaW1tZWRpYXRlbHkg ZHJvcHBpbmcgaXMgbm90IGdyZWF0IGVpdGhlci4gSG93ZXZlciwNCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJv bCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPnRo aXMgd291bGQgY3JlYXRlIGFuIG9zc2lmaWNhdGlvbiB2ZWN0b3Igd2hlcmUgQ0lEIGNoYW5nZXMg bWF5IGJyZWFrIHRoZSBwcm90b2NvbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5pdCdzIGJldHRlciBmb3IgUVVJQyB0byBmYWlsIHJpZ2h0 IGF3YXkgKGVuYWJsaW5nIFRDUCBmYWxsYmFjaykgdGhhbiB0byBibGFjayBob2xlIHN1ZGRlbmx5 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPltNS10gUmlnaHQsIHRoZSBzZWNvbmQgcG9pbnQgaGVyZSBpcyBhY3R1 YWxseSBpbXBvcnRhbnQuIFByb2JhYmx5IGFsc28gc29tZXRoaW5nIHRvIG1lbnRpb24gaW4gdGhl IGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQi Pg0KU2VjdGlvbiA0LjIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCi0gU2VydmVyIGRlcGxveW1lbnQgaGFz IDQtdHVwbGUgcm91dGluZyBhbmQgaXQgaXMgZXhwZW5zaXZlIHRvIGNoYW5nZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Ojcy LjBwdCI+DQotIElUIGluc3RhbGxzIGEgTkFUIGF0IHRoZSBmcm9udCBvZiB0aGUgaW5mcmFzdHJ1 Y3R1cmUgdGhhdCBzdG9yZXMgYSBtYXBwaW5nIG9mIENJRHMgdG8gaW5ib3VuZCBzb3VyY2UgYWRk cmVzcyBhbmQgcG9ydC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIHN0ZXAg d2FzIGFsc28gbm90IGZ1bGx5IGNsZWFyIHRvIG1lIGZyb20gdGhlIGRyYWZ0LiBOb3cgdGhhdCBJ IGxvb2sgYXQgaXQgYWdhaW4sIEkgdW5kZXJzdGFuZCB3aGF04oCZcyBtZWFudCBidXQgSSB0aGlu ayBpdCBjb3VsZCBiZSBjbGVhcmVyIGluIHRoZSBkcmFmdC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj5TbyBpcyA0LXR1cGxl IHJvdXRpbmcgYWN0dWFsbHkgY29tbW9uPyBXaHkgaXMgdGhlIDQtdHVwbGUgdXNlZCBpbnN0ZWFk IG9mIG9ubHkgcm91dGluZyBiYXNlZCBvbiB0aGUgZGVzdGluYXRpb24gYWRkcmVzcy9wb3J0Pzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+WWVzIGl0J3MgY29tbW9uLiBJ ZiB3ZSdyZSBmcm9udGluZyBhIHNpbmdsZSB3ZWJzaXRlIHRoZXJlIG1heSBiZSBhIHNpbmdsZSBk ZXN0aW5hdGlvbiBJUCBhbmQgd2VsbC1rbm93biBwb3J0LCBzbyB0aGUgZGVzdGluYXRpb24gZG9l c24ndCBhZGQgYW55IGVudHJvcHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkRFIj5bTUtdIFRoYXQgbWFrZXMgc2Vuc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KLSBJZiBhIHBhY2tldCBhcnJpdmVzIHdpdGggYSBr bm93biBDSUQgYnV0IGEgZGlmZmVyZW50IHNvdXJjZSBhZGRyZXNzL3BvcnQsIHRoZSBOQVQgd2ls bCByZXdyaXRlIHRoZSBzb3VyY2UvYWRkcmVzcyBwb3J0IHRvIHRoZSBvbGQgdmFsdWUsIGFuZCB0 aHVzIHRoZSBwYWNrZXQgd2lsbCByb3V0ZSB0byB0aGUgY29ycmVjdCBiYWNrLWVuZCBzZXJ2ZXIu IFRodXMgdGhlIGluZnJhc3RydWN0dXJlIGlzIHJvYnVzdCB0byBOQVQgcmViaW5kaW5nLCBpZg0K IG5vdCBpbnRlbnRpb25hbCBtaWdyYXRpb24gd2l0aCBhIG5ldyBDSUQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0 Ij4NCi0gV2hpbGUgdGhpcyAmcXVvdDt3b3JrcyZxdW90OywgaXQgaGFzIHNlY3VyaXR5IGltcGxp Y2F0aW9ucyBhcyBkaXNjdXNzZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SSB0 aGluayB5b3UgbmVlZCB0byBmdXJ0aGVyIGV4cGxhaW4gdGhlIGF0dGFjayBjYXNlIGhlcmUgaW4g dGhlIGRyYWZ0IOKAkyB0aGF0IGFuIGF0dGFja2VyIG1pZ2h0IHNwb29mIHRoZSBJUCBhZGRyZXNz IGFuZCB0aGVyZWZvcmUgY2FuIEREb1MgYSB0YXJnZXQgYXMgdGhlIHNlcnZlciBtaWdodCBrZWVw IHNlbmRpbmcgYSBsYXJnZSBhbW91bnQgb2YgZGF0YSB0byB0aGF0IG5ldyBJUCBhZGRyZXNzLiBI b3dldmVyLCBJDQogdGhpbmsgdGhpcyBzaG91bGQgcHJvYmFibHkgYmUgZGlzY3Vzc2VkIGluIHRo ZSBzZWN1cml0eSBzZWN0aW9uIG9mIHRoZSB0cmFuc3BvcnQgZHJhZnQgYSBiaXQgbW9yZSBhcyB0 aGlzIGlzIG9ubHkgcG9zc2libGUgYmVjYXVzZSBvZiBtaWdyYXRpb24gd2hpY2ggaXMgYSBuZXcg ZmVhdHVyZSBpbiBRVUlDLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ SSBiZWxpZXZlIEVyaWMgS2lubmVhciBoYXMgYWxyZWFkeSB3cml0dGVuIGEgdG9uIGFib3V0IGhv dyB0byBoYW5kbGUgbmV3IGFkZHJlc3NlcyBpbiB0aGUgdHJhbnNwb3J0IGRyYWZ0LiBJJ2xsIHJl d3JpdGUgdGhlIHBhcmFncmFwaCBhcyB5b3Ugc3VnZ2VzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iREUiPltNS10gPC9zcGFuPjxzcGFuIGxhbmc9IkRFIj5UaGFua3MhPC9z cGFuPiZuYnNwOzxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2 LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SG93ZXZlciwgZ2l2ZW4gdGhhdCBpZiBzb21lb25l IGFueXdheSBkZWNpZGVkIHRvIGltcGxlbWVudCB0aGlzIHNldHVwLCB0aGUgZW5kcG9pbnRzIGhh dmUgbm8gd2F5IHRvIGRldGVjdCB0aGF0IGFuIGFkZHJlc3MgY2hhbmdlZCBhbmQgd2FzIHJlc3Bl Y3RpdmVseSByZS13cml0dGVuIHRoZW4gYWdhaW4sIHNob3VsZCB3ZSBtYXliZSBzdGFydCB0aGlu ayBhYm91dCBhIHdheSB0byBpbXByb3ZlIHRoZSBzaXR1YXRpb27igKY/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0K PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 NDIuMjVwdCI+DQpUaGUgc2lnbmFsIGhlcmUgaXMgdGhhdCBhYnNvbHV0ZWx5IG5vdGhpbmcgaW4g dGhlIHBhY2tldCBoYXMgY2hhbmdlZCwgc28gSSdtIG5vdCBzdXJlIGhvdyBlbmRwb2ludHMgY291 bGQgcG9zc2libHkgZGV0ZWN0IHRoaXMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlllcywgYnV0IG1heWJlIHRoZXJlIGFyZSBvdGhl ciB0aGluZ3MuIE5vdCBwcm9wb3NpbmcgdGhpcyBhcyBhIHNvbHV0aW9uIGJ1dCBlLmcuIG9uZSBj b3VsZCBkZXRlY3QgYW4gYWRkcmVzcyBjaGFuZ2UgdXNpbmcgVFVSTuKApiBhbnl3YXkgSSBndWVz cyB5b3UgYXJlIHJpZ2h0IHRoYXQNCiB0aGVyZSBpcyBub3QgZWFzeSB3YXnigKY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_571B2506AA27411AAE5DD0E780FD889Bericssoncom_-- From nobody Tue Feb 11 08:46:24 2020 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 DFAEA1208DC for ; Tue, 11 Feb 2020 08:46:21 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 l0wFLq9NNLNx for ; Tue, 11 Feb 2020 08:46:20 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 72F271208EE for ; Tue, 11 Feb 2020 08:46:20 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 01BGePl1016296; Tue, 11 Feb 2020 16:46:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=X1thMkmRTIpZ3WOFzfUiOXB0G1+HayUPwkqKojsqZg8=; b=nNb1deTUJsOESZVM8/CcJatDarCmhdvvUbBIzv+eCmtDcMRxI+tdlHlXNhV11agiBasz E2R5K9QeRvMpG2+ff1ugLC9yWdY+mF4rZgCmf8n0FQ+nq969RgrJtdgMR10FFvbj3gAt nvK5+YYqOgFxbE73E/whGUKjEKWriEPMlMfnwrzLVGlPIfUHLWfGDP+xf5iSi0oImAku bx1FCGpBzdY5jsv6d96uQLgdylvx6EQBtfM+4RKF3mYQIe0QmcXpEQ1g8SzvhWs7bgfN XMrMe27cbdaaGgInzZ4RtModmsPAi9uhUMe9G7TDenY5GxSQAGiBCnlpUbn3+ZqcU5i0 CA== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2y1p9eee6r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Feb 2020 16:46:15 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01BGHiTP022568; Tue, 11 Feb 2020 11:46:14 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint8.akamai.com with ESMTP id 2y1s72ahd9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 11 Feb 2020 11:46:14 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.165.123) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 11 Feb 2020 10:46:13 -0600 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.165.123]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.165.123]) with mapi id 15.00.1473.005; Tue, 11 Feb 2020 10:46:13 -0600 From: "Lubashev, Igor" To: Lars Eggert CC: IETF QUIC WG , HAMCHAOUI Isabelle IMT/OLN , "alexandre.ferrieux@orange.com" , Dmitri Tikhonov Subject: RE: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt Thread-Topic: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt Thread-Index: AQHVzLqrJ8K1dwlaC0usEEtR2wTsCqft3wQQgChYbACAAB/50A== Date: Tue, 11 Feb 2020 16:46:12 +0000 Message-ID: <851a81d65a9a4318914b9b18fd0b0605@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <157921301012.26216.13677469865378306147.idtracker@ietfa.amsl.com> <180dde305bf149efb19a88e61967a87a@ustx2ex-dag1mb5.msg.corp.akamai.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.117.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-11_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002110115 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-11_05:2020-02-10, 2020-02-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 mlxlogscore=999 clxscore=1015 priorityscore=1501 mlxscore=0 impostorscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002110120 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 16:46:22 -0000 > From: Lars Eggert >=20 > Hi, >=20 > (chair hat off) >=20 > the draft points to the CONEX work and says this: >=20 > This loss signaling is similar to loss signaling in [RFC7713], except > the Loss Event bit is reporting the exact number of lost packets, > whereas the Echo Loss bit in [RFC7713] is reporting an approximate > number of lost bytes. >=20 > What it doesn't say is why the CONEX functionality is being proposed to b= e > incorporated into QUIC, rather than staying at the IP level where it argu= ably > belongs? Thanks for the feedback. I agree that the draft could benefit from the expl= anation of why we use QUIC v1 reserved header bits instead of some bits in = a lower layer (or more bits outside of the header in the QUIC packet). The short answer is deployability. There is no point in writing drafts tha= t will sit on a shelf, because no one will want to deploy them for at least= a decade. CONEX is one example, plagued by the difficulty of getting IPv6= extension headers deployed. And good luck with similar IPv4 extensions. Hence we borrow CONEX ideas but try to implement them in a way that is stil= l possible, while using greasing and anti-ossification techniques. > Thanks, > Lars Best, - Igor From nobody Tue Feb 11 09:31:09 2020 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 8C7DA120923; Tue, 11 Feb 2020 09:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 opqUJ2OKuwgY; Tue, 11 Feb 2020 09:31:03 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 B53201208D2; Tue, 11 Feb 2020 09:31:02 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id m10so2761556wmc.0; Tue, 11 Feb 2020 09:31:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=23NQD3yHPY5+NAxCahBcZj95em8VWp9oO9p31fbvkj8=; b=uQqktrodK0cSgbf6qHsRZiakSscGeWPy++S+0svG65d4BfXsJ0ENg9j4pP3BRiZiZY Dxnqw1czgzoP5pl1ETIqQHbZhkE1jpTvqzqrt64aJ9MR5rJBCNqBXH1xZw9JK8bfjiN7 GS58Y5bu1xQQcRwXXpBgMZCaET0CT/8l55JNRcTI4vmRVFU7bAQFDZo7QQ/SqZwFFNWa EOaw6vDt0pYh/pqcg2WBRURSFQ0T7NmLVAV/100/aUo90i3Bp00hphkn3JPts5B6qkhK atGIwjzcv1IdgMvg3yw2RBtKc9vUWZ4ngfkBLvUoNx5iOXkRg9QYu7502t9YoCAgnLpm GTGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=23NQD3yHPY5+NAxCahBcZj95em8VWp9oO9p31fbvkj8=; b=fAszZRhL++hi3tsrHmQMx2uvC4VbdDOLwTD6Dt3jLRzEKK4RdcFg9IDjv5eaE9SJli +kQyq6xthX9MuCMgSGBjX46mArnEpE3HdRvpPkct0K+slwsw1PpVH27BA3Iph8nDl4Gb jIO10W3ey3zIobrmixXULy0WNXqhLEA3drQqrpU1Ie6SWjAeoghT/spyEAUpCnf5uTyE cPDiPLHN+TlR950x2S8ek21CQFKn+Uqb+dKTqzkW9DaPjf8kBkcNP08L3anLNkzXLAVV Bl6LeFaDiDgnX/58agGzb79TGN+UMmYyA6/uEDTIGRVFUvRPnBHeCBb3VWRfSc6o9Ffu q+5A== X-Gm-Message-State: APjAAAXHEzaR4bboNKqWXY+JAOqs4Ro2D1FbSOdHi7uY1+at6AdXaEAg tOvEDCyREhucpJHVQB3fy5917aEfvar0aDbHlOg= X-Google-Smtp-Source: APXvYqy9IUulTK3xyquDKcDkLUU2gjWaJ6YlNbTihK+O2iDrYzMuwRiOQs39KeE8txOCcuFYuNpuF8oudymWjMdFYeY= X-Received: by 2002:a05:600c:20c6:: with SMTP id y6mr6729462wmm.95.1581442261286; Tue, 11 Feb 2020 09:31:01 -0800 (PST) MIME-Version: 1.0 References: <158109575881.11589.7522751407809468206.idtracker@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Tue, 11 Feb 2020 18:30:49 +0100 Message-ID: Subject: Re: WG Review: QUIC (quic) To: Giorgio Zoppi Cc: Spencer Dawkins at IETF , IETF QUIC WG , The IESG Content-Type: multipart/alternative; boundary="000000000000378116059e50387c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 17:31:07 -0000 --000000000000378116059e50387c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Giorgio, at this time there is no plan for an additional interim. QUIC business will be conducted at regular IETF meetings until further notice. On Mon, Feb 10, 2020 at 10:40 PM Giorgio Zoppi wrote: > Dear all, > when will be the next meeting? I know that the last was in Zurich. > BR, > Giorgio > > El lun., 10 feb. 2020 a las 22:36, Spencer Dawkins at IETF (< > spencerdawkins.ietf@gmail.com>) escribi=C3=B3: > >> Dear IESG, >> >> I don't have any concerns about the direction for this charter, but I do >> have some suggestions on wording. >> >> Best, >> >> Spencer >> >> On Fri, Feb 7, 2020 at 11:16 AM The IESG wrote= : >> >>> The QUIC (quic) WG in the Transport Area of the IETF is undergoing >>> rechartering. The IESG has not made any determination yet. The followin= g >>> draft charter was submitted, and is provided for informational purposes >>> only. >>> Please send your comments to the IESG mailing list (iesg@ietf.org) by >>> 2020-02-17. >>> >>> QUIC (quic) >>> ----------------------------------------------------------------------- >>> Current status: Active WG >>> >>> Chairs: >>> Mark Nottingham >>> Lars Eggert >>> Lucas Pardue >>> >>> Assigned Area Director: >>> Magnus Westerlund >>> >>> Transport Area Directors: >>> Mirja K=C3=BChlewind >>> Magnus Westerlund >>> >>> Mailing list: >>> Address: quic@ietf.org >>> To subscribe: https://www.ietf.org/mailman/listinfo/quic >>> Archive: https://mailarchive.ietf.org/arch/browse/quic/ >>> >>> Group page: https://datatracker.ietf.org/group/quic/ >>> >>> Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/ >>> >>> The QUIC working group will provide standards-track specifications for = a >>> UDP-based, stream-multiplexing, encrypted transport protocol, based on >>> pre-standardization implementation and deployment experience. >>> >>> Key goals for QUIC are: >>> >> >> I'm wondering when these change from goals to attributes, but maybe the >> next major revision is the right time ... >> >> >>> - Minimizing connection establishment and overall transport latency fo= r >>> applications, starting with HTTP; >>> >>> - Providing multiplexing without head-of-line blocking; >>> >>> - Requiring only changes to path endpoints to enable deployment; >>> >>> - Enabling multipath and forward error correction extensions; and >>> >>> - Providing always-secure transport, using TLS 1.3 by default. >>> >>> The work of the group will have five main focus areas, corresponding to >>> five >>> core deliverables. >>> >>> The first of these is the core transport work, which will describe the >>> wire >>> >> >> I wonder when the charter moves from future tense (which was accurate in >> 2016) to present tense, but perhaps after version 1 is complete would be= a >> good time. >> >> >>> format, along with the mechanisms for connection establishment, stream >>> multiplexing, data reliability, loss detection and recovery, congestion >>> control, and options negotiation. Work on congestion control will >>> describe >>> use of a standardized congestion controller as a default scheme for QUI= C. >>> Defining new congestion control schemes is explicitly out of scope for >>> this >>> group. QUIC is expected to support rapid, distributed development and >>> testing >>> of features. >>> >>> The second of these focus areas is security. This work will describe ho= w >>> the >>> protocol uses TLS 1.3 for key negotiation and will also describe how >>> those >>> keys are used to provide confidentiality and integrity protection of bo= th >>> application data and QUIC headers. This work will ensure that QUIC has >>> security and privacy properties that are at least as good as a stack >>> composed >>> of TLS 1.3 using TCP (or MPTCP when using multipath). >>> >>> The third focus area describes the mapping between the HTTP application >>> protocol and the transport facilities of QUIC. This mapping will have >>> performance characteristics comparable with HTTP/2, and provide extensi= on >>> mechanisms similar to HTTP/2. Upon completion of this mapping, work to >>> define >>> additional mappings may be included by updates to this charter, or may = be >>> worked on by other working groups. >>> >> >> When QUIC was chartered, my hope (and I don't think I was the only one) >> was that we would end up with HTTP/2 over QUIC. For good reasons, we end= ed >> up with HTTP/3 over QUIC, and it seems odd that there's no mention of >> HTTP/3 in the 2020 QUIC charter, but it IS mentioned in >> https://datatracker.ietf.org/doc/charter-ietf-httpbis/. >> >> >>> The fourth focus area will be on extensions to core protocol facilities= , >>> to >>> enable datagram delivery, version negotiation, and multipath >>> capabilities. >>> Other extensions are out of the scope of this charter. >>> >>> The fifth focus area will provide an Applicability and Manageability >>> Statement, describing how, and under what circumstances, QUIC may be >>> safely >>> used, and describing deployment and manageability implications of the >>> protocol. Additionally, the Working Group will provide guidance on how = to >>> handle QUIC traffic in load balancers. >>> >>> Current practices for network management of transport protocols include >>> the >>> ability to apply access control lists (ACLs), hashing of flows for >>> equal-cost >>> multipath routing (ECMP), directional signaling of flows, signaling of >>> flow >>> setup and teardown, and the ability to export information about flows f= or >>> accounting purposes. The QUIC protocol need not be defined to enable >>> each of >>> these abilities, or enable them in the same way as they are enabled by >>> TCP >>> when used with TLS 1.3, but the working group must consider the impact >>> of the >>> protocol on network management practices, reflecting the tensions >>> described >>> in RFC 7258. >>> >>> Note that consensus is required both for changes to the current protoco= l >>> 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. >>> >> >> This paragraph ^ was inserted to say "the way Google QUIC happens to wor= k >> in 2016" (which was the only QUIC we had) "isn't binding on the working >> group producing IETF QUIC". That was worth saying in 2016 - and we might >> have said it more clearly - but in 2020, the obvious meaning of "current >> protocol mechanisms" is IETF QUICv1. I don't think this paragraph means >> anything helpful now, and anyone who tries to be guided by it, is probab= ly >> headed into the weeds. I'd delete it. >> >> >>> The QUIC working group will work closely with the HTTPbis working group= , >>> especially on the QUIC mapping for HTTP. >>> >>> Milestones: >>> >>> Jul 2020 - Core Protocol document to IESG >>> >>> Jul 2020 - Loss detection and Congestion Control document to IESG >>> >>> Jul 2020 - TLS 1.3 Mapping document to IESG >>> >>> Jul 2020 - HTTP/2 mapping document to IESG >>> >>> Jul 2020 - QUIC Applicability and Manageability Statement to IESG >>> >> >> Just making sure I understand - the load balancing advice would be >> included in this statement, is that right? >> >> Jul 2020 - Version-Independent Properties of QUIC to IESG >>> >>> Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG >>> >>> Dec 2020 - Working group adoption of Multipath extension document >>> >>> Mar 2021 - Datagram Extension to IESG >>> >>> Mar 2021 - Version Negotiation Extension to IESG >>> >>> Dec 2021 - Multipath extension document to IESG >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >> > > -- > Life is a chess game - Anonymous. > --000000000000378116059e50387c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Giorgio, at this time there is no plan for an additional i= nterim. QUIC business will be conducted at regular IETF meetings until furt= her notice.

On Mon, Feb 10, 2020 at 10:40 PM Giorgio Zoppi <giorgio.zoppi@gmail.com> wrote:<= br>
Dear all,
when will be the next meeting? I know that the la= st was in Zurich.
BR,
Giorgio

El lun., 10 feb.= 2020 a las 22:36, Spencer Dawkins at IETF (<spencerdawkins.ietf@gmail.com&g= t;) escribi=C3=B3:
Dear IESG,=C2=A0

I don= 9;t have any concerns about the direction for this charter, but I do have s= ome suggestions on wording.=C2=A0

Best,
=
Spencer

On Fri, Feb 7, 2020 at 11:16 AM The IESG <iesg-secretary@ietf.o= rg> wrote:
iesg@ietf.org) by
2020-02-17.

QUIC (quic)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
=C2=A0 Mark Nottingham <mnot@mnot.net>
=C2=A0 Lars Eggert <lars@eggert.org>
=C2=A0 Lucas Pardue <lucaspardue.24.7@gmail.com>

Assigned Area Director:
=C2=A0 Magnus Westerlund <magnus.westerlund@ericsson.com>

Transport Area Directors:
=C2=A0 Mirja K=C3=BChlewind <ietf@kuehlewind.net>
=C2=A0 Magnus Westerlund <magnus.westerlund@ericsson.com>

Mailing list:
=C2=A0 Address: quic@iet= f.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/listinfo= /quic
=C2=A0 Archive: https://mailarchive.ietf.org/arch/brow= se/quic/

Group page: https://datatracker.ietf.org/group/quic/

Charter: https://datatracker.ietf.org/doc/charter= -ietf-quic/

The QUIC working group will provide standards-track specifications for a UDP-based, stream-multiplexing, encrypted transport protocol, based on
pre-standardization implementation and deployment experience.

Key goals for QUIC are:

I'm wonderi= ng when these change from goals to attributes, but maybe the next major rev= ision is the right time ...
=C2=A0
=C2=A0- Minimizing connection establishment and ov= erall transport latency for
=C2=A0applications, starting with HTTP;

=C2=A0- Providing multiplexing without head-of-line blocking;

=C2=A0- Requiring only changes to path endpoints to enable deployment;

=C2=A0- Enabling multipath and forward error correction extensions; and

=C2=A0- Providing always-secure transport, using TLS 1.3 by default.

The work of the group will have five main focus areas, corresponding to fiv= e
core deliverables.

The first of these is the core transport work, which will describe the wire=

I wonder when the charter moves from f= uture tense (which was accurate in 2016) to present tense, but perhaps afte= r version 1 is complete would be a good time.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> format, along with the mechanisms for connection establishment, stream
multiplexing, data reliability, loss detection and recovery, congestion
control, and options negotiation. Work on congestion control will describe<= br> use of a standardized congestion controller as a default scheme for QUIC. Defining new congestion control schemes is explicitly out of scope for this=
group. QUIC is expected to support rapid, distributed development and testi= ng
of features.

The second of these focus areas is security. This work will describe how th= e
protocol uses TLS 1.3 for key negotiation and will also describe how those<= br> keys are used to provide confidentiality and integrity protection of both application data and QUIC headers. This work will ensure that QUIC has
security and privacy properties that are at least as good as a stack compos= ed
of TLS 1.3 using TCP (or MPTCP when using multipath).

The third focus area describes the mapping between the HTTP application
protocol and the transport facilities of QUIC. This mapping will have
performance characteristics comparable with HTTP/2, and provide extension mechanisms similar to HTTP/2. Upon completion of this mapping, work to defi= ne
additional mappings may be included by updates to this charter, or may be worked on by other working groups.

When= QUIC was chartered, my hope (and I don't think I was the only one) was= that we would end up with HTTP/2 over QUIC. For good reasons, we ended up = with HTTP/3 over QUIC, and it seems odd that there's no mention of HTTP= /3 in the 2020 QUIC charter, but it IS mentioned in=C2=A0https://= datatracker.ietf.org/doc/charter-ietf-httpbis/.=C2=A0
=C2=A0<= /div>
The fourth focus are= a will be on extensions to core protocol facilities, to
enable datagram delivery, version negotiation, and multipath capabilities.<= br> Other extensions are out of the scope of this charter.

The fifth focus area will provide an Applicability and Manageability
Statement, describing how, and under what circumstances, QUIC may be safely=
used, and describing deployment and manageability implications of the
protocol. Additionally, the Working Group will provide guidance on how to handle QUIC traffic in load balancers.

Current practices for network management of transport protocols include the=
ability to apply access control lists (ACLs), hashing of flows for equal-co= st
multipath routing (ECMP), directional signaling of flows, signaling of flow=
setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each o= f
these abilities, or enable them in the same way as they are enabled by TCP<= br> when used with TLS 1.3, but the working group must consider the impact of t= he
protocol on network management practices, reflecting the tensions described=
in RFC 7258.

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.

This paragraph ^ was inserted to say "the way Goo= gle QUIC happens to work in 2016" (which was the only QUIC we had) &qu= ot;isn't binding on the working group producing IETF QUIC". That w= as worth saying in 2016 - and we might have said it more clearly - but in 2= 020, the obvious meaning of "current protocol mechanisms" is IETF= QUICv1. I don't think this paragraph means anything helpful now, and a= nyone who tries to be guided by it, is probably headed into the weeds. I= 9;d delete it.=C2=A0
=C2=A0
The QUIC working group will work closely with the HTTPbis= working group,
especially on the QUIC mapping for HTTP.

Milestones:

=C2=A0 Jul 2020 - Core Protocol document to IESG

=C2=A0 Jul 2020 - Loss detection and Congestion Control document to IESG
=C2=A0 Jul 2020 - TLS 1.3 Mapping document to IESG

=C2=A0 Jul 2020 - HTTP/2 mapping document to IESG

=C2=A0 Jul 2020 - QUIC Applicability and Manageability Statement to IESG

Just making sure I understand - the load = balancing advice would be included in this statement, is that right?=C2=A0<= /div>

=C2= =A0 Jul 2020 - Version-Independent Properties of QUIC to IESG

=C2=A0 Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG

=C2=A0 Dec 2020 - Working group adoption of Multipath extension document
=C2=A0 Mar 2021 - Datagram Extension to IESG

=C2=A0 Mar 2021 - Version Negotiation Extension to IESG

=C2=A0 Dec 2021 - Multipath extension document to IESG


_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce


--
Life is a chess game - Anonymous.
--000000000000378116059e50387c-- From nobody Tue Feb 11 12:48:11 2020 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 CCE5912006F for ; Tue, 11 Feb 2020 12:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 M3Ovufyy8ldA for ; Tue, 11 Feb 2020 12:47:24 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 A36F6120132 for ; Tue, 11 Feb 2020 12:47:24 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id h9so11536060otj.11 for ; Tue, 11 Feb 2020 12:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O9HDKs6p/TKxnz5wlDbmih0UEwBOlk5+PGHWJtoM4r4=; b=lkDi0RZclwgoeTTZkrlGA4+oMEbkqEpsq5SPBxZTky7PscgamEFIg2IF6UJPJ7eQ33 mJzCx/hvzu/yoceYMpLTatIZYZorPDNrhh+kVcao4Og99zQLiwE2ztpKbzM7bkwFgNT1 2jMdtp3c9u0vRhmbjMAIRZ5IIf1QyWKXRiTaaz+rsaxqZHzFW7Wj15Pp7qEVzGYFk6Ri bN3FXmfeO7MB+KlXv/5iTSZkpkpyfWjfVgydLHYxBSPRN37BJRkTU35WBk60DMcLXo80 OIE0FdTC/CGFcvsL0Hr8ZZ2nBOKniSjZC3m3t9Pz6vjMaSsa1TzOuQ2sr2Mut6GT9O8V 6gfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O9HDKs6p/TKxnz5wlDbmih0UEwBOlk5+PGHWJtoM4r4=; b=DqjmD1nL0nQaEIefyF1mVImDEE/T0+wU5qv6g5A/aSNQvBp4pHjv0lpO2jB8QgoKvt xyqQH5VLkS7JKpL1Zwku9lnSxsuqK+moiPDm0zjkL0lSDv3432FKJ0k52enr46Emb6I8 zxKAuxdjxxYZUhYaVEnC09XDun4OAIuT7CoG0IgoQaNA72qgmrC9htMTeZn01cbYVIie xCzIpA72Xm2ootLwucEsf/KgZ6kwDu+FbnFY6bpB5mhzeDek0ag7lSUzYlkjwN/6s+ir zS/qubVlsAAQAhyLbeZ7yNc17pFczr+nU6WDvKwBGwrVohYDRWjSQV+AUIi1PuBllHS+ HIYw== X-Gm-Message-State: APjAAAXIaoiJtbZwdCYDCU3vJ9g736Y2HMfefZzzKFycRdDGXD3IxqAN i79JAmXo59LUby9emOAhUZKTsL0Iq1tMbIAy1V8= X-Google-Smtp-Source: APXvYqw0aA1CORw10MCepP4IiVfcgCnBEEj2vAD2JMILxCrAA4kSQPc69ZfCxzhrK6qxOx1VUeNcdfrQ19qvJ2X1vtA= X-Received: by 2002:a05:6830:1149:: with SMTP id x9mr6872310otq.156.1581454043949; Tue, 11 Feb 2020 12:47:23 -0800 (PST) MIME-Version: 1.0 References: <157921301012.26216.13677469865378306147.idtracker@ietfa.amsl.com> <180dde305bf149efb19a88e61967a87a@ustx2ex-dag1mb5.msg.corp.akamai.com> <851a81d65a9a4318914b9b18fd0b0605@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <851a81d65a9a4318914b9b18fd0b0605@ustx2ex-dag1mb5.msg.corp.akamai.com> From: Erik Kline Date: Tue, 11 Feb 2020 12:47:13 -0800 Message-ID: Subject: Re: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt To: "Lubashev, Igor" Cc: Lars Eggert , "HAMCHAOUI Isabelle IMT/OLN" , IETF QUIC WG , "alexandre.ferrieux@orange.com" , Dmitri Tikhonov Content-Type: multipart/alternative; boundary="00000000000084adc5059e52f6d6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 20:47:28 -0000 --00000000000084adc5059e52f6d6 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 11, 2020 at 8:46 AM Lubashev, Igor wrote: > > From: Lars Eggert > > > > Hi, > > > > (chair hat off) > > > > the draft points to the CONEX work and says this: > > > > This loss signaling is similar to loss signaling in [RFC7713], except > > the Loss Event bit is reporting the exact number of lost packets, > > whereas the Echo Loss bit in [RFC7713] is reporting an approximate > > number of lost bytes. > > > > What it doesn't say is why the CONEX functionality is being proposed to > be > > incorporated into QUIC, rather than staying at the IP level where it > arguably > > belongs? > > Thanks for the feedback. I agree that the draft could benefit from the > explanation of why we use QUIC v1 reserved header bits instead of some bits > in a lower layer (or more bits outside of the header in the QUIC packet). > > The short answer is deployability. There is no point in writing drafts > that will sit on a shelf, because no one will want to deploy them for at > least a decade. CONEX is one example, plagued by the difficulty of getting > IPv6 extension headers deployed. And good luck with similar IPv4 > extensions. > > Hence we borrow CONEX ideas but try to implement them in a way that is > still possible, while using greasing and anti-ossification techniques. > > > Thanks, > > Lars > > Best, > - Igor > > Folks might laugh, but I think realistically we'll be looking towards UDP trailers at some point. --00000000000084adc5059e52f6d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 11, 2020 at 8:46 AM Lubashev,= Igor <ilubashe@akamai.com>= ; wrote:
> From: Lars Eggert <lars@eggert.org>
>
> Hi,
>
> (chair hat off)
>
> the draft points to the CONEX work and says this:
>
>=C2=A0 =C2=A0 This loss signaling is similar to loss signaling in [RFC7= 713], except
>=C2=A0 =C2=A0 the Loss Event bit is reporting the exact number of lost = packets,
>=C2=A0 =C2=A0 whereas the Echo Loss bit in [RFC7713] is reporting an ap= proximate
>=C2=A0 =C2=A0 number of lost bytes.
>
> What it doesn't say is why the CONEX functionality is being propos= ed to be
> incorporated into QUIC, rather than staying at the IP level where it a= rguably
> belongs?

Thanks for the feedback. I agree that the draft could benefit from the expl= anation of why we use QUIC v1 reserved header bits instead of some bits in = a lower layer (or more bits outside of the header in the QUIC packet).

The short answer is deployability.=C2=A0 There is no point in writing draft= s that will sit on a shelf, because no one will want to deploy them for at = least a decade.=C2=A0 CONEX is one example, plagued by the difficulty of ge= tting IPv6 extension headers deployed.=C2=A0 And good luck with similar IPv= 4 extensions.

Hence we borrow CONEX ideas but try to implement them in a way that is stil= l possible, while using greasing and anti-ossification techniques.

> Thanks,
> Lars

Best,
- Igor


Folks might laugh, but I think realist= ically we'll be looking towards UDP trailers at some point.
=
--00000000000084adc5059e52f6d6-- From nobody Tue Feb 11 12:51:28 2020 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 CEE1A12006F for ; Tue, 11 Feb 2020 12:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=iqN8ugq1; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=G7pZeRUc 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 hQn_df6vYPav for ; Tue, 11 Feb 2020 12:51:23 -0800 (PST) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 5A1E712083C for ; Tue, 11 Feb 2020 12:51:23 -0800 (PST) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01BKZ538003234; Tue, 11 Feb 2020 12:51:15 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=mgbJYjx8Jz9++gweczmZD8gw+DREAuhyGO4JfxZDx0A=; b=iqN8ugq116FVuz4MzL7UpCZJ2ivol11sxkW9bDJsFSvQEYgXMA6iQ/AWDZR/YF8k8f3A jmCNsyQ/AwGUQNJqNJJkiJuTXFoZVyFLGQRDfcX92i0xTFk6jc7d8DTtfB88uVs1NLx7 W3deCLo6hoIOPYJ1+ahcctxMSROnIGltWfM= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2y1upqfxt1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 11 Feb 2020 12:51:14 -0800 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.36.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 11 Feb 2020 12:51:14 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ccEJFqk0XMNl0MaRQ4Z5chdQ6EXBFkswhem8xO4wTgnci6jMSgXLR5HkaQWE4FT/+9sPR/QiYxJoI9Q0dyU1sWmNJtBr6zi/vKRX7LNrO+xPxnxyQMfks57fZk/CmiXGWN3ZWOPA0eOZn3VS/F0eZKdJ9sxMVTcRY82LiRWIev2LHrFZfAM6s8CAFRqAIRVDi8Ud8ghBBSoiPtlHDJiXTE+JxZzTXO1YVb2FiME9xpi5DsjkmXzmB+HrMMEPBFJYPa6z2X12QaijFENtCeIdO1EMTr+TrDXT7KNJE2ZvhihKQfPqHvogP6O2TyOvVGPHy2cwyfYk72rOkFzBjgGVsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mgbJYjx8Jz9++gweczmZD8gw+DREAuhyGO4JfxZDx0A=; b=QarkfXGEm5gZFzFhPnkIqrCA9be7s71UrCgjsctyZ/z5qi/4eYyrkEB0zqHq4zUojyjvL7DbULGZB+3g+lPQd4Rz4KtrbTL0JkF4L++yPCL8iai4R5qPbICbK0uPw+ktR2uctjIq4TwRiidyAEKcW4wxN9w0GjhphKWJ/SqNGkJzUrU7S6/T0DBHJL79yHWToWqG7aDasBW3h1/YxNQN4vtIhxnvIPWBDX67nVKv7tVxVk/TBJOWk/Ezq/zkSVwpV4ia48ntrWwNXXhxsZlQA12sCVJftAZfvG1HWx3itz2eu8R0WUUan0+fl9Ig4tVON5XosLYR7niD+UBzVfdD2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector2-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mgbJYjx8Jz9++gweczmZD8gw+DREAuhyGO4JfxZDx0A=; b=G7pZeRUcDLhWdZ6PI4yavcKOvd0jeLgjQ/4IiNGNLJJsUW3XFSGOEmsT1UhOzCH/2P9em4dYCGBJR4ORbbfDKn6OWu5NedzrF3Szv3MdpWXmWb3caAPPik2jlHa6NIJ52iqnyBm4IXuVBVtm0NfQIRwX7tdowg0IPZRTrdAVC/U= Received: from MWHPR15MB1935.namprd15.prod.outlook.com (10.174.96.149) by MWHPR15MB1439.namprd15.prod.outlook.com (10.173.235.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.22; Tue, 11 Feb 2020 20:51:12 +0000 Received: from MWHPR15MB1935.namprd15.prod.outlook.com ([fe80::ac5f:bc9e:f7c2:e35f]) by MWHPR15MB1935.namprd15.prod.outlook.com ([fe80::ac5f:bc9e:f7c2:e35f%12]) with mapi id 15.20.2707.030; Tue, 11 Feb 2020 20:51:12 +0000 From: Roberto Peon To: Erik Kline , "Lubashev, Igor" CC: Lars Eggert , HAMCHAOUI Isabelle IMT/OLN , IETF QUIC WG , "alexandre.ferrieux@orange.com" , "Dmitri Tikhonov" Subject: Re: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt Thread-Topic: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt Thread-Index: AQHVzLqrJ8K1dwlaC0usEEtR2wTsCqft3wQQgCfz1wCAAIk4AIAAQ1eA//96/4A= Date: Tue, 11 Feb 2020 20:51:12 +0000 Message-ID: References: <157921301012.26216.13677469865378306147.idtracker@ietfa.amsl.com> <180dde305bf149efb19a88e61967a87a@ustx2ex-dag1mb5.msg.corp.akamai.com> <851a81d65a9a4318914b9b18fd0b0605@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-originating-ip: [198.217.64.131] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4d8b6b2d-47a0-4317-c2d0-08d7af342119 x-ms-traffictypediagnostic: MWHPR15MB1439: x-microsoft-antispam-prvs: x-fb-source: Internal x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0310C78181 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(346002)(39860400002)(396003)(376002)(199004)(189003)(8936002)(81156014)(81166006)(478600001)(8676002)(15650500001)(91956017)(76116006)(64756008)(66556008)(66476007)(66446008)(66946007)(86362001)(5660300002)(6512007)(6486002)(36756003)(2906002)(33656002)(4326008)(54906003)(110136005)(316002)(26005)(2616005)(186003)(6506007)(53546011)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1439; H:MWHPR15MB1935.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3OIJtwtjjElBrOdCiJeV19DFdbHsq5nncCqtlwKLxla16LOmTB+/Y8RUbxYcLpbR4E1AylAiBtacMngtHF8ITKSegOKyiZ5l5V5WtGHKWzvWr3nvwbkjj7zh5iabEwUiFMihmsKs2oxx0Q1l9PGlp/YjBl2en3kLzzByWC4L5DRiJ0jUtD8gJT+MVGldJr0S1J7ZNMzsmUMuoK8F6YFfhD5zMjIVFrwFFC9Gc+Ve1L9FAEHoh3P54JBhZtR5VF72lORnMW5LySzRXxHolqWEe2IkFLgraR2O2G/ifErE736ajBYg2OmNV94dtBry/TrVdos/fYSWHUkm1lvOkM7bqfASw/2IrY4I+j3Cdc/eI47PV7JQtKPq54em+q4eFLc5e7U/A2WEIhYWEMccFtMEvhWC8ujMUrLCa9ANA0vuyB1nnslZvogUMcyTaZyGj7ss x-ms-exchange-antispam-messagedata: hjdUhsg/g76lJzm5w1QORBe+8kv1Fu2eH4bnbzjPcXZ/rT6mtqqJU7QEbdyoiFy46ZmYzr2EQQq46KDQGuR4dycvqR8tJ8MXpnmp4LtzhYxjRrS/wOAxTEHezeRW1gNoqME7morh/rcc+hAjOwWuaQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BBE88CC9E83343858469A35C5AE6CACFfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4d8b6b2d-47a0-4317-c2d0-08d7af342119 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2020 20:51:12.3311 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7zyE/po6kI7skpMO8YTeXiFWhaxfOYpafFIRjejbfJQTTPxp9pP19IbRl4l2E3kn X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1439 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-11_05:2020-02-11, 2020-02-11 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 mlxlogscore=999 priorityscore=1501 mlxscore=0 suspectscore=0 clxscore=1011 malwarescore=0 phishscore=0 impostorscore=0 adultscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002110136 X-FB-Internal: deliver Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 20:51:27 -0000 --_000_BBE88CC9E83343858469A35C5AE6CACFfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IGxhdWdoaW5nIG92ZXIgaGVyZeKApg0KDQpASWdvcuKAlEkgdGhpbmsgdGhlIHF1ZXN0aW9u IHdhcyBpZiB3ZSBjb3VsZCBwdXQgdGhlIHJlYXNvbmluZyBpbnRvIHRoZSBkcmFmdCENCi09Ug0K DQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBFcmlrIEts aW5lIDxlay5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDIw IGF0IDEyOjQ3IFBNDQpUbzogIkx1YmFzaGV2LCBJZ29yIiA8aWx1YmFzaGVAYWthbWFpLmNvbT4N CkNjOiBMYXJzIEVnZ2VydCA8bGFyc0BlZ2dlcnQub3JnPiwgSEFNQ0hBT1VJIElzYWJlbGxlIElN VC9PTE4gPGlzYWJlbGxlLmhhbWNoYW91aUBvcmFuZ2UuY29tPiwgSUVURiBRVUlDIFdHIDxxdWlj QGlldGYub3JnPiwgImFsZXhhbmRyZS5mZXJyaWV1eEBvcmFuZ2UuY29tIiA8YWxleGFuZHJlLmZl cnJpZXV4QG9yYW5nZS5jb20+LCBEbWl0cmkgVGlraG9ub3YgPGR0aWtob25vdkBsaXRlc3BlZWR0 ZWNoLmNvbT4NClN1YmplY3Q6IFJlOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWZlcnJpZXV4aGFtY2hhb3VpLXF1aWMtbG9zc2JpdHMtMDMudHh0DQoNCk9uIFR1ZSwgRmViIDEx LCAyMDIwIGF0IDg6NDYgQU0gTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFp bHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PiB3cm90ZToNCj4gRnJvbTogTGFycyBFZ2dlcnQgPGxh cnNAZWdnZXJ0Lm9yZzxtYWlsdG86bGFyc0BlZ2dlcnQub3JnPj4NCj4NCj4gSGksDQo+DQo+IChj aGFpciBoYXQgb2ZmKQ0KPg0KPiB0aGUgZHJhZnQgcG9pbnRzIHRvIHRoZSBDT05FWCB3b3JrIGFu ZCBzYXlzIHRoaXM6DQo+DQo+ICAgIFRoaXMgbG9zcyBzaWduYWxpbmcgaXMgc2ltaWxhciB0byBs b3NzIHNpZ25hbGluZyBpbiBbUkZDNzcxM10sIGV4Y2VwdA0KPiAgICB0aGUgTG9zcyBFdmVudCBi aXQgaXMgcmVwb3J0aW5nIHRoZSBleGFjdCBudW1iZXIgb2YgbG9zdCBwYWNrZXRzLA0KPiAgICB3 aGVyZWFzIHRoZSBFY2hvIExvc3MgYml0IGluIFtSRkM3NzEzXSBpcyByZXBvcnRpbmcgYW4gYXBw cm94aW1hdGUNCj4gICAgbnVtYmVyIG9mIGxvc3QgYnl0ZXMuDQo+DQo+IFdoYXQgaXQgZG9lc24n dCBzYXkgaXMgd2h5IHRoZSBDT05FWCBmdW5jdGlvbmFsaXR5IGlzIGJlaW5nIHByb3Bvc2VkIHRv IGJlDQo+IGluY29ycG9yYXRlZCBpbnRvIFFVSUMsIHJhdGhlciB0aGFuIHN0YXlpbmcgYXQgdGhl IElQIGxldmVsIHdoZXJlIGl0IGFyZ3VhYmx5DQo+IGJlbG9uZ3M/DQoNClRoYW5rcyBmb3IgdGhl IGZlZWRiYWNrLiBJIGFncmVlIHRoYXQgdGhlIGRyYWZ0IGNvdWxkIGJlbmVmaXQgZnJvbSB0aGUg ZXhwbGFuYXRpb24gb2Ygd2h5IHdlIHVzZSBRVUlDIHYxIHJlc2VydmVkIGhlYWRlciBiaXRzIGlu c3RlYWQgb2Ygc29tZSBiaXRzIGluIGEgbG93ZXIgbGF5ZXIgKG9yIG1vcmUgYml0cyBvdXRzaWRl IG9mIHRoZSBoZWFkZXIgaW4gdGhlIFFVSUMgcGFja2V0KS4NCg0KVGhlIHNob3J0IGFuc3dlciBp cyBkZXBsb3lhYmlsaXR5LiAgVGhlcmUgaXMgbm8gcG9pbnQgaW4gd3JpdGluZyBkcmFmdHMgdGhh dCB3aWxsIHNpdCBvbiBhIHNoZWxmLCBiZWNhdXNlIG5vIG9uZSB3aWxsIHdhbnQgdG8gZGVwbG95 IHRoZW0gZm9yIGF0IGxlYXN0IGEgZGVjYWRlLiAgQ09ORVggaXMgb25lIGV4YW1wbGUsIHBsYWd1 ZWQgYnkgdGhlIGRpZmZpY3VsdHkgb2YgZ2V0dGluZyBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIGRl cGxveWVkLiAgQW5kIGdvb2QgbHVjayB3aXRoIHNpbWlsYXIgSVB2NCBleHRlbnNpb25zLg0KDQpI ZW5jZSB3ZSBib3Jyb3cgQ09ORVggaWRlYXMgYnV0IHRyeSB0byBpbXBsZW1lbnQgdGhlbSBpbiBh IHdheSB0aGF0IGlzIHN0aWxsIHBvc3NpYmxlLCB3aGlsZSB1c2luZyBncmVhc2luZyBhbmQgYW50 aS1vc3NpZmljYXRpb24gdGVjaG5pcXVlcy4NCg0KPiBUaGFua3MsDQo+IExhcnMNCg0KQmVzdCwN Ci0gSWdvcg0KDQpGb2xrcyBtaWdodCBsYXVnaCwgYnV0IEkgdGhpbmsgcmVhbGlzdGljYWxseSB3 ZSdsbCBiZSBsb29raW5nIHRvd2FyZHMgVURQIHRyYWlsZXJzIGF0IHNvbWUgcG9pbnQuDQo= --_000_BBE88CC9E83343858469A35C5AE6CACFfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <90DDAE569686D14391D7FCE42506167C@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Tm90IGxhdWdoaW5nIG92ZXIgaGVyZeKApjxicj4NCjxicj4NCkBJZ29y 4oCUSSB0aGluayB0aGUgcXVlc3Rpb24gd2FzIGlmIHdlIGNvdWxkIHB1dCB0aGUgcmVhc29uaW5n IGludG8gdGhlIGRyYWZ0ITxicj4NCi09UjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+UVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYg b2YgRXJpayBLbGluZSAmbHQ7ZWsuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i PlR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDIwIGF0IDEyOjQ3IFBNPGJyPg0KPGI+VG86IDwvYj4m cXVvdDtMdWJhc2hldiwgSWdvciZxdW90OyAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs8YnI+ DQo8Yj5DYzogPC9iPkxhcnMgRWdnZXJ0ICZsdDtsYXJzQGVnZ2VydC5vcmcmZ3Q7LCBIQU1DSEFP VUkgSXNhYmVsbGUgSU1UL09MTiAmbHQ7aXNhYmVsbGUuaGFtY2hhb3VpQG9yYW5nZS5jb20mZ3Q7 LCBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDthbGV4YW5kcmUuZmVy cmlldXhAb3JhbmdlLmNvbSZxdW90OyAmbHQ7YWxleGFuZHJlLmZlcnJpZXV4QG9yYW5nZS5jb20m Z3Q7LCBEbWl0cmkgVGlraG9ub3YgJmx0O2R0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbSZndDs8 YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtZmVycmlldXhoYW1jaGFvdWktcXVpYy1sb3NzYml0cy0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU dWUsIEZlYiAxMSwgMjAyMCBhdCA4OjQ2IEFNIEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJt YWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0OyBGcm9tOiBMYXJz IEVnZ2VydCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhcnNAZWdnZXJ0Lm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmxhcnNAZWdnZXJ0Lm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpLDxicj4N CiZndDsgPGJyPg0KJmd0OyAoY2hhaXIgaGF0IG9mZik8YnI+DQomZ3Q7IDxicj4NCiZndDsgdGhl IGRyYWZ0IHBvaW50cyB0byB0aGUgQ09ORVggd29yayBhbmQgc2F5cyB0aGlzOjxicj4NCiZndDsg PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgVGhpcyBsb3NzIHNpZ25hbGluZyBpcyBzaW1pbGFyIHRv IGxvc3Mgc2lnbmFsaW5nIGluIFtSRkM3NzEzXSwgZXhjZXB0PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgdGhlIExvc3MgRXZlbnQgYml0IGlzIHJlcG9ydGluZyB0aGUgZXhhY3QgbnVtYmVyIG9mIGxv c3QgcGFja2V0cyw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB3aGVyZWFzIHRoZSBFY2hvIExvc3Mg Yml0IGluIFtSRkM3NzEzXSBpcyByZXBvcnRpbmcgYW4gYXBwcm94aW1hdGU8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyBudW1iZXIgb2YgbG9zdCBieXRlcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2hh dCBpdCBkb2Vzbid0IHNheSBpcyB3aHkgdGhlIENPTkVYIGZ1bmN0aW9uYWxpdHkgaXMgYmVpbmcg cHJvcG9zZWQgdG8gYmU8YnI+DQomZ3Q7IGluY29ycG9yYXRlZCBpbnRvIFFVSUMsIHJhdGhlciB0 aGFuIHN0YXlpbmcgYXQgdGhlIElQIGxldmVsIHdoZXJlIGl0IGFyZ3VhYmx5PGJyPg0KJmd0OyBi ZWxvbmdzPzxicj4NCjxicj4NClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiBJIGFncmVlIHRoYXQg dGhlIGRyYWZ0IGNvdWxkIGJlbmVmaXQgZnJvbSB0aGUgZXhwbGFuYXRpb24gb2Ygd2h5IHdlIHVz ZSBRVUlDIHYxIHJlc2VydmVkIGhlYWRlciBiaXRzIGluc3RlYWQgb2Ygc29tZSBiaXRzIGluIGEg bG93ZXIgbGF5ZXIgKG9yIG1vcmUgYml0cyBvdXRzaWRlIG9mIHRoZSBoZWFkZXIgaW4gdGhlIFFV SUMgcGFja2V0KS48YnI+DQo8YnI+DQpUaGUgc2hvcnQgYW5zd2VyIGlzIGRlcGxveWFiaWxpdHku Jm5ic3A7IFRoZXJlIGlzIG5vIHBvaW50IGluIHdyaXRpbmcgZHJhZnRzIHRoYXQgd2lsbCBzaXQg b24gYSBzaGVsZiwgYmVjYXVzZSBubyBvbmUgd2lsbCB3YW50IHRvIGRlcGxveSB0aGVtIGZvciBh dCBsZWFzdCBhIGRlY2FkZS4mbmJzcDsgQ09ORVggaXMgb25lIGV4YW1wbGUsIHBsYWd1ZWQgYnkg dGhlIGRpZmZpY3VsdHkgb2YgZ2V0dGluZyBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIGRlcGxveWVk LiZuYnNwOyBBbmQNCiBnb29kIGx1Y2sgd2l0aCBzaW1pbGFyIElQdjQgZXh0ZW5zaW9ucy48YnI+ DQo8YnI+DQpIZW5jZSB3ZSBib3Jyb3cgQ09ORVggaWRlYXMgYnV0IHRyeSB0byBpbXBsZW1lbnQg dGhlbSBpbiBhIHdheSB0aGF0IGlzIHN0aWxsIHBvc3NpYmxlLCB3aGlsZSB1c2luZyBncmVhc2lu ZyBhbmQgYW50aS1vc3NpZmljYXRpb24gdGVjaG5pcXVlcy48YnI+DQo8YnI+DQomZ3Q7IFRoYW5r cyw8YnI+DQomZ3Q7IExhcnM8YnI+DQo8YnI+DQpCZXN0LDxicj4NCi0gSWdvcjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9sa3Mg bWlnaHQgbGF1Z2gsIGJ1dCBJIHRoaW5rIHJlYWxpc3RpY2FsbHkgd2UnbGwgYmUgbG9va2luZyB0 b3dhcmRzIFVEUCB0cmFpbGVycyBhdCBzb21lIHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BBE88CC9E83343858469A35C5AE6CACFfbcom_-- From nobody Tue Feb 11 13:05:10 2020 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 301B412083A for ; Tue, 11 Feb 2020 13:05:08 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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_NONE=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=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 ENr3LO_po8Km for ; Tue, 11 Feb 2020 13:05:01 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 0ABF112006F for ; Tue, 11 Feb 2020 13:05:00 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 01BKwXVg013182; Tue, 11 Feb 2020 21:04:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=qGQ7GYfDnGV7SItBrEOQYuGr5srD3fUkKqkGre09HQc=; b=XwimyKIQDgBnnVWkzd4Ii9DjZ0gvyv2rZNirM3xRrE7XoQG7X8sFITmfKXNUv7op3DJV NlGsIN8b4g9daGue1jU2V+K5MP/ldKJESDU0CObzruDEBRnvh1Kj3GvT1Vc5aUmpw3oN 3V2nqKj/xrAMdB9ukI6ACw8q+NB/fTf5p699P4gM1wBGhgtoE/V5cvgN2J6RoZ8dDEc+ ljHi7CNMTdNxRry6ElDL2DvLp/Y3uqHh+9bz95IQ2LnQHY/jefndFvSme1Ft6PlkbiCR VUAmoR9jErUqQYyzXPZSGzR84kBRhfYBl2JaOqeckh69UI5UCljN7E7a3FRZ4tgNVWmz pQ== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2y1p9efbsh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Feb 2020 21:04:54 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 01BKXfqJ004723; Tue, 11 Feb 2020 16:04:53 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint8.akamai.com with ESMTP id 2y1s72apkt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 11 Feb 2020 16:04:52 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.165.123) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 11 Feb 2020 15:04:51 -0600 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.165.123]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.165.123]) with mapi id 15.00.1473.005; Tue, 11 Feb 2020 15:04:51 -0600 From: "Lubashev, Igor" To: Roberto Peon , Erik Kline CC: Lars Eggert , HAMCHAOUI Isabelle IMT/OLN , IETF QUIC WG , "alexandre.ferrieux@orange.com" , "Dmitri Tikhonov" Subject: RE: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt Thread-Topic: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt Thread-Index: AQHVzLqrJ8K1dwlaC0usEEtR2wTsCqft3wQQgChYbACAAB/50IAArJaAgAABHQD//53+UA== Date: Tue, 11 Feb 2020 21:04:50 +0000 Message-ID: <16d7759ce1de46b59d0ff0a60d22f0b2@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <157921301012.26216.13677469865378306147.idtracker@ietfa.amsl.com> <180dde305bf149efb19a88e61967a87a@ustx2ex-dag1mb5.msg.corp.akamai.com> <851a81d65a9a4318914b9b18fd0b0605@ustx2ex-dag1mb5.msg.corp.akamai.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.117.59] Content-Type: multipart/alternative; boundary="_000_16d7759ce1de46b59d0ff0a60d22f0b2ustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-11_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002110136 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-11_05:2020-02-11, 2020-02-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 mlxlogscore=999 clxscore=1011 priorityscore=1501 mlxscore=0 impostorscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002110137 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 21:05:08 -0000 --_000_16d7759ce1de46b59d0ff0a60d22f0b2ustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBub3QgbGF1Z2hpbmfigKYg8J+YiQ0KDQpZZXMsIHRoYXTigJlzIGhvdyBJIHJl YWQgdGhlIHF1ZXN0aW9uLCB0b28uICBIZW5jZSBJIHJlcGxpZWQ6IOKAnEkgYWdyZWUgdGhhdCB0 aGUgZHJhZnQgY291bGQgYmVuZWZpdCBmcm9tIHRoZSBleHBsYW5hdGlvbiBvZiB3aHkgd2UgdXNl IFFVSUMgdjEgcmVzZXJ2ZWQgaGVhZGVyIGJpdHMgaW5zdGVhZCBvZiBzb21lIGJpdHMgaW4gYSBs b3dlciBsYXllciAob3IgbW9yZSBiaXRzIG91dHNpZGUgb2YgdGhlIGhlYWRlciBpbiB0aGUgUVVJ QyBwYWNrZXQpLuKAnSAgQW5kIEkgYWRkZWQgYW4gaXNzdWUgdG8gdGhpcyBlZmZlY3QsIHRvbyAo aHR0cHM6Ly9naXRodWIuY29tL2lnb3Jsb3JkL2RyYWZ0LWZlcnJpZXV4aGFtY2hhb3VpLWxvc3Ni aXRzL2lzc3Vlcy8zNykuDQoNCkJ1dCwgc2luY2UgdGhlIHJlYXNvbmluZyB3YXMsIGluZGVlZCwg bWlzc2luZyBmcm9tIHRoZSBkcmFmdCwgSSBraW5kIG9mIHN1bW1hcml6ZWQgaXQgYWZ0ZXIuDQoN Cg0KICAqICAgSWdvcg0KDQpGcm9tOiBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbT4NCg0KTm90 IGxhdWdoaW5nIG92ZXIgaGVyZeKApg0KDQpASWdvcuKAlEkgdGhpbmsgdGhlIHF1ZXN0aW9uIHdh cyBpZiB3ZSBjb3VsZCBwdXQgdGhlIHJlYXNvbmluZyBpbnRvIHRoZSBkcmFmdCENCi09Ug0KDQpG cm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZz4+IG9uIGJlaGFsZiBvZiBFcmlrIEtsaW5lIDxlay5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 ZWsuaWV0ZkBnbWFpbC5jb20+Pg0KRGF0ZTogVHVlc2RheSwgRmVicnVhcnkgMTEsIDIwMjAgYXQg MTI6NDcgUE0NClRvOiAiTHViYXNoZXYsIElnb3IiIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0 bzppbHViYXNoZUBha2FtYWkuY29tPj4NCkNjOiBMYXJzIEVnZ2VydCA8bGFyc0BlZ2dlcnQub3Jn PG1haWx0bzpsYXJzQGVnZ2VydC5vcmc+PiwgSEFNQ0hBT1VJIElzYWJlbGxlIElNVC9PTE4gPGlz YWJlbGxlLmhhbWNoYW91aUBvcmFuZ2UuY29tPG1haWx0bzppc2FiZWxsZS5oYW1jaGFvdWlAb3Jh bmdlLmNvbT4+LCBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5v cmc+PiwgImFsZXhhbmRyZS5mZXJyaWV1eEBvcmFuZ2UuY29tPG1haWx0bzphbGV4YW5kcmUuZmVy cmlldXhAb3JhbmdlLmNvbT4iIDxhbGV4YW5kcmUuZmVycmlldXhAb3JhbmdlLmNvbTxtYWlsdG86 YWxleGFuZHJlLmZlcnJpZXV4QG9yYW5nZS5jb20+PiwgRG1pdHJpIFRpa2hvbm92IDxkdGlraG9u b3ZAbGl0ZXNwZWVkdGVjaC5jb208bWFpbHRvOmR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbT4+ DQpTdWJqZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1mZXJyaWV1 eGhhbWNoYW91aS1xdWljLWxvc3NiaXRzLTAzLnR4dA0KDQpPbiBUdWUsIEZlYiAxMSwgMjAyMCBh dCA4OjQ2IEFNIEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHVi YXNoZUBha2FtYWkuY29tPj4gd3JvdGU6DQo+IEZyb206IExhcnMgRWdnZXJ0IDxsYXJzQGVnZ2Vy dC5vcmc8bWFpbHRvOmxhcnNAZWdnZXJ0Lm9yZz4+DQo+DQo+IEhpLA0KPg0KPiAoY2hhaXIgaGF0 IG9mZikNCj4NCj4gdGhlIGRyYWZ0IHBvaW50cyB0byB0aGUgQ09ORVggd29yayBhbmQgc2F5cyB0 aGlzOg0KPg0KPiAgICBUaGlzIGxvc3Mgc2lnbmFsaW5nIGlzIHNpbWlsYXIgdG8gbG9zcyBzaWdu YWxpbmcgaW4gW1JGQzc3MTNdLCBleGNlcHQNCj4gICAgdGhlIExvc3MgRXZlbnQgYml0IGlzIHJl cG9ydGluZyB0aGUgZXhhY3QgbnVtYmVyIG9mIGxvc3QgcGFja2V0cywNCj4gICAgd2hlcmVhcyB0 aGUgRWNobyBMb3NzIGJpdCBpbiBbUkZDNzcxM10gaXMgcmVwb3J0aW5nIGFuIGFwcHJveGltYXRl DQo+ICAgIG51bWJlciBvZiBsb3N0IGJ5dGVzLg0KPg0KPiBXaGF0IGl0IGRvZXNuJ3Qgc2F5IGlz IHdoeSB0aGUgQ09ORVggZnVuY3Rpb25hbGl0eSBpcyBiZWluZyBwcm9wb3NlZCB0byBiZQ0KPiBp bmNvcnBvcmF0ZWQgaW50byBRVUlDLCByYXRoZXIgdGhhbiBzdGF5aW5nIGF0IHRoZSBJUCBsZXZl bCB3aGVyZSBpdCBhcmd1YWJseQ0KPiBiZWxvbmdzPw0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFj ay4gSSBhZ3JlZSB0aGF0IHRoZSBkcmFmdCBjb3VsZCBiZW5lZml0IGZyb20gdGhlIGV4cGxhbmF0 aW9uIG9mIHdoeSB3ZSB1c2UgUVVJQyB2MSByZXNlcnZlZCBoZWFkZXIgYml0cyBpbnN0ZWFkIG9m IHNvbWUgYml0cyBpbiBhIGxvd2VyIGxheWVyIChvciBtb3JlIGJpdHMgb3V0c2lkZSBvZiB0aGUg aGVhZGVyIGluIHRoZSBRVUlDIHBhY2tldCkuDQoNClRoZSBzaG9ydCBhbnN3ZXIgaXMgZGVwbG95 YWJpbGl0eS4gIFRoZXJlIGlzIG5vIHBvaW50IGluIHdyaXRpbmcgZHJhZnRzIHRoYXQgd2lsbCBz aXQgb24gYSBzaGVsZiwgYmVjYXVzZSBubyBvbmUgd2lsbCB3YW50IHRvIGRlcGxveSB0aGVtIGZv ciBhdCBsZWFzdCBhIGRlY2FkZS4gIENPTkVYIGlzIG9uZSBleGFtcGxlLCBwbGFndWVkIGJ5IHRo ZSBkaWZmaWN1bHR5IG9mIGdldHRpbmcgSVB2NiBleHRlbnNpb24gaGVhZGVycyBkZXBsb3llZC4g IEFuZCBnb29kIGx1Y2sgd2l0aCBzaW1pbGFyIElQdjQgZXh0ZW5zaW9ucy4NCg0KSGVuY2Ugd2Ug Ym9ycm93IENPTkVYIGlkZWFzIGJ1dCB0cnkgdG8gaW1wbGVtZW50IHRoZW0gaW4gYSB3YXkgdGhh dCBpcyBzdGlsbCBwb3NzaWJsZSwgd2hpbGUgdXNpbmcgZ3JlYXNpbmcgYW5kIGFudGktb3NzaWZp Y2F0aW9uIHRlY2huaXF1ZXMuDQoNCj4gVGhhbmtzLA0KPiBMYXJzDQoNCkJlc3QsDQotIElnb3IN Cg0KRm9sa3MgbWlnaHQgbGF1Z2gsIGJ1dCBJIHRoaW5rIHJlYWxpc3RpY2FsbHkgd2UnbGwgYmUg bG9va2luZyB0b3dhcmRzIFVEUCB0cmFpbGVycyBhdCBzb21lIHBvaW50Lg0K --_000_16d7759ce1de46b59d0ff0a60d22f0b2ustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE3ODI5OTQ0OTQ7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODQzNjA3MDIwIC0z NzU1MTQ2MDYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzIGZvciBub3QgbGF1Z2hpbmfigKYgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWYiPg0KJiMxMjg1MjE7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHRoYXTigJlzIGhvdyBJIHJlYWQgdGhlIHF1ZXN0aW9u LCB0b28uJm5ic3A7IEhlbmNlIEkgcmVwbGllZDog4oCcSSBhZ3JlZSB0aGF0IHRoZSBkcmFmdCBj b3VsZCBiZW5lZml0IGZyb20gdGhlIGV4cGxhbmF0aW9uIG9mIHdoeSB3ZSB1c2UgUVVJQyB2MSBy ZXNlcnZlZCBoZWFkZXIgYml0cyBpbnN0ZWFkIG9mIHNvbWUgYml0cyBpbiBhIGxvd2VyIGxheWVy IChvciBtb3JlIGJpdHMgb3V0c2lkZSBvZiB0aGUgaGVhZGVyDQogaW4gdGhlIFFVSUMgcGFja2V0 KS7igJ0mbmJzcDsgQW5kIEkgYWRkZWQgYW4gaXNzdWUgdG8gdGhpcyBlZmZlY3QsIHRvbyAoPGEg aHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2lnb3Jsb3JkL2RyYWZ0LWZlcnJpZXV4aGFtY2hhb3Vp LWxvc3NiaXRzL2lzc3Vlcy8zNyI+aHR0cHM6Ly9naXRodWIuY29tL2lnb3Jsb3JkL2RyYWZ0LWZl cnJpZXV4aGFtY2hhb3VpLWxvc3NiaXRzL2lzc3Vlcy8zNzwvYT4pLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CdXQsIHNpbmNlIHRoZSByZWFzb25pbmcgd2FzLCBpbmRlZWQsIG1pc3NpbmcgZnJv bSB0aGUgZHJhZnQsIEkga2luZCBvZiBzdW1tYXJpemVkIGl0IGFmdGVyLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPklnb3I8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gUm9iZXJ0byBQZW9uICZsdDtmZW5peEBmYi5jb20mZ3Q7IDxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk5vdCBsYXVnaGluZyBvdmVyIGhlcmXigKY8YnI+DQo8YnI+DQpASWdvcuKAlEkgdGhp bmsgdGhlIHF1ZXN0aW9uIHdhcyBpZiB3ZSBjb3VsZCBwdXQgdGhlIHJlYXNvbmluZyBpbnRvIHRo ZSBkcmFmdCE8YnI+DQotPVI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPlFVSUMgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPnF1aWMt Ym91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBFcmlrIEtsaW5lICZsdDs8YSBo cmVmPSJtYWlsdG86ZWsuaWV0ZkBnbWFpbC5jb20iPmVrLmlldGZAZ21haWwuY29tPC9hPiZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgRmVicnVhcnkgMTEsIDIwMjAgYXQgMTI6NDcgUE08 YnI+DQo8Yj5UbzogPC9iPiZxdW90O0x1YmFzaGV2LCBJZ29yJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5MYXJzIEVnZ2VydCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhcnNAZWdnZXJ0 Lm9yZyI+bGFyc0BlZ2dlcnQub3JnPC9hPiZndDssIEhBTUNIQU9VSSBJc2FiZWxsZSBJTVQvT0xO ICZsdDs8YSBocmVmPSJtYWlsdG86aXNhYmVsbGUuaGFtY2hhb3VpQG9yYW5nZS5jb20iPmlzYWJl bGxlLmhhbWNoYW91aUBvcmFuZ2UuY29tPC9hPiZndDssIElFVEYgUVVJQyBXRyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEg aHJlZj0ibWFpbHRvOmFsZXhhbmRyZS5mZXJyaWV1eEBvcmFuZ2UuY29tIj5hbGV4YW5kcmUuZmVy cmlldXhAb3JhbmdlLmNvbTwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRy ZS5mZXJyaWV1eEBvcmFuZ2UuY29tIj5hbGV4YW5kcmUuZmVycmlldXhAb3JhbmdlLmNvbTwvYT4m Z3Q7LCBEbWl0cmkgVGlraG9ub3YgJmx0OzxhIGhyZWY9Im1haWx0bzpkdGlraG9ub3ZAbGl0ZXNw ZWVkdGVjaC5jb20iPmR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJlOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZlcnJp ZXV4aGFtY2hhb3VpLXF1aWMtbG9zc2JpdHMtMDMudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIg MTEsIDIwMjAgYXQgODo0NiBBTSBMdWJhc2hldiwgSWdvciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmls dWJhc2hlQGFrYW1haS5jb20iPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij4mZ3Q7IEZyb206IExhcnMgRWdnZXJ0ICZsdDs8YSBocmVmPSJtYWlsdG86 bGFyc0BlZ2dlcnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+bGFyc0BlZ2dlcnQub3JnPC9hPiZndDs8 YnI+DQomZ3Q7IDxicj4NCiZndDsgSGksPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IChjaGFpciBoYXQg b2ZmKTxicj4NCiZndDsgPGJyPg0KJmd0OyB0aGUgZHJhZnQgcG9pbnRzIHRvIHRoZSBDT05FWCB3 b3JrIGFuZCBzYXlzIHRoaXM6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBUaGlz IGxvc3Mgc2lnbmFsaW5nIGlzIHNpbWlsYXIgdG8gbG9zcyBzaWduYWxpbmcgaW4gW1JGQzc3MTNd LCBleGNlcHQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB0aGUgTG9zcyBFdmVudCBiaXQgaXMgcmVw b3J0aW5nIHRoZSBleGFjdCBudW1iZXIgb2YgbG9zdCBwYWNrZXRzLDxicj4NCiZndDsmbmJzcDsg Jm5ic3A7IHdoZXJlYXMgdGhlIEVjaG8gTG9zcyBiaXQgaW4gW1JGQzc3MTNdIGlzIHJlcG9ydGlu ZyBhbiBhcHByb3hpbWF0ZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG51bWJlciBvZiBsb3N0IGJ5 dGVzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBXaGF0IGl0IGRvZXNuJ3Qgc2F5IGlzIHdoeSB0aGUg Q09ORVggZnVuY3Rpb25hbGl0eSBpcyBiZWluZyBwcm9wb3NlZCB0byBiZTxicj4NCiZndDsgaW5j b3Jwb3JhdGVkIGludG8gUVVJQywgcmF0aGVyIHRoYW4gc3RheWluZyBhdCB0aGUgSVAgbGV2ZWwg d2hlcmUgaXQgYXJndWFibHk8YnI+DQomZ3Q7IGJlbG9uZ3M/PGJyPg0KPGJyPg0KVGhhbmtzIGZv ciB0aGUgZmVlZGJhY2suIEkgYWdyZWUgdGhhdCB0aGUgZHJhZnQgY291bGQgYmVuZWZpdCBmcm9t IHRoZSBleHBsYW5hdGlvbiBvZiB3aHkgd2UgdXNlIFFVSUMgdjEgcmVzZXJ2ZWQgaGVhZGVyIGJp dHMgaW5zdGVhZCBvZiBzb21lIGJpdHMgaW4gYSBsb3dlciBsYXllciAob3IgbW9yZSBiaXRzIG91 dHNpZGUgb2YgdGhlIGhlYWRlciBpbiB0aGUgUVVJQyBwYWNrZXQpLjxicj4NCjxicj4NClRoZSBz aG9ydCBhbnN3ZXIgaXMgZGVwbG95YWJpbGl0eS4mbmJzcDsgVGhlcmUgaXMgbm8gcG9pbnQgaW4g d3JpdGluZyBkcmFmdHMgdGhhdCB3aWxsIHNpdCBvbiBhIHNoZWxmLCBiZWNhdXNlIG5vIG9uZSB3 aWxsIHdhbnQgdG8gZGVwbG95IHRoZW0gZm9yIGF0IGxlYXN0IGEgZGVjYWRlLiZuYnNwOyBDT05F WCBpcyBvbmUgZXhhbXBsZSwgcGxhZ3VlZCBieSB0aGUgZGlmZmljdWx0eSBvZiBnZXR0aW5nIElQ djYgZXh0ZW5zaW9uIGhlYWRlcnMgZGVwbG95ZWQuJm5ic3A7IEFuZA0KIGdvb2QgbHVjayB3aXRo IHNpbWlsYXIgSVB2NCBleHRlbnNpb25zLjxicj4NCjxicj4NCkhlbmNlIHdlIGJvcnJvdyBDT05F WCBpZGVhcyBidXQgdHJ5IHRvIGltcGxlbWVudCB0aGVtIGluIGEgd2F5IHRoYXQgaXMgc3RpbGwg cG9zc2libGUsIHdoaWxlIHVzaW5nIGdyZWFzaW5nIGFuZCBhbnRpLW9zc2lmaWNhdGlvbiB0ZWNo bmlxdWVzLjxicj4NCjxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgTGFyczxicj4NCjxicj4N CkJlc3QsPGJyPg0KLSBJZ29yPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb2xrcyBtaWdodCBsYXVnaCwgYnV0IEkgdGhpbmsgcmVh bGlzdGljYWxseSB3ZSdsbCBiZSBsb29raW5nIHRvd2FyZHMgVURQIHRyYWlsZXJzIGF0IHNvbWUg cG9pbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_16d7759ce1de46b59d0ff0a60d22f0b2ustx2exdag1mb5msgcorpak_-- From nobody Tue Feb 11 14:59:19 2020 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 7BE5F120829 for ; Tue, 11 Feb 2020 14:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 pW2Z60-_RTrX for ; Tue, 11 Feb 2020 14:59:15 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 48855120826 for ; Tue, 11 Feb 2020 14:59:15 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id w15so14643025wru.4 for ; Tue, 11 Feb 2020 14:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BsuzC2wHXq2ghzRPNO0LYwrgl6YnceDsYe/Al8eF/fE=; b=F3aksLJ2Cu7kMsfXeg+JzRP9Y46moxkDd1rFXvhynfj1+AA9upgz33C88TZxIiimuT Q3HNbKK9y8kVCZW3FtMW7EstFKQD2KrRKyjg4otPpdX14TgoZIeO6FYlxKUOUTZWQoMc OpYqa+LIkUYHHVjcWEu/gNeg+/QQZzkU7RyQHXfTLOorM5wNqD5YdPjMJffrQYEjmMl8 jyc6YQ0jpEGzYBH6NQ0babN/9BEY1uUGkKejHutfnPMx3pJ4PZ8nKbCQjfXaC1Bv4/gt lo4lGbiAAOkkFFSAyC44yCsYfSijBKjqRqu8q/aNgHYnCxSGu4OAdJwR2VOs+wPS3OgG CzVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=BsuzC2wHXq2ghzRPNO0LYwrgl6YnceDsYe/Al8eF/fE=; b=DeSKOdq/w3v1VQDpMi8mrJauf4VRXBcFGzkCMefPQTO6ebrUGtbD1lxG3U+kuaIo+h k1aHi+kfTi4C8IzOBRGvyp3vYOKTsRLKaN1q7TKxnJ3VZWflzFajWDpwqwTCBJWFf/eV N/1eBs0157RV1uf7wksxR4PsNy0dTUxXklhMdriqaxJvEhwF4YbIZJ4jE7ZjCn0trWMz qLcpH9zRMwvpOlfGrCCL4vGqa09OtoHblvSnkc2Q2jDS62UfHXvY6AC70qbLD2L+PLJm VG87cAbYHY2nLw7t3l2w8RX2E9IEklZGUN7E0c06ezHnnF32gS9LYNj7Ph6EVm8sgPec R1rQ== X-Gm-Message-State: APjAAAU9vGOZT0yhAUAri3AbxMnyuM6iyDYznUjvi+uhenIKngZhqa59 u9hzrHbQP0IpuUFaKFG1NQHt/ldhokc5QuODGApHLeZQ X-Google-Smtp-Source: APXvYqxI4ZljWTV3AC3FTcD1MDb49Fz2d6P6JQZ7vJZ7SXVjov93l7EWV2BoWSIUYl4AMKLlS4lAlTpuJi1/dp5YnPo= X-Received: by 2002:a5d:63c7:: with SMTP id c7mr12007953wrw.158.1581461953423; Tue, 11 Feb 2020 14:59:13 -0800 (PST) MIME-Version: 1.0 References: <158145486391.19903.8276757561393517329.idtracker@ietfa.amsl.com> In-Reply-To: <158145486391.19903.8276757561393517329.idtracker@ietfa.amsl.com> From: Martin Duke Date: Tue, 11 Feb 2020 14:59:02 -0800 Message-ID: Subject: Fwd: New Version Notification for draft-duke-quic-natsupp-01.txt To: IETF QUIC WG , Dan Wing Content-Type: multipart/alternative; boundary="000000000000f5ad5e059e54cd60" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 22:59:17 -0000 --000000000000f5ad5e059e54cd60 Content-Type: text/plain; charset="UTF-8" Here's new draft that incorporates Mirja's and Dan Wing's comments. It also adds some language that using QUIC-LB on the client is a bad idea. After discussing with Mirja, I think we agreed that leaving this as an individual draft that the ops draft references may be the least painful path, pending a discussion with Gorry if this is worth putting in TSVWG to match similar documents for other protocols. ---------- Forwarded message --------- From: Date: Tue, Feb 11, 2020 at 1:01 PM Subject: New Version Notification for draft-duke-quic-natsupp-01.txt To: Martin Duke A new version of I-D, draft-duke-quic-natsupp-01.txt has been successfully submitted by Martin Duke and posted to the IETF repository. Name: draft-duke-quic-natsupp Revision: 01 Title: Network Address Translation Support for QUIC Document date: 2020-02-11 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-duke-quic-natsupp-01.txt Status: https://datatracker.ietf.org/doc/draft-duke-quic-natsupp/ Htmlized: https://tools.ietf.org/html/draft-duke-quic-natsupp-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-duke-quic-natsupp Diff: https://www.ietf.org/rfcdiff?url2=draft-duke-quic-natsupp-01 Abstract: Network Address Translators (NATs) are widely deployed to share scarce public IPv4 addresses among multiple end hosts. They overwrite IP addresses and ports in IP packets to do so. QUIC is a protocol on top of UDP that provides transport-like services. QUIC is better-behaved in the presence of NATs than older protocols, and existing UDP NATs should operate without incident if unmodified. QUIC offers additional features that may tempt NAT implementers as potential optimizations. However, in practice, leveraging these features will lead to new connection failure modes and security vulnerabilities. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000f5ad5e059e54cd60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here's new draft that incorporates Mirja's an= d Dan Wing's comments. It also adds some language that using QUIC-LB on= the client is a bad idea.

After discussing with M= irja, I think we agreed that leaving this as an individual draft that the o= ps draft references may be the least painful path, pending a discussion wit= h Gorry if this is worth putting in TSVWG to match similar documents for ot= her protocols.

---------- Forwarded message ---------
From: <internet-dra= fts@ietf.org>
Date: Tue, Feb 11, 2020 at 1:01 PM
Subjec= t: New Version Notification for draft-duke-quic-natsupp-01.txt
To: Marti= n Duke <martin.h.duke@gmail.c= om>



A new version of I-D, draft-duke-quic-natsupp-01.txt
has been successfully submitted by Martin Duke and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-duke-quic-natsupp
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Network Address Translation Suppor= t for QUIC
Document date:=C2=A0 2020-02-11
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-duke-quic-natsupp-0= 1.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-duke-quic-natsupp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-duke-quic-natsupp-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/html/draft-duke-quic-natsupp
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-duke-quic-natsupp-01<= br>
Abstract:
=C2=A0 =C2=A0Network Address Translators (NATs) are widely deployed to shar= e
=C2=A0 =C2=A0scarce public IPv4 addresses among multiple end hosts.=C2=A0 T= hey
=C2=A0 =C2=A0overwrite IP addresses and ports in IP packets to do so.=C2=A0= QUIC is a
=C2=A0 =C2=A0protocol on top of UDP that provides transport-like services.= =C2=A0 QUIC
=C2=A0 =C2=A0is better-behaved in the presence of NATs than older protocols= , and
=C2=A0 =C2=A0existing UDP NATs should operate without incident if unmodifie= d.
=C2=A0 =C2=A0QUIC offers additional features that may tempt NAT implementer= s as
=C2=A0 =C2=A0potential optimizations.=C2=A0 However, in practice, leveragin= g these
=C2=A0 =C2=A0features will lead to new connection failure modes and securit= y
=C2=A0 =C2=A0vulnerabilities.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--000000000000f5ad5e059e54cd60-- From nobody Tue Feb 11 18:33:26 2020 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 74F52120071 for ; Tue, 11 Feb 2020 18:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=kVLcgzcA; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=d7u7yHeG 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 UQ7wYl5-FCP0 for ; Tue, 11 Feb 2020 18:33:21 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 A669F12004D for ; Tue, 11 Feb 2020 18:33:21 -0800 (PST) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.42/8.16.0.42) with SMTP id 01C2Tr98023126; Tue, 11 Feb 2020 18:33:15 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=ya2mSW2hx1i3Lyh1eD/HLnIazU4I/NlAkRPF/6Ia8iI=; b=kVLcgzcAsyoSSKg9qLxyGKKO+0n71cC7XfjxSq4ix5HrYSjjudeK8IB7xJ0lfg1iGfpJ +r2VXH9qwUyaw7thjiSvIU0P8SM959XL07bLRzxVzsNQTkFCoKQB0GJaza3ZyXE5jiKX xpJlWWBw085egABCyJFVfo3lsQMljyC/T18= Received: from maileast.thefacebook.com ([163.114.130.16]) by m0089730.ppops.net with ESMTP id 2y2ftexgea-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 11 Feb 2020 18:33:15 -0800 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.35.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 11 Feb 2020 18:33:14 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LAAwgSvB9ZhQ0yUiBCFoQ2xRqBBfyzipvbQNL+AyxVn1AIZEe9qbDWKqJNrShceHGYCiy9cFTTQdqu92Z2KjohGfhfR+xJvfjMJzkmaHWDDQL1T+aHMA39h8NHdtdAxEu59bpgxpvHYYMuqiQCrVl9RFMuI6RnOkISeVBTIbBOYf9xkmcLJPQprNb20zKFPUFk3uEkGLiYMpAwjv26MzqH4BqjWXdY3ksHcozAD097SfSoHhiYuUk87/wLwvkdsHIUGSPhqXipSQH+AQm2va74EqAdomo5qGLToOvted49cnsx1KhC3+gbtzRAPzqcHh20gcML1PWN8EClL7JQo+7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ya2mSW2hx1i3Lyh1eD/HLnIazU4I/NlAkRPF/6Ia8iI=; b=At/+5+WHWXsY+vvfUCmmsGviXsEAt/p4RkY0PXGPBB4msMz1pNRFDuaFXKgOWVL+33KPAnqCZnYzeumckpcoyAmGpRvO9RrRtXRY/gfsN6J88w6/qSRROOufvpMuxRbIsagQlF4n6beg1mBCck7q/b8QRYvJBL1MmAKjiBIozGhL7Bi35oiMR/ZJiaewosb3XvDxYKRhx7ZxwcbxwDyEw4bSZaYcA7BznsGX4YkfnxJzjn86hdBq0P4tVxcQb5yxtGbJ6i0c4Dqp0g1R7XQbaMhFZG4UyiI4jXeJZ3QECJaaMoqYXm1OnnNp6XD9UHdpBCkkcF3eNl2ydhePZmCzjg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector2-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ya2mSW2hx1i3Lyh1eD/HLnIazU4I/NlAkRPF/6Ia8iI=; b=d7u7yHeGofqiNxFQHtzooxQszUxNcCFmvinE/unYgamMsvE8fgNFpLraMhk2IE4kkQKZe10o62040KaainR0QUcVddIx/2W+Um4EysCrjNCi0mnLIOS1bbyG7bDkkica9yTd9O51quJlb7eLCbvzdiqA12t1iA5oPZ1Ka3NpLcE= Received: from MWHPR15MB1935.namprd15.prod.outlook.com (10.174.96.149) by MWHPR15MB1488.namprd15.prod.outlook.com (10.173.235.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Wed, 12 Feb 2020 02:33:13 +0000 Received: from MWHPR15MB1935.namprd15.prod.outlook.com ([fe80::ac5f:bc9e:f7c2:e35f]) by MWHPR15MB1935.namprd15.prod.outlook.com ([fe80::ac5f:bc9e:f7c2:e35f%12]) with mapi id 15.20.2707.030; Wed, 12 Feb 2020 02:33:13 +0000 From: Roberto Peon To: Erik Kline , "Lubashev, Igor" CC: Lars Eggert , HAMCHAOUI Isabelle IMT/OLN , IETF QUIC WG , "alexandre.ferrieux@orange.com" , "Dmitri Tikhonov" Subject: Re: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt Thread-Topic: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt Thread-Index: AQHVzLqrJ8K1dwlaC0usEEtR2wTsCqft3wQQgCfz1wCAAIk4AIAAQ1eA//96/4CAAIntAIAAW6D9 Date: Wed, 12 Feb 2020 02:33:13 +0000 Message-ID: References: <157921301012.26216.13677469865378306147.idtracker@ietfa.amsl.com> <180dde305bf149efb19a88e61967a87a@ustx2ex-dag1mb5.msg.corp.akamai.com> <851a81d65a9a4318914b9b18fd0b0605@ustx2ex-dag1mb5.msg.corp.akamai.com> , <16d7759ce1de46b59d0ff0a60d22f0b2@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <16d7759ce1de46b59d0ff0a60d22f0b2@ustx2ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.234.190.115] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 91eb2d0f-9b91-4eb7-295c-08d7af63e889 x-ms-traffictypediagnostic: MWHPR15MB1488: x-microsoft-antispam-prvs: x-fb-source: Internal x-ms-oob-tlc-oobclassifiers: OLM:3044; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(136003)(346002)(396003)(39860400002)(199004)(189003)(66946007)(66476007)(64756008)(8936002)(66556008)(52536014)(5660300002)(76116006)(110136005)(54906003)(316002)(19627235002)(66446008)(91956017)(2906002)(7696005)(15650500001)(71200400001)(33656002)(81156014)(4326008)(86362001)(9686003)(186003)(55016002)(26005)(53546011)(6506007)(478600001)(45080400002)(8676002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1488; H:MWHPR15MB1935.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: C2YmB/Bo5uHTPHOz8b3jFLyELFOzMmp1a+pjMUuhXC0pR5/5Kwq/4NtpzIzinoxYGojscunj97dIloD1zbNl9/3vhr3qofMCi5C2dfeuzMPKhvs3NBazGLKXd7oVd2mGjCTuWlImWH3Wv2Hx1JXi5bYl5TmN/pjsrfPy9WBzpjA8qXPS3EBjvuEk2stAK7IpBiN8kP6W+rOL0j6E3trTexn1jt/FdJ6Fxj7Onh7nWLcOPrTICU0oEWjST1nh+KFusePRhn1nfP3HjZ47Z4tjXPCl0qqGB1niaWZUrheXarX2vj2qP47A0+QoPnYUlCtVw8Oah6cvpZ7Cv0II6x5hfKpyee1UFppokbibR6IcTfNkuaw7DCZYSdw8eBfXw/fpqtMFWq/Yj7ciUbaeS7NPskt+ff736d3/0eImsaFOFHVkhkYTxklS8OCCe52giWW/mf5fuOL4+B2IEbH516w9lFJe5MMbgIGhGvENmHz+8XGiUHKTZ4HLXFLmve6jgEq6 x-ms-exchange-antispam-messagedata: 8BOUYvTlaiIAXjyljMWY4O5cIof4E11e/A47qzxEgWLWityx4wNZ35rdZjOJjgU9kR/z5j0ihYYtfrJ9gGaeN498sV1s/NS65KtYJqSAi/0fTotcSfVRrOqcbCXJLLtrfzfM1/5gh0LKA83FmreC5A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1935FC4A378BA641D87DAD39CD1B0MWHPR15MB1935namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 91eb2d0f-9b91-4eb7-295c-08d7af63e889 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2020 02:33:13.1082 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HkJExBK4eX91bhCDKSpPgqyDxcTo+n8fe8hiWUb3mjIjR7wlDvCe+wL/UDsH3XDi X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1488 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-11_07:2020-02-11, 2020-02-11 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 mlxscore=0 bulkscore=0 phishscore=0 priorityscore=1501 spamscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 adultscore=0 mlxlogscore=999 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002120014 X-FB-Internal: deliver Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 02:33:24 -0000 --_000_MWHPR15MB1935FC4A378BA641D87DAD39CD1B0MWHPR15MB1935namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I should have known you were already on top of it, lol! -=3DR Get Outlook for Android ________________________________ From: Lubashev, Igor Sent: Tuesday, February 11, 2020 1:04:50 PM To: Roberto Peon ; Erik Kline Cc: Lars Eggert ; HAMCHAOUI Isabelle IMT/OLN ; IETF QUIC WG ; alexandre.ferrieux@orange= .com ; Dmitri Tikhonov Subject: RE: New Version Notification for draft-ferrieuxhamchaoui-quic-loss= bits-03.txt Thanks for not laughing=85 ?? Yes, that=92s how I read the question, too. Hence I replied: =93I agree th= at the draft could benefit from the explanation of why we use QUIC v1 reser= ved header bits instead of some bits in a lower layer (or more bits outside= of the header in the QUIC packet).=94 And I added an issue to this effect= , too (https://github.com/igorlord/draft-ferrieuxhamchaoui-lossbits/issues/= 37). But, since the reasoning was, indeed, missing from the draft, I kind of sum= marized it after. * Igor From: Roberto Peon Not laughing over here=85 @Igor=97I think the question was if we could put the reasoning into the dra= ft! -=3DR From: QUIC > on behalf = of Erik Kline > Date: Tuesday, February 11, 2020 at 12:47 PM To: "Lubashev, Igor" > Cc: Lars Eggert >, HAMCHAOUI Isabel= le IMT/OLN >, IETF QUIC WG >, "alexandre.ferri= eux@orange.com" >, Dmitri Tikhonov > Subject: Re: New Version Notification for draft-ferrieuxhamchaoui-quic-loss= bits-03.txt On Tue, Feb 11, 2020 at 8:46 AM Lubashev, Igor > wrote: > From: Lars Eggert > > > Hi, > > (chair hat off) > > the draft points to the CONEX work and says this: > > This loss signaling is similar to loss signaling in [RFC7713], except > the Loss Event bit is reporting the exact number of lost packets, > whereas the Echo Loss bit in [RFC7713] is reporting an approximate > number of lost bytes. > > What it doesn't say is why the CONEX functionality is being proposed to b= e > incorporated into QUIC, rather than staying at the IP level where it argu= ably > belongs? Thanks for the feedback. I agree that the draft could benefit from the expl= anation of why we use QUIC v1 reserved header bits instead of some bits in = a lower layer (or more bits outside of the header in the QUIC packet). The short answer is deployability. There is no point in writing drafts tha= t will sit on a shelf, because no one will want to deploy them for at least= a decade. CONEX is one example, plagued by the difficulty of getting IPv6= extension headers deployed. And good luck with similar IPv4 extensions. Hence we borrow CONEX ideas but try to implement them in a way that is stil= l possible, while using greasing and anti-ossification techniques. > Thanks, > Lars Best, - Igor Folks might laugh, but I think realistically we'll be looking towards UDP t= railers at some point. --_000_MWHPR15MB1935FC4A378BA641D87DAD39CD1B0MWHPR15MB1935namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I should have known you were already on top of it, lol!
-=3DR

From: Lubashev, Igor <il= ubashe@akamai.com>
Sent: Tuesday, February 11, 2020 1:04:50 PM
To: Roberto Peon <fenix@fb.com>; Erik Kline <ek.ietf@gmail.= com>
Cc: Lars Eggert <lars@eggert.org>; HAMCHAOUI Isabelle IMT/OLN = <isabelle.hamchaoui@orange.com>; IETF QUIC WG <quic@ietf.org>; = alexandre.ferrieux@orange.com <alexandre.ferrieux@orange.com>; Dmitri= Tikhonov <dtikhonov@litespeedtech.com>
Subject: RE: New Version Notification for draft-ferrieuxhamchaoui-qu= ic-lossbits-03.txt
 

Thanks for not laughing=85 😉

 

Yes, that=92s how I read the question, too.  = Hence I replied: =93I agree that the draft could benefit from the explanati= on of why we use QUIC v1 reserved header bits instead of some bits in a low= er layer (or more bits outside of the header in the QUIC packet).=94  And I added an issue to this effect, too (https://github.com/igorlord/draft-ferrieuxhamchaoui-lossbits/issues/3= 7).

 

But, since the reasoning was, indeed, missing from= the draft, I kind of summarized it after.

 

  • Igor

 

From: Roberto Peon <fenix@fb.com>

Not laughing over here=85

@Igor=97I think the question was if we could put the reasoning into the dra= ft!
-=3DR

 

F= rom: QUIC <quic-bounces@ietf.org> on behalf of Erik Kl= ine <ek.ietf@gmail.com>
Date: Tuesday, February 11, 2020 at 12:47 PM
To: "Lubashev, Igor" <ilubashe@akamai.com>
Cc: Lars Eggert <lars@eggert.o= rg>, HAMCHAOUI Isabelle IMT/OLN <isabelle.hamchaoui@orange.com>, IETF QUIC WG <quic@ietf.org>, "alexandre.ferrieux@orange.com" <alexandre.ferrieux@or= ange.com>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Subject: Re: New Version Notification for draft-ferrieuxhamchaoui-qu= ic-lossbits-03.txt

 

On Tue, Feb 11, 2020 at 8:46 AM Lubashev, Igor <= ;ilubashe@akamai.com> wrote:<= /p>

> From: Lars Egg= ert <lars@eggert.or= g>
>
> Hi,
>
> (chair hat off)
>
> the draft points to the CONEX work and says this:
>
>    This loss signaling is similar to loss signaling in [RFC7= 713], except
>    the Loss Event bit is reporting the exact number of lost = packets,
>    whereas the Echo Loss bit in [RFC7713] is reporting an ap= proximate
>    number of lost bytes.
>
> What it doesn't say is why the CONEX functionality is being proposed t= o be
> incorporated into QUIC, rather than staying at the IP level where it a= rguably
> belongs?

Thanks for the feedback. I agree that the draft could benefit from the expl= anation of why we use QUIC v1 reserved header bits instead of some bits in = a lower layer (or more bits outside of the header in the QUIC packet).

The short answer is deployability.  There is no point in writing draft= s that will sit on a shelf, because no one will want to deploy them for at = least a decade.  CONEX is one example, plagued by the difficulty of ge= tting IPv6 extension headers deployed.  And good luck with similar IPv4 extensions.

Hence we borrow CONEX ideas but try to implement them in a way that is stil= l possible, while using greasing and anti-ossification techniques.

> Thanks,
> Lars

Best,
- Igor

 

Folks might laugh, but I think realistically we'll= be looking towards UDP trailers at some point.

--_000_MWHPR15MB1935FC4A378BA641D87DAD39CD1B0MWHPR15MB1935namp_-- From nobody Wed Feb 12 00:33:09 2020 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 4D24D1200B1 for ; Wed, 12 Feb 2020 00:33:08 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 c8kJBNLuU6G8 for ; Wed, 12 Feb 2020 00:33:06 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20603.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::603]) (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 1C9BC12008A for ; Wed, 12 Feb 2020 00:33:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gEUbd2LIdTm+HoZ5Q5adpVh75YxOJReNRFQhkCb1w+dZQZZ/m2e5YRWtDKYuL957Do4rZK3z36+8xsUpM5BaeIiOcUlep2YK1/CiVSqkNO2p/d4z1WGoqhlb9KOh8xXzB5e/UTTEnwuNTDQo3U6cv/pbhnl2Lr0b5ubN8QCajKSWnzcKH5pgeBRLNOccN4un68UjMHmtWhAdUTZpWg+K8lAND9oiQE3B4vo0Ny3lZL7AbLCz4wd7mq3UBo3JuVH/+E3KEgFYqGaIJOlsJnVY9bzJSrnrGdN3nrrlKpatPwb8PXAc35urPpiTygUR9QWJxmwEvKJwlwgJ8fS69O4k4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7u7siI23ijOvbWApSCiiSqelm01uTihmHaHGSbe2yxE=; b=CPF3Ut9XDkxBVy4ZEbW0jenoF4nrkpbP3z7cDvssXr9y0bjIawwQDl13JtgvyfSf4Y1RPFCxm7mQpbH1OU2B/VjcFBxS97SrWTo7ggNcIVH+umRZGhJ+eZpXPcRsYZBeKSt9ZQQBk2tvDr5qfd55OTTgVBAjP8dKABXBxbqvDhE1HwLo2yjNTOlUovaPO7wx6TYgR1I9VpbK8kMdp5yjc4f1Kp3ocgUPLyczwcBlQIx05GeYMA3V/ZrEXwDqbqbqP9OnzaKySRpdBTEj/r2Nu46Lpyocst51hBaTSdBJjdMPr8SVWZ9VlHImp99CnF+2q4XeCh7tSC7J9umEbm3PRg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7u7siI23ijOvbWApSCiiSqelm01uTihmHaHGSbe2yxE=; b=PWqa/ucrCtnbbc0orBD/txJPYEyojt9oBNk7A8y5ycbd3aJu+lijsa7/9RZRAMEw9iw3vHXj/lApZlC5Y9lMy9vLGsEa5llfebDBvkNepSq66+lq6UzG58asx3lf9WofZChlW2oXZ/mxPpfuVur3Av3tKEkrVTbM10p6Fez9OJM= Received: from DB7PR07MB4572.eurprd07.prod.outlook.com (52.135.133.12) by DB7PR07MB4092.eurprd07.prod.outlook.com (52.134.96.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.16; Wed, 12 Feb 2020 08:33:03 +0000 Received: from DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544]) by DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544%5]) with mapi id 15.20.2729.021; Wed, 12 Feb 2020 08:33:03 +0000 From: Magnus Westerlund To: "ek.ietf@gmail.com" , "ilubashe@akamai.com" CC: "isabelle.hamchaoui@orange.com" , "dtikhonov@litespeedtech.com" , "lars@eggert.org" , "alexandre.ferrieux@orange.com" , "quic@ietf.org" Subject: Re: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt Thread-Topic: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt Thread-Index: AQHVzLqrJ8K1dwlaC0usEEtR2wTsCqft3wQQgCfz1wCAAIk4AIAAQ1eAgADFNAA= Date: Wed, 12 Feb 2020 08:33:03 +0000 Message-ID: References: <157921301012.26216.13677469865378306147.idtracker@ietfa.amsl.com> <180dde305bf149efb19a88e61967a87a@ustx2ex-dag1mb5.msg.corp.akamai.com> <851a81d65a9a4318914b9b18fd0b0605@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.130.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4d69447c-4bbe-4519-b42e-08d7af962d75 x-ms-traffictypediagnostic: DB7PR07MB4092: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(39860400002)(136003)(376002)(396003)(189003)(199004)(6506007)(2616005)(36756003)(66446008)(26005)(6512007)(8936002)(64756008)(110136005)(66946007)(66556008)(66616009)(66476007)(91956017)(76116006)(316002)(4326008)(54906003)(4744005)(81166006)(5660300002)(8676002)(44832011)(81156014)(186003)(86362001)(71200400001)(966005)(6486002)(478600001)(2906002)(278084002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4092; H:DB7PR07MB4572.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3spnYBrahWJNnFS99f3RtgCYoV+bZkBXrxw3BWXIoKpr0lkuTC1h5Y1wJYN9m/rLQTNVotfeyNyyTkgNVd/fZcLEm+hGjhpVQsr/fhDtz9/gtpL9sPXA+lgvHwpilP2HUHyn2AD5Z8aENBy34R8I/Zp0a/Nc5FPiJiTiulJYLtNZSpeP0Ck0bbcfhS0izivjrKKetqJkRS0yeSTxTl/ALwfEyMyxn1ViGDl9XyqyJ0byj0THEVlFQCh7krw0jTIFptbjiLo09zDedf0qQnqXvlUjX9O+oB4S+ZTiRElCkLWrER0N4uNqXl+pLP6zwaPcGr4kNdVE98R8qhaUgnlwNK1QZDnmVJdfD3yc0Ya+Cl3zfxSNvuu5VOjgzUNM+WoS3JWJ3Denq7RBCVp3IdLQgud+PYt9u4n4mmJyHZdmlVBNW3fpG6Tr1mtJSElB4uVrIjz3u4Y9Q2qbyGxYQiBQz6HpN9i3khjdtoSk32lzn0uRS2nWund3ZO92L+mnv4mlR0Jz8NJbjhxz7qXHY0MxIm9cU9fQ/domMjGmN8rfbBS3IBqNzEtTrrviQlBeRUUl x-ms-exchange-antispam-messagedata: 682YcYPusFOAJAwIWHAywMN8/MIIWK7VDOzBg1JXmzy4l45SvyxwnMTBf47o8w/fm7oL723h6Op3dEzsbhqAVKzB/BvkSTc9XkzyV2kD/hoo+546Shd7K4sg8KuZ5M71ECHRucQJziY07Z4G0LbrMw== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-V1hxly5db9zeuU5oaiD/" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d69447c-4bbe-4519-b42e-08d7af962d75 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2020 08:33:03.7479 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WrBqFVxe6t/UqjBXeJrddgiZMGpKDyQcuACQLVjS7kCJDEu1EzRVq+5+4B+5EOz53h4p/ilUWQ44rUi9h6PhoAF56ByMt3KYfoXM44SRPCU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4092 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 08:33:08 -0000 --=-V1hxly5db9zeuU5oaiD/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2020-02-11 at 12:47 -0800, Erik Kline wrote: >=20 > Folks might laugh, but I think realistically we'll be looking towards UDP > trailers at some point. This is not a joke, it is actual ongoing work in the IETF. Please see UDP o= ptions: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ =20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-V1hxly5db9zeuU5oaiD/ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIxMjA4MzMwMlowLwYJKoZIhvcN AQkEMSIEIHbpwcjfIHhsubKcNbreoeO576S8Ej3I2JpzYfmxHORbMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAOPCxMyyPkJrY dextRt0L+c/Wdau7yD8LDVngDWvsMPLshvtQKsV9WOWwQjc3jyD7cJ3BzBLS3lKXbfCi2T/zqHb7 bpsNdc9bdUCqKvMhiuOnKKvh3xr5OUqeuWohxxsxqhp96iDg6VQ1V9IRxUkygja/AbuEecuW61bn 34hMZWM9o9yeZjqtr2vUtiMjJh3eM+Ok8qaQZG+3OfkDyDk/csKbQvEwVoNb6/yIdKJI1xAHl2sh j/GTXSwvwWMoTh2+peLB1dKr+I8SHLahk6CrAUeCrFSLdLMouv16wo1RQvfuR6hQVi4itEqNQCRT iGcUQgx95zMRd050D14UNJaeeAAAAAAAAA== --=-V1hxly5db9zeuU5oaiD/-- From nobody Wed Feb 12 02:03:21 2020 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 1D8EE1200B1; Wed, 12 Feb 2020 02:03:16 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 5qisNgvkW2Or; Wed, 12 Feb 2020 02:03:13 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2061d.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::61d]) (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 CD750120077; Wed, 12 Feb 2020 02:03:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WXd3ukJHlA3jvHX4E5zYdNwjiIR1Y+6pbCW1X1ErOd0by/mciw7tArTixwNKKsTWDyW3BDMI6LWEzu92LEs0fn7IxYqnGBNdN9vAqu4qEYptHF7VvhbC1GLW51xqmlBuGNwFy/ZnyrfHaHp2j676c2pZR63tHrIXLMyescaplTVu2ixtvWXZ766Af5LXT+Q6sm0L2dpj6NPb1B0kpYENhHQlR9dMd2KuJS62b7XlV1ui5tsEK2dxKQlA21dxTVisyKxCKnRUct5j602CQ8co3qre9kGTOW3kKMyXYZIa3G0ExZvMsTXkN4ngJUtwguN16fs8sHJbIaym7iWshPdoDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ySgUpD9jYluWlYFI2HF3k1sWXu8C59GmrLzIoKW1ypE=; b=HEz7r02FF2ia04mtYPcMdtUfezA2vbHrd3fRZ4KTm05fqcP6u1wheILU+TmU2XA6H3121DG36cusNv6jCqXhfn5qhDmahbsKgQYFypfyn+48tJpgJxrtws4WbM38Zl6QMDp4cB8osw3HsDPBlMV+AvGiFjYpxAAF4OmIWn5VX3hGXccwkOLPR+FP0yN2ZIkILeJvh/PA7LcVevQSwQ87A0d74SH6QFA1GFPGhI6a/TKi7kgQ7OsrDXKF8mnnGmv69sSUf/GWPkNDiiMZL7r+YK3Mwqwco37QaChtO5ro8hBovD+m8ii9SNQRVpnQutGISZIJJzVjuAEbsLKVuyXhfQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ySgUpD9jYluWlYFI2HF3k1sWXu8C59GmrLzIoKW1ypE=; b=Qkiw6uhkRg4vwzSDUPwbojFadOUdhH9NUDVrKU8b3wX2lGox7GwfkmKFtslA1NeE71/CrMTbQIP/u4ZrY1DxTeD1q0wb0/+p1qSYzgXHSgLUsImoNsR7EIfix1gtj9lNbydusM6IclTKgip61NwagP6mJj9kAUDcIwm/R49628w= Received: from DB7PR07MB4572.eurprd07.prod.outlook.com (52.135.133.12) by DB7PR07MB5321.eurprd07.prod.outlook.com (20.178.42.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.18; Wed, 12 Feb 2020 10:03:09 +0000 Received: from DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544]) by DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544%5]) with mapi id 15.20.2729.021; Wed, 12 Feb 2020 10:03:09 +0000 From: Magnus Westerlund To: "iesg@ietf.org" , "spencerdawkins.ietf@gmail.com" CC: "quic-chairs@ietf.org" , "quic@ietf.org" Subject: Re: Fwd: WG Review: QUIC (quic) Thread-Topic: Fwd: WG Review: QUIC (quic) Thread-Index: AQHV3dpaGsZ7AO0AmE2pgZoD7jgQH6gU+FMAgABb7ACAAgdLgA== Date: Wed, 12 Feb 2020 10:03:09 +0000 Message-ID: <6e688025eb0a43f0ddde5ac20c10f5b8330821ac.camel@ericsson.com> References: <158109575881.11589.7522751407809468206.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.130.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2a28a1df-ed0c-4a2e-2bed-08d7afa2c379 x-ms-traffictypediagnostic: DB7PR07MB5321: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(376002)(136003)(366004)(189003)(199004)(81166006)(86362001)(8676002)(186003)(81156014)(478600001)(66574012)(966005)(71200400001)(6486002)(6506007)(6512007)(26005)(2906002)(76116006)(66946007)(54906003)(5660300002)(316002)(110136005)(66616009)(66446008)(66556008)(66476007)(64756008)(91956017)(8936002)(2616005)(4326008)(44832011)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5321; H:DB7PR07MB4572.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2tMPqAUkwXCUtW/K9Hp9J/GJkNhfiYI2sx1qEMs4jO5acHySbOXESXtORf3diZXWY90PpKKHiQDsAImUUVrwFNv2nrX1QrYuj3YgFlD6M/FBBrRgvdoO592lHpVIqGNIHcYlThes4Ah8JOeEFa5tLoI69bhaxA81jV9gSKqP4SptAzpdRMX9HBOZpsW3YYdLwA/uD/06rGr3GCQgr3zApVSWKfnxhL4wgmWGSMtH6FtKxss+hvUCk4rrtQ/6G0Kxe+By15uUFoAydoWZxraB/JnW8Ej7GYI1vQvX1/BuR4mJmA3uZdZHRluQXkKrKvUJf3tA2tdbtFao1Yp0spVxRhRWBz8TxWxNA+7vxAuH5PVwBaQVs0IqfNJu0TqBHmYowHJQLcv7ohiDbg3zUea3IvgqL9xt3Kjc0udvAOHa9QdH4HRoKzXTmiGcLLmjBe1qMU67Jj9g+CCKF0irmvbvO2s8Qjcub8xdA1OjgGUhZBz/Dg/gPBf+n3MEtSUUNty9tJuFmOnIIkKunmKQBe4d+A== x-ms-exchange-antispam-messagedata: 2KQi3IxVHZnPkqbh37HU8eBp2iZHQFweU+FWOoJTTjNJ4pN3+/bMVTp4si6sPP37FonDTSWfFO2FPsXYxyFkLu6HOfqwixs4Sc5CHnULK36EDil4PBxkMGhcKAN+oNqJd2isUpSPuxLmJzqKWSBofQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-A4Q+/h2RvdV9YMnol+Sv" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a28a1df-ed0c-4a2e-2bed-08d7afa2c379 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2020 10:03:09.4705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6dBpJVVTJbssJX79ZKqx7yPtYGkwEpAVn32/R5t/R13oNW8vFH4Yle32f6NdawJ6p9PZqGorbkqPZi7BvC8ZmMmU4+BCqohNjdwpwYwyNzU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5321 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 10:03:16 -0000 --=-A4Q+/h2RvdV9YMnol+Sv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Spencer, Thanks for the comments. Please see inline.=20 QUIC (quic) > > ----------------------------------------------------------------------- > > Current status: Active WG > >=20 > > Chairs: > > Mark Nottingham > > Lars Eggert > > Lucas Pardue > >=20 > > Assigned Area Director: > > Magnus Westerlund > >=20 > > Transport Area Directors: > > Mirja K=C3=BChlewind > > Magnus Westerlund > >=20 > > Mailing list: > > Address: quic@ietf.org > > To subscribe: https://www.ietf.org/mailman/listinfo/quic > > Archive: https://mailarchive.ietf.org/arch/browse/quic/ > >=20 > > Group page: https://datatracker.ietf.org/group/quic/ > >=20 > > Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/ > >=20 > > The QUIC working group will provide standards-track specifications for = a > > UDP-based, stream-multiplexing, encrypted transport protocol, based on > > pre-standardization implementation and deployment experience. > >=20 > > Key goals for QUIC are: >=20 > I'm wondering when these change from goals to attributes, but maybe the n= ext > major revision is the right time ... Yes, I think the next version is the time to rework the whole charter.=20 > =20 > > - Minimizing connection establishment and overall transport latency fo= r > > applications, starting with HTTP; > >=20 > > - Providing multiplexing without head-of-line blocking; > >=20 > > - Requiring only changes to path endpoints to enable deployment; > >=20 > > - Enabling multipath and forward error correction extensions; and > >=20 > > - Providing always-secure transport, using TLS 1.3 by default. > >=20 > > The work of the group will have five main focus areas, corresponding to= five > > core deliverables. > >=20 > > The first of these is the core transport work, which will describe the = wire >=20 > I wonder when the charter moves from future tense (which was accurate in = 2016) > to present tense, but perhaps after version 1 is complete would be a good > time.=20 As the first version work still is ongoing I think the natural phase to cha= nge the tempus will be in the next recharter when we actually have a first vers= ion of the protocol.=20 > =20 > > format, along with the mechanisms for connection establishment, stream > > multiplexing, data reliability, loss detection and recovery, congestion > > control, and options negotiation. Work on congestion control will descr= ibe > > use of a standardized congestion controller as a default scheme for QUI= C. > > Defining new congestion control schemes is explicitly out of scope for = this > > group. QUIC is expected to support rapid, distributed development and > > testing > > of features. > >=20 > > The second of these focus areas is security. This work will describe ho= w the > > protocol uses TLS 1.3 for key negotiation and will also describe how th= ose > > keys are used to provide confidentiality and integrity protection of bo= th > > application data and QUIC headers. This work will ensure that QUIC has > > security and privacy properties that are at least as good as a stack > > composed > > of TLS 1.3 using TCP (or MPTCP when using multipath). > >=20 > > The third focus area describes the mapping between the HTTP application > > protocol and the transport facilities of QUIC. This mapping will have > > performance characteristics comparable with HTTP/2, and provide extensi= on > > mechanisms similar to HTTP/2. Upon completion of this mapping, work to > > define > > additional mappings may be included by updates to this charter, or may = be > > worked on by other working groups. >=20 > When QUIC was chartered, my hope (and I don't think I was the only one) w= as > that we would end up with HTTP/2 over QUIC. For good reasons, we ended up= with > HTTP/3 over QUIC, and it seems odd that there's no mention of HTTP/3 in t= he > 2020 QUIC charter, but it IS mentioned in=20 > https://datatracker.ietf.org/doc/charter-ietf-httpbis/.=20 As you might have noticed there have been some changes to not be specific s= aying HTTP/2 which is no longer correct with the choice to go on to define HTTP/3= . The easier fix rather than trying to define what HTTP/3 is in detail, instead w= e have chosen to describe it simply as a mapping of the HTTP semantics onto t= he QUIC protocol. This makes the ongoing work to be in charter.=20 So are you primarily concerned that we are not explicitly saying that the H= TTP sematinc mapping on QUIC is called HTTP/3? Or is it that we don't define wh= at HTTP/3 is from a work scope perspective more detailed?=20 > =20 > > The fourth focus area will be on extensions to core protocol facilities= , to > > enable datagram delivery, version negotiation, and multipath capabiliti= es. > > Other extensions are out of the scope of this charter. > >=20 > > The fifth focus area will provide an Applicability and Manageability > > Statement, describing how, and under what circumstances, QUIC may be sa= fely > > used, and describing deployment and manageability implications of the > > protocol. Additionally, the Working Group will provide guidance on how = to > > handle QUIC traffic in load balancers. > >=20 > > Current practices for network management of transport protocols include= the > > ability to apply access control lists (ACLs), hashing of flows for equa= l- > > cost > > multipath routing (ECMP), directional signaling of flows, signaling of = flow > > setup and teardown, and the ability to export information about flows f= or > > accounting purposes. The QUIC protocol need not be defined to enable ea= ch of > > these abilities, or enable them in the same way as they are enabled by = TCP > > when used with TLS 1.3, but the working group must consider the impact = of > > the > > protocol on network management practices, reflecting the tensions descr= ibed > > in RFC 7258. > >=20 > > Note that consensus is required both for changes to the current protoco= l > > 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 > This paragraph ^ was inserted to say "the way Google QUIC happens to work= in > 2016" (which was the only QUIC we had) "isn't binding on the working grou= p > producing IETF QUIC". That was worth saying in 2016 - and we might have s= aid > it more clearly - but in 2020, the obvious meaning of "current protocol > mechanisms" is IETF QUICv1. I don't think this paragraph means anything > helpful now, and anyone who tries to be guided by it, is probably headed = into > the weeds. I'd delete it.=20 Yes, I agree that it is reasonable to remove it without any impact to the W= G way of working.=20 > =20 > > The QUIC working group will work closely with the HTTPbis working group= , > > especially on the QUIC mapping for HTTP. > >=20 > > Milestones: > >=20 > > Jul 2020 - Core Protocol document to IESG > >=20 > > Jul 2020 - Loss detection and Congestion Control document to IESG > >=20 > > Jul 2020 - TLS 1.3 Mapping document to IESG > >=20 > > Jul 2020 - HTTP/2 mapping document to IESG > >=20 > > Jul 2020 - QUIC Applicability and Manageability Statement to IESG >=20 > Just making sure I understand - the load balancing advice would be includ= ed in > this statement, is that right?=20 Yes, or we add an additional milestone if this is a seperate document. It i= s not 100% clear, and I am happy to leave this to the WG.=20 >=20 > > Jul 2020 - Version-Independent Properties of QUIC to IESG > >=20 > > Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG > >=20 > > Dec 2020 - Working group adoption of Multipath extension document > >=20 > > Mar 2021 - Datagram Extension to IESG > >=20 > > Mar 2021 - Version Negotiation Extension to IESG > >=20 > > Dec 2021 - Multipath extension document to IESG > >=20 > >=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-A4Q+/h2RvdV9YMnol+Sv Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIxMjEwMDMwOFowLwYJKoZIhvcN AQkEMSIEILRk7UsVNKn+rfdaSy+N7mbwoBKm3Nui6q2yNPn3n7q7MGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEARs1m33RMVImH MrWBnnHcbWJwL2Grv6z/JE93aRdGb1wcG/+XzOZMpTIlEi3TzTRvZE4i7Jp2NN7ZVXL6miMGFbGz LOlJU8lOAVWoBFSso0sjmoLO9AgAFgRYijFx1B16AWk/0prbnCy4tUJ3xXp2G4N11Ap/NofSxfCM qJyRvNBoLASNI19fjY3gRXv78vaPiNLAcOlUST9FqVV7NwUIAFHihdVL4g1jvI1fTivtrjbQ5L82 qJnfbHu5TdJsDlPlkxKRSOUCfNdhuwuEn7pa/5yn2vqDiovfSIoCmxPTft/2EIYa1lgyYcI3KAj+ rGRS42ik/ozD4RAIJ0S+ItJFjwAAAAAAAA== --=-A4Q+/h2RvdV9YMnol+Sv-- From nobody Wed Feb 12 05:01:32 2020 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 B5D441200D8 for ; Wed, 12 Feb 2020 05:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 Ney0wuHKsTcv for ; Wed, 12 Feb 2020 05:01:29 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 0B2F91200D5 for ; Wed, 12 Feb 2020 05:01:29 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id y11so2236730wrt.6 for ; Wed, 12 Feb 2020 05:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=DKxLwEEwmG1ZWIyzg+e0b9TqXNnQtX6QWQZ1jgu+Ldk=; b=pAfnEbdIxvvmsvSnRWjTOYYfIZRp2acPECuM7+L9NV80teUKbuQ7DGXcMvZnsjj5el 4jK5z2L4P84lWAdPyKL7xCEkc84bCBc7Y6WVYa8NyRui1KZXtNeRFNns10OKlzOkGdEI dDjDu23LO0f3QDMz3ojbDuUuu/QdVdro5/yNRxTYRw5j2W1LrbWQ8kbBHG/WWZ/bCQzH SY4LaA3+hWMNnqWgUgmDpn+KMIRCxZMpZlQs9RwaDwmQnLm/o22QD4czfOuwMEXHSBZ3 /EkDoj/wen9SB3OpjyQSPAOwJZfhgfsaXsH9eZeBlyF7/uC8ieWCNPYyd0oUtydH60xs QC6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=DKxLwEEwmG1ZWIyzg+e0b9TqXNnQtX6QWQZ1jgu+Ldk=; b=XkWmogABYcup4R4f4MDC95zPUyCM/DKOqdXxruvoIcwSYjSUzFlYrC/IV/6+5ZSoTf 3rzKiB5pBP+r5W2Umw1rd5TESaoKIY5zpeis+Z1Mv5gZYfo3NMjhRlS/PSwhRID6UQm/ BtswebUjcz4wmwFrMnktpNqATp2Pua7WSrnkFgVQINtp1XiZ9AKES3JoGMNYiEK415tZ IqGvEqQntfOaOAB0qMWPvp1gLXjZPblpmnyzskkqju1glvkNkQoRyZsDJb167sOksRpO 0WUNY0mgEn+rYuHoq1KxlKEOJDZfXHZ6gi3+GYkMyHpsgv4/oexKrTd8UNMbqLF8o1ZU xVyg== X-Gm-Message-State: APjAAAX07jlDUT1M4Su5VdeGPwMnotxiwQmg5/a01+uFx7WfMz8UTGVy o5mCDQTmFzEx26Ce3fK76fWw3SnQ5hbLiguS1GF3EhnC X-Google-Smtp-Source: APXvYqw8jMJniAw9OmEKUZ1Mgnn5fH19dMNQ+gKmK8/HAsPe2gB7bRG7A16CyvZl91BFWmrJzRMqNLJlf/Y52f0817k= X-Received: by 2002:a5d:6b82:: with SMTP id n2mr16334743wrx.153.1581512487138; Wed, 12 Feb 2020 05:01:27 -0800 (PST) MIME-Version: 1.0 From: Lucas Pardue Date: Wed, 12 Feb 2020 13:01:15 +0000 Message-ID: Subject: Consensus call, Transport Parameter change To: QUIC WG Cc: Lars Eggert , Mark Nottingham Content-Type: multipart/alternative; boundary="00000000000000fbf5059e60926c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 13:01:31 -0000 --00000000000000fbf5059e60926c Content-Type: text/plain; charset="UTF-8" In the Zurich interim we discussed an issue related to changing Transport Parameters to use variable-length integer encoding. The issue and its proposal are shown below. Discussion at the interim seemed to support consensus for accepting the proposal. The proposal makes a wire format change that will affect interoperability among many implementations. In order to accelerate landing this change, we're running a shorter 1-week consensus call for the single issue. If you object to the proposal, please comment on the issue or in response to this message. Absent any pushback, we'll direct the editors to incorporate the change in one week's time. See for the current state of issues in the Late Stage process, itself defined at < https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md>. * #3294: Make transport parameter ID and length varint The proposal is Cheers, Lars, Lucas & Mark QUIC WG Chairs --00000000000000fbf5059e60926c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the Zurich interim we discussed an issue related to cha= nging Transport Parameters to use variable-length integer encoding. The iss= ue and its proposal are shown below. Discussion at the interim seemed to su= pport consensus for accepting the proposal.

The proposal makes a wir= e format change that will affect interoperability among many implementation= s. In order to accelerate landing this change, we're running a shorter = 1-week consensus call for the single issue. If you object to the proposal, = please comment on the issue or in response to this message. Absent any push= back, we'll direct the editors to incorporate the change in one week= 9;s time.

See <https://github.com/quicwg/base-drafts/projects/5> for the= current state of issues in the Late Stage process, itself defined at <<= a href=3D"https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md= ">https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md>= .

* #3294: Make transport parameter ID and length varint
=C2=A0 T= he proposal is <https://github.com/quicwg/base-drafts/pull/3169>

Cheers,<= br>Lars, Lucas & Mark
QUIC WG Chairs
--00000000000000fbf5059e60926c-- From nobody Wed Feb 12 17:57:14 2020 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 DE0B812006F; Wed, 12 Feb 2020 17:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 nT8lUauQhnt4; Wed, 12 Feb 2020 17:57:10 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 47AF312006D; Wed, 12 Feb 2020 17:57:10 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id y19so3020565lfl.9; Wed, 12 Feb 2020 17:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uSvGjAA2OOgFiN1gl/62u6cEwCF9KZXdJ5YxxNrtkOQ=; b=WHCxB53841gqiAseO/osGECqyL7k2TefUeMbHixmDq8suU/xOBb6tvgB9d1+CWjEVM RGDNBj7vyqG8wqyQIOXX8hD6rYiVcAefuKOD36uso2yZH1otqTlkutGH39RB5iC6wuXI IGLmVVklLx5WVQBh+XMq2bZaTXP5DXHPzbfz5HwxcV0htmcn5+JCnTTOmGLsyHcTpI4i e5M8xm0zrtEg8F0OwwmJUSnoJFB0oVm+2+d/bAKKpID/6wQOojNrxcnRv0GNY4pILbDH cA09o6YT4toQHt0MPp+VCXjoRHWpwFYvlo61S5FEattUJlUAW5RAmwbdcH5Bm/SOBfGE D7DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uSvGjAA2OOgFiN1gl/62u6cEwCF9KZXdJ5YxxNrtkOQ=; b=Hm8bQlR2R3ypm44YHnNDMcEt0mAVkNhcKkLd+3Dl1lcwF6uxilXW+X9d0ZmSjEeRgr 9jFw2t+CJ/OkvRqx3poNjlY4hhuTMqy1mx/LiRboMsRUl0b3tJ0/O5G1Oj4kqXi6GgmP b6l0jKIN5OC019rzbBGOXIauwndRp/I6ztYSDeD1QPzptmVnPs27yjLY4SvM1tTopEgJ 9hnIGQR068rFS7OKncErBaP1BkYqOhHkoZIz0fLI/dHWsKnGubr77cYipo7j6f+5vhsE 5uJc+Bc9YMs08AWHbI5u0khe3yQ7+ibmWdF9AGN1Sq3evF2sYcJCDwRVDSaycomSjUaX z2fw== X-Gm-Message-State: APjAAAXsUCrKRHLDSFWE8cbffzQVOcToDbjxi8MTuOUFlVBM4s8nueIT AshuVialJNKFusmj37lOfNId7CeDtEbVWPr1vjENx19m X-Google-Smtp-Source: APXvYqyiTmncbtGU6QBUnTyo0OWFz324wFR8VUbjcZ2nI2n7nAYF5pTZKhWz1spqUqDQS+kJW5nH7z/dzGkFj2NhYZw= X-Received: by 2002:a19:ca59:: with SMTP id h25mr8069443lfj.27.1581559028575; Wed, 12 Feb 2020 17:57:08 -0800 (PST) MIME-Version: 1.0 References: <158109575881.11589.7522751407809468206.idtracker@ietfa.amsl.com> <6e688025eb0a43f0ddde5ac20c10f5b8330821ac.camel@ericsson.com> In-Reply-To: <6e688025eb0a43f0ddde5ac20c10f5b8330821ac.camel@ericsson.com> From: Spencer Dawkins at IETF Date: Wed, 12 Feb 2020 19:56:42 -0600 Message-ID: Subject: Re: Fwd: WG Review: QUIC (quic) To: Magnus Westerlund Cc: "iesg@ietf.org" , "quic-chairs@ietf.org" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="00000000000016f0aa059e6b686c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 01:57:13 -0000 --00000000000016f0aa059e6b686c Content-Type: text/plain; charset="UTF-8" Hi, Magnus, Thanks for the clues. Inline (and deleting stuff that makes sense to me now). On Wed, Feb 12, 2020 at 4:03 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi Spencer, > > > Thanks for the comments. Please see inline. > > > The third focus area describes the mapping between the HTTP application > > > protocol and the transport facilities of QUIC. This mapping will have > > > performance characteristics comparable with HTTP/2, and provide > extension > > > mechanisms similar to HTTP/2. Upon completion of this mapping, work to > > > define > > > additional mappings may be included by updates to this charter, or may > be > > > worked on by other working groups. > > > > When QUIC was chartered, my hope (and I don't think I was the only one) > was > > that we would end up with HTTP/2 over QUIC. For good reasons, we ended > up with > > HTTP/3 over QUIC, and it seems odd that there's no mention of HTTP/3 in > the > > 2020 QUIC charter, but it IS mentioned in > > https://datatracker.ietf.org/doc/charter-ietf-httpbis/. > > As you might have noticed there have been some changes to not be specific > saying > HTTP/2 which is no longer correct with the choice to go on to define > HTTP/3. The > easier fix rather than trying to define what HTTP/3 is in detail, instead > we > have chosen to describe it simply as a mapping of the HTTP semantics onto > the > QUIC protocol. This makes the ongoing work to be in charter. > > So are you primarily concerned that we are not explicitly saying that the > HTTP > sematinc mapping on QUIC is called HTTP/3? Or is it that we don't define > what > HTTP/3 is from a work scope perspective more detailed? > I'm primarily concerned that it's unnecessarily obscure, who's working on HTTP/3. You might think that you'd know that from looking at the QUIC charter :-) But let me try this thinking on - it's only unnecessarily obscure for as long as QUIC is operating on this charter. So, if (making this up) the next charter happens in six months, well, that's not so bad ... and with the next charter, HTTP/3 moves off to HTTPbis anyway. Does that sound about right to you? Best, Spencer --00000000000016f0aa059e6b686c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Magnus,=C2=A0

Than= ks for the clues. Inline (and deleting stuff that makes sense to me now).

On Wed, Feb 12, 2020 at 4:03 AM Magnus Westerlund <magnus.westerlund@ericsson.com> wro= te:
Hi Spencer,<= br>

Thanks for the comments. Please see inline.
> > The third focus area describes the mapping between the HTTP appli= cation
> > protocol and the transport facilities of QUIC. This mapping will = have
> > performance characteristics comparable with HTTP/2, and provide e= xtension
> > mechanisms similar to HTTP/2. Upon completion of this mapping, wo= rk to
> > define
> > additional mappings may be included by updates to this charter, o= r may be
> > worked on by other working groups.
>
> When QUIC was chartered, my hope (and I don't think I was the only= one) was
> that we would end up with HTTP/2 over QUIC. For good reasons, we ended= up with
> HTTP/3 over QUIC, and it seems odd that there's no mention of HTTP= /3 in the
> 2020 QUIC charter, but it IS mentioned in
> https://datatracker.ietf.org/doc/charter-= ietf-httpbis/.

As you might have noticed there have been some changes to not be specific s= aying
HTTP/2 which is no longer correct with the choice to go on to define HTTP/3= . The
easier fix rather than trying to define what HTTP/3 is in detail, instead w= e
have chosen to describe it simply as a mapping of the HTTP semantics onto t= he
QUIC protocol. This makes the ongoing work to be in charter.

So are you primarily concerned that we are not explicitly saying that the H= TTP
sematinc mapping on QUIC is called HTTP/3? Or is it that we don't defin= e what
HTTP/3 is from a work scope perspective more detailed?

I'm primarily concerned that it's unnecessarily ob= scure, who's working on HTTP/3. You might think that you'd know tha= t from looking at the QUIC charter :-)

But let me = try this thinking on - it's only unnecessarily obscure for as long as Q= UIC is operating on this charter. So, if (making this up) the next charter = happens in six months, well, that's not so bad ... and with the next ch= arter, HTTP/3 moves off to HTTPbis anyway.

Does th= at sound about right to you?

Best,

<= /div>
Spencer
--00000000000016f0aa059e6b686c-- From nobody Wed Feb 12 22:59:20 2020 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 A81071200B2 for ; Wed, 12 Feb 2020 22:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 8sfWTZDGOS79 for ; Wed, 12 Feb 2020 22:59:15 -0800 (PST) Received: from vs25.mail.saunalahti.fi (vs25.mail.saunalahti.fi [62.142.117.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EDE312007A for ; Wed, 12 Feb 2020 22:59:15 -0800 (PST) Received: from vs25.mail.saunalahti.fi (localhost [127.0.0.1]) by vs25.mail.saunalahti.fi (Postfix) with ESMTP id 439B620C67 for ; Thu, 13 Feb 2020 08:59:13 +0200 (EET) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs25.mail.saunalahti.fi (Postfix) with ESMTP id 3906D2013A for ; Thu, 13 Feb 2020 08:59:13 +0200 (EET) Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw01.mail.saunalahti.fi (Postfix) with ESMTPSA id 34F1C40003 for ; Thu, 13 Feb 2020 08:59:12 +0200 (EET) Received: from stickers.eggert.org (Stickers.eggert.org [172.24.110.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id D0AB7615B51 for ; Thu, 13 Feb 2020 08:59:05 +0200 (EET) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_4DB8E8AF-981F-4024-9B69-E762760ED8FA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Fwd: [tsvwg] Publication has been requested for draft-ietf-tsvwg-datagram-plpmtud-14 Message-Id: <2FCFF407-D6F1-4824-B2AE-0E24A25FBCFC@eggert.org> References: <158152900123.17918.2300667862394511096.idtracker@ietfa.amsl.com> To: IETF QUIC WG Date: Thu, 13 Feb 2020 08:59:05 +0200 X-MailScanner-ID: D0AB7615B51.A38AE X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 06:59:18 -0000 --Apple-Mail=_4DB8E8AF-981F-4024-9B69-E762760ED8FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Begin forwarded message: > Wesley Eddy has requested publication of = draft-ietf-tsvwg-datagram-plpmtud-14 as Proposed Standard on behalf of = the TSVWG working group. >=20 > Please verify the document's state at = https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ since QUIC is intended to implement this procedure, if you haven't = reviewed it already, the upcoming IETF Last Call is your last chance to = do so. Thanks, Lars --Apple-Mail=_4DB8E8AF-981F-4024-9B69-E762760ED8FA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl5E87kACgkQVLXDCb9w wVc6GA//aWqIa2V568SiHtOygV6QBRFFMoRfiacpZolrufHu5U/FzEBBbzE56d+K aVAIvjojPLDY+2HxpDk2jwcH7pZIMDZ1h8WSRDbdgQ3tiRT8xWsE7fzeJzGetsk8 kXJgZEFHWCJyIHRr1yCc/H5mvATLhYJi5d8ejhkoedFNdLtZp4owNrG4Iz3Byfl/ lYwA63QYhZp1Jewc2L75ADCD9XkhhrIfpflNUONXngXKzENYgDqTyfKUE4RDcx3+ GgDSHJJD9ZaUGILjE65pwF4N4lfh6Kk6YUXzcn/gRG0DVmjPr2W2hYRfod1jZRSh KDqcaTsN3FC44UVOSw6lPjojc69yyg++uYsxHIBbpS8qXAIS3mPkpta05HrOdF6V WNsbXaICBQ9WNg2V9wXoyGGGsrWkQYoKfcSc43MJKslzgNiMiKNXUkEk2fdEUFl6 ANMrFJQQmYCM4hQvNWg5kGwax6TCibQC360+MJ+Jm2/g4BrdsTfE5fPQPPryiv8S fFHt76OOi0dLSyR0ivrz/n2YyAKlrOO5euGkE2mqDzg6KhCyEYixBHby/Pa8vq+e N+rJVaHrZY1548lb35KlQZ0h0yg6RmFDO1T87u8vyVjy42K6S0Xul5YzLHGmFq7f EVznJZ7NcyCrihSS5ssOAf+jerSxlnUFLFPFIT6YOdtk1ZpLS0c= =ubdS -----END PGP SIGNATURE----- --Apple-Mail=_4DB8E8AF-981F-4024-9B69-E762760ED8FA-- From nobody Thu Feb 13 07:44:43 2020 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 B072C120124 for ; Thu, 13 Feb 2020 07:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 3Q3l4eWFmmSL for ; Thu, 13 Feb 2020 07:44:39 -0800 (PST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 E8ACF1200C7 for ; Thu, 13 Feb 2020 07:44:38 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id d3so6003892otp.4 for ; Thu, 13 Feb 2020 07:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fpZouiDlMhmt1J26919/K4kx2SxzR0/QGdolFj0j8x8=; b=EGQDUEQ4Fp4CNcB3s7pBMNWpFjwMY+Y5w7LowyJugEHHtDbcfEt6W0/3BKFj92zMcp PLnaHEIaGhuYqVQOhtLiDg/BajvgZhTO579dTBlwsJH4V9/pRIKiQ/7MTCLIX437A8Bw yAETi/EjpKE3gVTxTcn0B/lKLcQCYnbZNAOApfW6b733yL8xnfyWv7C9q5uXFc80TtLu WowPFlHtyDIduJLPkWqJempfiYNROdPMyMhth6KkcsosZmaQk4QY6zGm+vOIPQ+bpnuV A5HKXpZEBh+0+nkx13SZw8CylVGoLay6XLuyuXG0m/bjILktUYqChC3ycgisbTOIMKiB E1PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fpZouiDlMhmt1J26919/K4kx2SxzR0/QGdolFj0j8x8=; b=Z8PE0EM0WTh/CAWCXb1IIJqjNHyCyWeb+Wiu7gj4P/yLkSseiqGhmJH1E4o2iLFCcF etyk7pYWdhvqkTNXVwCXSvTCYH97cVgIxqNaDXoSnpfW0wGxfnAQMCKA/1RDrmf1KuHR Rv8fm8NYKn+FqcVBti7oId3B5MuLXPNz6daSHcdxyc3j5swaslQG/vFSULll1JnWdxYz vH/3YvcD58h0xtlgoqwPZQWUX46FrLD1ZujiwwZek/j0yb0CVSzeOmePtlLHlwb/Eu4I xwL2ABizK9xAWzFVDm6aFuxu3imDg8ZFxhIxFuhCogiLzmc3fn5qjBX0tgyJ10lh51GQ cYjg== X-Gm-Message-State: APjAAAVDAblkLYuRo93RO6IaVuf1HtDN6B6+N7Sn/8CRfQi1mTtck/0g 8nKm4n30Ihf5ScFI+s+wNke67WF9HZUa7Qxi+BY= X-Google-Smtp-Source: APXvYqxwAtLk5BYDLAyCKoqjMLxmuiquB9qfUUrcmBJLAY9B1JBfPKkDYaNFNmmmwofjB5xpCdGoAaOCReJ+wjCSYQU= X-Received: by 2002:a05:6830:1218:: with SMTP id r24mr14273127otp.144.1581608678291; Thu, 13 Feb 2020 07:44:38 -0800 (PST) MIME-Version: 1.0 References: <157921301012.26216.13677469865378306147.idtracker@ietfa.amsl.com> <180dde305bf149efb19a88e61967a87a@ustx2ex-dag1mb5.msg.corp.akamai.com> <851a81d65a9a4318914b9b18fd0b0605@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: From: Erik Kline Date: Thu, 13 Feb 2020 07:44:26 -0800 Message-ID: Subject: Re: New Version Notification for draft-ferrieuxhamchaoui-quic-lossbits-03.txt To: Magnus Westerlund Cc: "ilubashe@akamai.com" , "isabelle.hamchaoui@orange.com" , "dtikhonov@litespeedtech.com" , "lars@eggert.org" , "alexandre.ferrieux@orange.com" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000717ad5059e76f722" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 15:44:41 -0000 --000000000000717ad5059e76f722 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 12, 2020 at 12:33 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On Tue, 2020-02-11 at 12:47 -0800, Erik Kline wrote: > > > > Folks might laugh, but I think realistically we'll be looking towards UDP > > trailers at some point. > > This is not a joke, it is actual ongoing work in the IETF. Please see UDP > options: > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ Aha, this is actually what I was looking for. I was only able to find Tom Herbert's draft when I searched. Thanks! --000000000000717ad5059e76f722 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 12, 2020 at 12:33 AM Magnus W= esterlund <magnus.west= erlund@ericsson.com> wrote:
On Tue, 2020-02-11 at 12:47 -= 0800, Erik Kline wrote:
>
> Folks might laugh, but I think realistically we'll be looking towa= rds UDP
> trailers at some point.

This is not a joke, it is actual ongoing work in the IETF. Please see UDP o= ptions:

https://datatracker.ietf.org/doc/draft= -ietf-tsvwg-udp-options/

Aha, this is a= ctually what I was looking for.=C2=A0 I was only able to find Tom Herbert&#= 39;s draft when I searched.

Thanks!
--000000000000717ad5059e76f722-- From nobody Sat Feb 15 23:32:42 2020 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 0A176120026 for ; Sat, 15 Feb 2020 23:32:37 -0800 (PST) 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 (2048-bit key) header.d=mnot.net header.b=PXuNhb5T; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nGg7nvOU 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 FpkdVal5zP7V for ; Sat, 15 Feb 2020 23:32:33 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B2D120013 for ; Sat, 15 Feb 2020 23:32:33 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 9224A606 for ; Sun, 16 Feb 2020 02:32:29 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 16 Feb 2020 02:32:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=zB5DNcPg95qu1VErcMxP+dZEOu3DPHJBJIb3CpNPUmM=; b=PXuNhb5T fxXWP9ouPfN+VSW2QcfeLeIPcF49id019ub7Etw+WKltlbj2E55Cx64xqOm5dt94 Hb0/1lMN2bvhvTqDAH7e2mz2mC8dpt5wYHTReXUc2+cEkhh6UWtjv7rd2CTG+JEC weaAezid6FhApqppjs/DkalBauDhdV8bR4L2jdXGF4VfDdc0HgjzvArZIUvl7JlP UP5Al5yEAMoI8luwMTcl6H0CWtZuloHnX2V+ICBbNPUVoeX8G4xjTHEb0pQmiOEE q2g4UyYCzoRONfc0Gr5wQvl7443oagCSbmwMKvFvl11U8SMT/g08ZodRmUYCHkE2 KwmQVmsQ/mzkXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=zB5DNcPg95qu1VErcMxP+dZEOu3DP HJBJIb3CpNPUmM=; b=nGg7nvOUmiAVlLiMjZN9Y9oAaInNN4xidQk6eh4IHVQ5u BZ7K0zqJbPVA5fjRdNm3NfhEqLy0SVNa0bwY2Gm71u9tdp/1Qm860x5jhaoj3rPZ FOA6U6H7MbGqekMCWQ9rbd0EJ670BKEY4mdddCN1DkqeV3qmPLwMQ6XGk7/A7IIh 3XwCUcij4/rbVfUz3Y4LhFa30ZZGSjUPtuK31EoRwDVJR+tZIbay6ONRK8XqsM4S WZ8jkQQNyG+Y8Rt0Ga08AfZIIOgoRpsfleZMrXW6wKJ/496CyAl2hhFFxGExMy0C VQV7PSA+JljFckb3baCLMeCW4vglwEFEAMzGCVO5w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrjeefgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphepudeikedriedurdegjedruddtjeenucevlhhushht vghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [168.61.47.107]) by mail.messagingengine.com (Postfix) with ESMTPA id C4103328005E for ; Sun, 16 Feb 2020 02:32:28 -0500 (EST) Content-Type: multipart/alternative; boundary="===============8965597977158094834==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: quic@ietf.org Subject: Weekly github digest (QUIC Activity Summary) Message-Id: <20200216073228.C4103328005E@mailuser.nyi.internal> Date: Sun, 16 Feb 2020 02:32:28 -0500 (EST) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2020 07:32:37 -0000 --===============8965597977158094834== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+4/-7/=F0=9F=92=AC29) 4 issues created: - Is ACK delay zero for Initial and Handshake ACK frames? (by larseggert) https://github.com/quicwg/base-drafts/issues/3459=20 - Clarify when it is ok to ignore packet loss (by ianswett) https://github.com/quicwg/base-drafts/issues/3456 [-recovery]=20 - Should we allow ACK-only packets to be declared lost? (by martinthomson) https://github.com/quicwg/base-drafts/issues/3451 [-recovery]=20 - max_packet_size in 0-RTT (by martinthomson) https://github.com/quicwg/base-drafts/issues/3447 [-transport]=20 10 issues received 29 new comments: - #3459 Is ACK delay zero for Initial and Handshake ACK frames? (1 by ian= swett) https://github.com/quicwg/base-drafts/issues/3459=20 - #3451 Should we allow ACK-only packets to be declared lost? (14 by huit= ema, ianswett, janaiyengar, kazuho, marten-seemann, martinthomson, mirjak) https://github.com/quicwg/base-drafts/issues/3451 [-recovery]=20 - #3447 max_packet_size in 0-RTT (2 by ianswett, martinduke) https://github.com/quicwg/base-drafts/issues/3447 [-transport]=20 - #3446 Allow application CONNECTION_CLOSE everywhere (3 by kazuho, marti= nthomson, nibanks) https://github.com/quicwg/base-drafts/issues/3446 [-tls] [-transport]=20 - #3435 Allow CONNECTION_CLOSE in 0-RTT (3 by huitema, kazuho, martinthom= son) https://github.com/quicwg/base-drafts/issues/3435 [-transport]=20 - #3434 Remembering transport parameters (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/3434 [-transport]=20 - #3348 Which DCID do Handshake retransmissions use? (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/3348 [-transport] [design]= [proposal-ready]=20 - #3294 Make transport parameter ID and length varint (2 by MikeBishop, m= artinthomson) https://github.com/quicwg/base-drafts/issues/3294 [-transport] [design]= [proposal-ready]=20 - #2125 Document what needs to be checked for address validation (1 by ma= rtinthomson) https://github.com/quicwg/base-drafts/issues/2125 [-transport] [design]= [has-consensus]=20 - #253 HTTP/QUIC without Alt-Svc? (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/253 [-http] [design]=20 7 issues closed: - Allow use of token after client address changes https://github.com/quic= wg/base-drafts/issues/3307 [-transport] [design] [has-consensus]=20 - Immediate close without state https://github.com/quicwg/base-drafts/iss= ues/3297 [-transport] [design] [has-consensus]=20 - CONNECTION_CLOSE for unpadded Initial https://github.com/quicwg/base-dr= afts/issues/3269 [-transport] [design] [has-consensus]=20 - Which DCID do Handshake retransmissions use? https://github.com/quicwg/= base-drafts/issues/3348 [-transport] [design]=20 - Clarify the definition of things that make messages malformed https://g= ithub.com/quicwg/base-drafts/issues/3345 [-http] [design] [has-consensus]=20 - Why are there two ways of associating push with requests? https://githu= b.com/quicwg/base-drafts/issues/3275 [-http] [design] [has-consensus]=20 - Recouple QUIC version and ALPN https://github.com/quicwg/base-drafts/is= sues/3117 [-http] [design] [has-consensus]=20 Pull requests ------------- * quicwg/base-drafts (+8/-5/=F0=9F=92=AC9) 8 pull requests submitted: - Make congestion control more self-contained (by ianswett) https://github.com/quicwg/base-drafts/pull/3463=20 - Fix the section reference (by ianswett) https://github.com/quicwg/base-drafts/pull/3460=20 - Revert "Remove "Ignoring Loss of Undecryptable Packets"" (by ianswett) https://github.com/quicwg/base-drafts/pull/3457=20 - Add handling of all packets marked as CE (by mirjak) https://github.com/quicwg/base-drafts/pull/3455=20 - In an unlikely event of emergency.... set ECN marks (by mirjak) https://github.com/quicwg/base-drafts/pull/3454=20 - ACK-only packets are not congestion controlled (by ianswett) https://github.com/quicwg/base-drafts/pull/3453=20 - Restore "Ignoring Loss of Undecryptable Packets" (by ianswett) https://github.com/quicwg/base-drafts/pull/3450 [-recovery]=20 - Revert "Remove "Ignoring Loss of Undecryptable Packets"" (by ianswett) https://github.com/quicwg/base-drafts/pull/3449=20 5 pull requests received 9 new comments: - #3453 ACK-only packets are not congestion controlled (1 by ianswett) https://github.com/quicwg/base-drafts/pull/3453=20 - #3449 Revert "Remove "Ignoring Loss of Undecryptable Packets"" (1 by ia= nswett) https://github.com/quicwg/base-drafts/pull/3449=20 - #3443 MAY send 1 packet entering recovery (5 by ianswett, martinduke) https://github.com/quicwg/base-drafts/pull/3443 [-recovery] [design]=20 - #3440 Allow CONNECTION_CLOSE in 0-RTT (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/3440 [-tls] [-transport] [de= sign]=20 - #3327 What needs to be checked for address validation (1 by martinthoms= on) https://github.com/quicwg/base-drafts/pull/3327 [-transport]=20 5 pull requests merged: - Allow use of token after client address change https://github.com/quicwg/base-drafts/pull/3308 [-transport] [design]=20 - Define stateless CONNECTION_CLOSE https://github.com/quicwg/base-drafts/pull/3292 [-transport] [design]=20 - Clarify and split the "malformed" definition https://github.com/quicwg/base-drafts/pull/3352 [-http] [design]=20 - Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE https://github.com/quicwg/base-drafts/pull/3309 [-http] [design]=20 - Require QUICv1 for HTTP/3 https://github.com/quicwg/base-drafts/pull/3323 [-http] [design]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============8965597977158094834== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Activity Summary)

Sunday February 16, 2020

Events without label "editorial"

Issues

quicwg/base-drafts (+4/-7/=F0=9F=92=AC29)

4 issues created:

10 issues received 29 new comments:

7 issues closed:

Pull requests

quicwg/base-drafts (+8/-5/=F0=9F=92=AC9)

8 pull requests submitted:

5 pull requests received 9 new comments:

5 pull requests merged:

Repositories tracked by this digest:

--===============8965597977158094834==-- From nobody Tue Feb 18 07:46:12 2020 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 ED90612083A for ; Tue, 18 Feb 2020 07:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=jdrosen.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 U2tRf_pNrTTH for ; Tue, 18 Feb 2020 07:46:09 -0800 (PST) Received: from se2c-iad1.servconfig.com (se2c-iad1.servconfig.com [209.182.212.109]) (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 57AE7120837 for ; Tue, 18 Feb 2020 07:46:06 -0800 (PST) Received: from ecbiz261.inmotionhosting.com ([173.231.209.30]) by se2-iad1.servconfig.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j454Q-000Bpz-5Q for QUIC@ietf.org; Tue, 18 Feb 2020 10:46:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jdrosen.net ; s=default; h=Content-Type:To:Subject:Message-ID:Date:From:MIME-Version: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=kfaxksWByRD+oqbm1N+oXNb+WOQByaMKMA3S+hv0Fsg=; b=lnSPzffROMlC45kFnrp7Pog0/j 1OTPrySz2QN2Lhr4/qdmIvXunCqyQWxgsYQFqHG31O9//fCFDaplgNBOirUjAejJr+05TtuAtfrKP +WPfolLcdqTabs9w5jY8a+bgMl5oTeVOemAMvHPw+qqv7MlXB/aDT8lRmpiYarKqppE0VYaFgU5ZG goUQVgW2EiKzbNdIUiIaJ5q+k65mDZxZPDAxgpE8+fNvTRpC5ExEe5A6oI6kx5a42YcymRomIu2K2 fHSuQjEqftuUILrHX9X2CoT/R8VuTEm40mzB+NQKG3ys+4tBVxVCVLKr+7y5VybzNFK5n6LuCHwDY G5Bz47yA==; Received: from mail-io1-f48.google.com ([209.85.166.48]:38422) by ecbiz261.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j454G-008zKM-RB for QUIC@ietf.org; Tue, 18 Feb 2020 10:45:57 -0500 Received: by mail-io1-f48.google.com with SMTP id s24so22768763iog.5 for ; Tue, 18 Feb 2020 07:45:48 -0800 (PST) X-Gm-Message-State: APjAAAW4oBAHjsqD3PnqbDiEhQwOxxERFB5IojGYhimXrRKRH2CV2HrU Q/uWIrfV7MaZjxBDGpEeBCmUlkIHqWaegIlJPz4= X-Google-Smtp-Source: APXvYqxTbGgFpxeXsM7HEnVqFDhf8Ek8/B8uircSkCZTHzRX24Mew0taRjNiWXcdtVTZiVcS527p442hOMRJ+b7f/Wk= X-Received: by 2002:a5d:9b12:: with SMTP id y18mr5632007ion.176.1582040748452; Tue, 18 Feb 2020 07:45:48 -0800 (PST) MIME-Version: 1.0 From: Jonathan Rosenberg Date: Tue, 18 Feb 2020 10:45:39 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: New mailer and IETF107 BoF on RIPT - voice over httpbis/quic To: QUIC@ietf.org Content-Type: multipart/alternative; boundary="000000000000d4f09f059edb9010" X-OutGoing-Spam-Status: No, score=-1.0 X-Get-Message-Sender-Via: ecbiz261.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed X-Authenticated-Sender: ecbiz261.inmotionhosting.com: jdrosen@jdrosen.net X-Originating-IP: 173.231.209.30 X-SpamExperts-Domain: ecbiz261.inmotionhosting.com X-SpamExperts-Username: 173.231.209.30 Authentication-Results: servconfig.com; auth=pass smtp.auth=173.231.209.30@ecbiz261.inmotionhosting.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0UaqOYGQPGxXNcBH7FeyDZOpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGD1MrJoK9JtNoVLbHoVHInyrgN zB/4Jkrw1eDLcif59fte/3zmGkGQneA8WNNbWS/SU7Tmz6iKnkQL9gqsxD3470fA0YZc+xfvG2CI OS28wWHeCraMRz3Zpm2/+WRGLAvPncd7d6Ar9jEsdmNrs5/Gb9pZr02kEVW6lkbUMxT6T1MW2zYz ltcgI/QO165UBzUizjHMm350tqBAfs9JUvo50yurnAgqfnDGmn2ukOhFDOP7XboatnmCadTOrkIb f975kHhEyM2tiEp+XRIAUc3UzkQMF99VlWOZVo1sbhkkbsVl3+TTaFqscM0+2EG9m6t7g8oiq9mz mwrbQbTulSg7juWBOXp8nHKe0R+FkIqN7hnDD6pB70LlwpsXkY1htC/fMczzN5mQ043Do45hhrwg 0REuqNMl4E+tMKMsv/A3u4xFRxF9LSHNsZFl22lrRRn/H0knlMgOQTVp+x1fo2EPm7RRpkhz2DzV 8AC0M8MF4CAePde1hfC62WPCh2eFne4ttx2+w6WCzCQD1cF/IhYabef4MG1fWx9wgPursioG1YOX Hjy/idBqr16QNZ5QSTQwlY0VFLSbFIu/G7s944hVWtALcfLsSdDQjx3YJQ9wjpnrNu10mK3aP+o3 gGmuv7WWvtfniS8/4KPPwSGgkUdVR/vbMh99te2yAVHGkzn6RH/ibvOlR7n+mLVXoref2nFetcKz lOiuRfGyvPhp04qWWePXdRjeeYOc4D1auWIFhSGnX5LVqRcupC/dtsVV9Bnvw6nIoDr0sXUZ7YZo Z/GZ+ok0RXCB5AzwbZ4SU5vHHMnt266BaCapkcEMMfcyb/+DDU6PNRkfow1xbM/2UJ2205F25Uiz 2aftYPu4QNsCeeBBRp9gx5laPNWqTz/BnPe8gEEc+Eql4Tj+X3YkLe5buZsVjy9XzROwHfhT0TBj IpnIsBWmQxKby4FdfisOZlTfMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@se1-lax1.servconfig.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 15:46:11 -0000 --000000000000d4f09f059edb9010 Content-Type: text/plain; charset="UTF-8" There is a new work effort underway to standardize an application protocol on top of httpbis for real-time voice and video, basically replacing SIP, RTP and SDP. This takes advantage of the usage of QUIC and UDP-based transport, that makes httpbis more amenable to real-time. The current draft also makes use of webtransport. We've got a mailer set up: https://www.ietf.org/mailman/listinfo/v3 And you can read the core draft here: https://datatracker.ietf.org/doc/draft-rosenbergjennings-dispatch-ript/?include_text=1 We'll be holding a BoF at IETF107 in Vancouver with the aim of chartering a working group. It would be great to get participation and support from the experts in the quic community. Thx, Jonathan R. -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --000000000000d4f09f059edb9010 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is a new work effort underway to standardize an appl= ication protocol on top of httpbis for real-time voice and video, basically= replacing SIP, RTP and SDP. This takes advantage of the usage of QUIC and = UDP-based transport, that makes httpbis more amenable to real-time. The cur= rent draft also makes use of webtransport.=C2=A0

We'= ve got a mailer set up:

And you can read the core draft h= ere:

--000000000000d4f09f059edb9010-- From nobody Wed Feb 19 06:33:51 2020 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 49ADB12008D for ; Wed, 19 Feb 2020 06:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 FLxV3i0dQPQp for ; Wed, 19 Feb 2020 06:33:47 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 54C251200B5 for ; Wed, 19 Feb 2020 06:33:47 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id n10so844883wrm.1 for ; Wed, 19 Feb 2020 06:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d/5J3E8RBYpzgCaWMw2A9jRgPDss33WN90UmElbvdmk=; b=PQQzZ6Jv7kds+gFFkSnT67dP+C02girWfF+/ZIeymIqx1ykA9c5l0XPDUfqrBUo/ah wXBovbd/iaL3FqklkCj69WP6TrsgL0wJHR70uRAzci3+vF21e7iblML2jch9XShXMlQy KLbJDn4q70zRGk4DsB537a/ufIi/SkL0BXtI/vGQqJezZ723bp1Ziwp8jrAX+eQDMjjI SFtVY2lP3i6B40mn6+Q46IKuIcpZaOUNpIczHjIKwuKG1R1ptUTOn8eO1NTgkkqpCGw2 fgMz6NBZUctWJK7zYqQF7SoofryOoNdw8ofFVbvok1CQcNM8sFAJEDApVjPOtHZ96sm+ fhDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d/5J3E8RBYpzgCaWMw2A9jRgPDss33WN90UmElbvdmk=; b=nN1LeZuFYO3ahuS1TRuVD6K+4dmX5oVlOEHhkffl1e7aMN/YrUXyp86o7RksiV3gpb Mb20qeCOB4USkUP7YiHvqW6/DsyP+cTUoS6wZnhTIBBnT6XyEA+TRcsH2hzoFeHS7rIc yF9asp1diHKe5oWKXCDryljxYDw0fbloSASIL4AgW38nEp4rYhjhNI3N2ExXShnUDgrJ P1K7kYZ/+t+iFFXUrNEtUnTirvSzdV3J2zda0Ob2PzXoQjH1stkOh6I8ZtN3YPZCSfU+ Q9dZ4mfHZEZGPJ0EAamTel2/h1J12BL1tg7xq0M0G9JvkiotwfauW1ZwON3+vphA+547 hwyg== X-Gm-Message-State: APjAAAVXRHr6bqJJGeyj/TeQYdF4e0j0YcWoykDBJhrJINkzcUllvU7f e8nA4YJLVxUp3EGh5zF8LyynMF1e3GC96YV8dMPHdBVj X-Google-Smtp-Source: APXvYqyRMwcGfz4evPvzejlsH/VOt4w0CTHoqut9oBn4Xp+Wb1l5M/fHulN7TNYQD4HWFgvRA+Ky1Lr3rOEjlyNTcus= X-Received: by 2002:a5d:6b82:: with SMTP id n2mr38864769wrx.153.1582122825547; Wed, 19 Feb 2020 06:33:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Pardue Date: Wed, 19 Feb 2020 14:33:34 +0000 Message-ID: Subject: Re: Consensus call, Transport Parameter change To: QUIC WG Cc: Lars Eggert , Mark Nottingham Content-Type: multipart/alternative; boundary="000000000000021375059eeead6a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 14:33:49 -0000 --000000000000021375059eeead6a Content-Type: text/plain; charset="UTF-8" Hearing no pushback, consensus declared. On Wed, Feb 12, 2020 at 1:01 PM Lucas Pardue wrote: > In the Zurich interim we discussed an issue related to changing Transport > Parameters to use variable-length integer encoding. The issue and its > proposal are shown below. Discussion at the interim seemed to support > consensus for accepting the proposal. > > The proposal makes a wire format change that will affect interoperability > among many implementations. In order to accelerate landing this change, > we're running a shorter 1-week consensus call for the single issue. If you > object to the proposal, please comment on the issue or in response to this > message. Absent any pushback, we'll direct the editors to incorporate the > change in one week's time. > > See for the current > state of issues in the Late Stage process, itself defined at < > https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md>. > > * #3294: Make transport parameter ID and length varint > The proposal is > > Cheers, > Lars, Lucas & Mark > QUIC WG Chairs > --000000000000021375059eeead6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hearing no pushback, consensus declared.

On Wed, Feb 12, 20= 20 at 1:01 PM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
In the Zurich interim we discu= ssed an issue related to changing Transport Parameters to use variable-leng= th integer encoding. The issue and its proposal are shown below. Discussion= at the interim seemed to support consensus for accepting the proposal.
=
The proposal makes a wire format change that will affect interoperabili= ty among many implementations. In order to accelerate landing this change, = we're running a shorter 1-week consensus call for the single issue. If = you object to the proposal, please comment on the issue or in response to t= his message. Absent any pushback, we'll direct the editors to incorpora= te the change in one week's time.

See <https://github.com= /quicwg/base-drafts/projects/5> for the current state of issues in t= he Late Stage process, itself defined at <https://g= ithub.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md>.

* = #3294: Make transport parameter ID and length varint
=C2=A0 The proposal= is <https://github.com/quicwg/base-drafts/pull/3169>

= Cheers,
Lars, Lucas & Mark
QUIC WG Chairs
--000000000000021375059eeead6a-- From nobody Wed Feb 19 06:40:05 2020 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 D301E1200F8 for ; Wed, 19 Feb 2020 06:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 WVvl0aAYnQyK for ; Wed, 19 Feb 2020 06:40:02 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 39DDD12008D for ; Wed, 19 Feb 2020 06:40:02 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id n10so870767wrm.1 for ; Wed, 19 Feb 2020 06:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=36fFenGILEhdWRmJaf25KKg5uMdY6Vw0adT9dg6VgFc=; b=ul4Fdt63xI1p0W8RtYsz4k8DOZd5y0fu/Cdxm7brhn4pHREj4qsj++GS8y/ECDQYej EphRoAcc2EcMZ0glkGP8GbaXz9ZWoiE0VpBqeqPPrZJqkLsuCi8QetL0SGgN1swlhLW1 TpO8B5noTAl5+ghZGkaCnY8CEJHz8lkPUZKOd/9JyrFFWohhY3RxPOQdS9UFY5V57IhV sq93Dody1rLJ0Ss7sfFXcVD2P8dkR/h+Z8xQ77jDLrfhaJFnlVFnEhsUwSY0x6T6hl78 i6ub6sgUbbHyKEbWMpyH62MbQL7vnv88zZR9RhlDzW6P459SvVdDySM89ucOlBpvyfwO trlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=36fFenGILEhdWRmJaf25KKg5uMdY6Vw0adT9dg6VgFc=; b=BbrMS1yhSE8wgLWd1eJGDazFuqhRHBsxqCPzNYcxpgymogFoexH2xw+CDvaBXQBsBT GHQv6zGRGO4JzHUB64LVK0OgzEybWgtGficeqlIl9loO3pnGhdtFWpRmrnMsWfclPH0W xaaPwAfrUSF9QjILba4ux44SMbQJ9pqdW7bGp4d7Iq+IgRLMHffTWoCPG5ybZ0nhfEzN Mw8ZHTIMEpvSDSscjDJlKU00e6sSq81MtWqpa4KCJtGxsMHJ2ZYOnlWYYTaWZ+RI3u5q oxTlDb5AUxamcUQJ2du5CNHrP/03bKWdzIYz+JVR0UYQswJT9C36Z85h/SAYzZUAA+XL HAwA== X-Gm-Message-State: APjAAAVsStD/V/XBtJPEW3B21ijY8a8FMXHlg1i/En1BsXkR1Xny8nF8 ukXRcVCEfFlf2+PK2fGBwsrTHhOtKzywh+Wz+M3tBYq6 X-Google-Smtp-Source: APXvYqwNIXMJiVV2L3srwsIFNCk76O8iS5wj4ZOHpGr7gJZp2cMLoFFaX0snd/VfwXQdcLLN/BhlQdtrs8nFcz0ffDU= X-Received: by 2002:adf:e5c2:: with SMTP id a2mr34933557wrn.85.1582123200287; Wed, 19 Feb 2020 06:40:00 -0800 (PST) MIME-Version: 1.0 From: Lucas Pardue Date: Wed, 19 Feb 2020 14:39:49 +0000 Message-ID: Subject: Consensus calls for Late Stage-Documents, post-Zurich edition To: QUIC WG Cc: Lars Eggert , Mark Nottingham Content-Type: multipart/alternative; boundary="000000000000581949059eeec3be" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 14:40:04 -0000 --000000000000581949059eeec3be Content-Type: text/plain; charset="UTF-8" The following issues have proposals for resolution, and discussion so far seems to support consensus to accept them. If you object, please do so on the issue or in response to this message (changing the Subject appropriately!). Absent any pushback, we'll direct the editors to incorporate them. See for the current state of issues in the Late Stage process, itself defined at . * #3456: Clarify when it is ok to ignore packet loss The proposal is * #3451: Should we allow ACK-only packets to be declared lost? The proposal is * #3423: active_connection_id_limit is unknown for 0-RTT The proposal is * #3396: Server cannot proceed after invalid Retry token The proposal is * #3373: More strongly recommend ECN marking The proposal is to close with no action. * #3350: Ignoring ACK delay can result in wrong RTT calculations The proposal is to close with no action. * #3348: Which DCID do Handshake retransmissions use? The proposal is * #3335: Immediate retransmission upon loss detection The proposal is * #3332: Composability of QUIC Extensions The proposal is to close with no action. * #3304: ACK generation recommendation The proposal is to close with no action. * #3291: Allow the Transport to Stop/Reset a Stream? The proposal is to close with no action. * #3272: pto_count should be reset when dropping a packet number space The proposal is * #3259: Safety issue during incipient persistent congestion episode The proposal is to close with no action. * #3216: Flow Control Tuning The proposal is to close with no action. * #3215: Timer interval for retire the connection IDs The proposal is to close with no action. * #3161: Simplify the client's PTO code by allowing the server to send a PING The proposal is to close with no action. * #3126: TIMEOUT CONNECTION_CLOSE error The proposal is to close with no action. * #3078: Lost Server Initial Takes Too Long to be Retransmitted The proposal is * #2923: MIN_RTT management The proposal is to close with no action. * #2632: H3 GOAWAY should be symmetric and cover bidi and uni streams The proposal is * #2387: Write up our security target against on-path attack The proposal is do no more than the editors' copy describes and close with no action. * #2143: Be more conservative about migration? The proposal is do no more than the editors' copy describes and close with no action. Regards Lars, Lucas and Mark QUIC Chairs --000000000000581949059eeec3be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The following issues have proposals for resolution, and di= scussion so far seems
to support consensus to accept them. If you object= , please do so on the issue or
in response to this message (changing the= Subject appropriately!). Absent any
pushback, we'll direct the edit= ors to incorporate them.

See <https://github.com/quicwg/base-drafts/projects/5<= /a>> for the current state of
issues in the Late Stage process, itsel= f defined at
<https://github.com/quicwg/base-drafts/blob/master/CO= NTRIBUTING.md>.

* #3456: Clarify when it is ok to ignore pack= et loss
=C2=A0 The proposal is <https://github.com/quicwg/base-drafts/pull/345= 0/files>

* #3451: Should we allow ACK-only packets to be decl= ared lost?
=C2=A0 The proposal is <https://github.com/quicwg/base-drafts/pull/3453>

* #3423: active_connection_id_limit is unknown for 0-RTT
= =C2=A0 The proposal is <https://github.com/quicwg/base-drafts/pull/3425>

= * #3396: Server cannot proceed after invalid Retry token
=C2=A0 The prop= osal is <htt= ps://github.com/quicwg/base-drafts/pull/3398>

* #3373: More s= trongly recommend ECN marking
=C2=A0 The proposal is to close with no ac= tion.

* #3350: Ignoring ACK delay can result in wrong RTT calculatio= ns
=C2=A0 The proposal is to close with no action.

* #3348: Which= DCID do Handshake retransmissions use?
=C2=A0 The proposal is <https://github.com/q= uicwg/base-drafts/pull/3349>

* #3335: Immediate retransmissio= n upon loss detection
=C2=A0 The proposal is <https://github.com/quicwg/base-drafts/= pull/3443>

* #3332: Composability of QUIC Extensions
=C2= =A0 The proposal is to close with no action.

* #3304: ACK generation= recommendation
=C2=A0 The proposal is to close with no action.

*= #3291: Allow the Transport to Stop/Reset a Stream?
=C2=A0 The proposal = is to close with no action.

* #3272: pto_count should be reset when = dropping a packet number space
=C2=A0 The proposal is <https://github.com/quicwg/bas= e-drafts/pull/3415>

* #3259: Safety issue during incipient pe= rsistent congestion episode
=C2=A0 The proposal is to close with no acti= on.

* #3216: Flow Control Tuning
=C2=A0 The proposal is to close = with no action.

* #3215: Timer interval for retire the connection ID= s
=C2=A0 The proposal is to close with no action.

* #3161: Simpli= fy the client's PTO code by allowing the server to send a PING
=C2= =A0 The proposal is to close with no action.

* #3126: TIMEOUT CONNEC= TION_CLOSE error
=C2=A0 The proposal is to close with no action.

= * #3078: Lost Server Initial Takes Too Long to be Retransmitted
=C2=A0 T= he proposal is <https://github.com/quicwg/base-drafts/issues/3078>

* #2= 923: MIN_RTT management
=C2=A0 The proposal is to close with no action.<= br>
* #2632: H3 GOAWAY should be symmetric and cover bidi and uni stream= s
=C2=A0 The proposal is <https://github.com/quicwg/base-drafts/pull/3129>
* #2387: Write up our security target against on-path attack
=C2=A0= The proposal is do no more than the editors' copy describes and close = with no action.

* #2143: Be more conservative about migration?
=C2=A0 The proposal is do no more than the editors' copy describes a= nd close with no action.

Regards
Lars, L= ucas and Mark
QUIC Chairs
--000000000000581949059eeec3be-- From nobody Thu Feb 20 17:11:07 2020 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 804541200F5 for ; Thu, 20 Feb 2020 17:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zX29noJOcTO7 for ; Thu, 20 Feb 2020 17:11:03 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 6A8D8120048 for ; Thu, 20 Feb 2020 17:11:03 -0800 (PST) Received: from xse144.mail2web.com ([66.113.196.144] helo=xse.mail2web.com) by mx181.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1j4wqJ-000KhP-Nl for quic@ietf.org; Fri, 21 Feb 2020 02:11:02 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 48Ntgh4DHGzP00 for ; Thu, 20 Feb 2020 17:10:56 -0800 (PST) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j4wqG-000718-Ep for quic@ietf.org; Thu, 20 Feb 2020 17:10:56 -0800 Received: (qmail 21927 invoked from network); 21 Feb 2020 01:10:56 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.204]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Feb 2020 01:10:55 -0000 To: IETF QUIC WG From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Subject: How do treat CID changes before HANDSHAKE_DONE Message-ID: Date: Thu, 20 Feb 2020 17:10:57 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FBBD0D19CF941EC0EF9DFA6E" Content-Language: en-US X-Originating-IP: 66.113.196.144 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.144/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.144/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0UaqOYGQPGxXNcBH7FeyDZOpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59ftC7cIsfrHWs8zegc19r7m5U7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/ICKD+bz1QuA8GxLVsb4edbyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilWEbX+OBfQvZ a2Z4uSB28NKCS+noqnLkLJ1dbiS8jHdfkQgX8db83GIgj8tVCbQqAYoQyfCZMHnX1xyiSXpQFfgM 7OYFXYdC3tRq275m/U3VTS31mvt+TpfpG7oe1oU5RLdCp3Zd9clP8wSiJZWbJCj+xRrjVmRxpGtS cvUmgj1LWPMRLM1ifcN/zogSpcxW3F2jZAOanSBpz6Rja2u/0jJnL+1r1xeA3qpV36sq6s9ITZYh Llri23ia6HDqcuNUS/ysta6u1iHEyuS7GD1uvcpETbjT//oj21hbHDB2NaOPJOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 01:11:06 -0000 This is a multi-part message in MIME format. --------------FBBD0D19CF941EC0EF9DFA6E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In the past, we have discussed the potential benefits for the client of quickly switching to a new connection ID once the handshake is complete. Suppose for example that there are several connections multiplexed on the same 5 tuple between a client and a server. Without migration, attackers can observe the pairing between CID used in each direction of traffic, associate a client sub-stream to a server sub-stream, and use that for example as input in a fingerprinting mechanism. If clients and server migrate to new CIDs, that pairing becomes more difficult. The question is, when to start doing that? And my proposal is, "after handshake complete", which in the client case means "after receiving handshake done". I have two worries. On one hand, I am concerned that staring a migration while the handshake is not finished makes the handshake process less robust to packet loss. On the other hand, I am also concerned that all potential privacy benefits of migrating to new CIDs are lost if the peer sends handshake packets with long headers associating the new DCID with the old SCID. For example, the client may have to repeat the final handshake packet on a timer. It will have to use a pair of CID in the long header. If it uses the new ones, it will reveal the linkage between the new client and server CID. If it uses the old one, it might end up using a CID that the server already discarded after the transition. The client can avoid these issues by simply waiting "handshake done" before migrating to new CID. There is some ambiguity in the spec on this subject. On one hand, section 9 says that "An endpoint MUST NOT initiate connection migration before the handshake is confirmed, as defined in section 4.1.2 of [QUIC-TLS ]= =2E" On the other hand, section 9.5 says that "At any time, endpoints MAY change the Destination Connection ID they send to a value that has not been used on another path." What shall the peer do if it receive data on a new DCID before the handshake is complete, before the handshake encryption keys have been discarded? My simplifying assumption is that before the handshake is done, peer can simply treat all incoming DCID as equivalent to DCID[0], and not trigger any specific processing. Is that correct? -- Christian Huitema --------------FBBD0D19CF941EC0EF9DFA6E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

In the past, we have discussed the potential benefits for the client of quickly switching to a new connection ID once the handshake is complete. Suppose for example that there are several connections multiplexed on the same 5 tuple between a client and a server. Without migration, attackers can observe the pairing between CID used in each direction of traffic, associate a client sub-stream to a server sub-stream, and use that for example as input in a fingerprinting mechanism. If clients and server migrate to new CIDs, that pairing becomes more difficult. The question is, when to start doing that? And my proposal is, "after handshake complete", which in the client case means "after receiving handshake done".

I have two worries. On one hand, I am concerned that staring a migration while the handshake is not finished makes the handshake process less robust to packet loss. On the other hand, I am also concerned that all potential privacy benefits of migrating to new CIDs are lost if the peer sends handshake packets with long headers associating the new DCID with the old SCID. For example, the client may have to repeat the final handshake packet on a timer. It will have to use a pair of CID in the long header. If it uses the new ones, it will reveal the linkage between the new client and server CID. If it uses the old one, it might end up using a CID that the server already discarded after the transition. The client can avoid these issues by simply waiting "handshake done" before migrating to new CID.

There is some ambiguity in the spec on this subject. On one hand, section 9 says that "An endpoint MUST NOT initiate connection migration before the handshake is confirmed, as defined in section 4.1.2 of [QUIC-TLS]." On the other hand, section 9.5 says that "At any time, endpoints MAY change the Destination Connection ID they send to a value that has not been used on another path." What shall the peer do if it receive data on a new DCID before the handshake is complete, before the handshake encryption keys have been discarded? My simplifying assumption is that before the handshake is done, peer can simply treat all incoming DCID as equivalent to DCID[0], and not trigger any specific processing. Is that correct?

-- Christian Huitema

--------------FBBD0D19CF941EC0EF9DFA6E-- From nobody Fri Feb 21 01:25:42 2020 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 38C09120074; Fri, 21 Feb 2020 01:25:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-transport-26.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <158227713414.29005.17669139647692674238@ietfa.amsl.com> Date: Fri, 21 Feb 2020 01:25:34 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 09:25:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-26.txt Pages : 174 Date : 2020-02-21 Abstract: This document defines the core of the QUIC transport protocol. Accompanying documents describe QUIC's loss detection and congestion control and the use of TLS for key negotiation. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at . Working Group information can be found at ; source code and issues list for this draft can be found at . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-transport-26 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-26 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 21 01:25:58 2020 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 87CCD120800; Fri, 21 Feb 2020 01:25:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-tls-26.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <158227714150.29013.4731034563256140614@ietfa.amsl.com> Date: Fri, 21 Feb 2020 01:25:41 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 09:25:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Using TLS to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-26.txt Pages : 52 Date : 2020-02-21 Abstract: This document describes how Transport Layer Security (TLS) is used to secure QUIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-tls-26 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-26 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 21 06:48:11 2020 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 13E56120859; Fri, 21 Feb 2020 06:47:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-http-26.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <158229647894.29029.17122277016210252474@ietfa.amsl.com> Date: Fri, 21 Feb 2020 06:47:59 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 14:48:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Hypertext Transfer Protocol Version 3 (HTTP/3) Author : Mike Bishop Filename : draft-ietf-quic-http-26.txt Pages : 61 Date : 2020-02-21 Abstract: The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-http/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-http-26 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-26 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 21 06:48:24 2020 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 E3DC112084F; Fri, 21 Feb 2020 06:48:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-qpack-13.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <158229648283.29077.12145077556353394494@ietfa.amsl.com> Date: Fri, 21 Feb 2020 06:48:02 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 14:48:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QPACK: Header Compression for HTTP/3 Authors : Charles 'Buck' Krasic Mike Bishop Alan Frindell Filename : draft-ietf-quic-qpack-13.txt Pages : 38 Date : 2020-02-21 Abstract: This specification defines QPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/3. This is a variation of HPACK header compression that seeks to reduce head-of-line blocking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-qpack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-qpack-13 https://datatracker.ietf.org/doc/html/draft-ietf-quic-qpack-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-qpack-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 21 08:31:31 2020 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 D572D12087C for ; Fri, 21 Feb 2020 08:31:29 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NrA2RC4BfJl2 for ; Fri, 21 Feb 2020 08:31:26 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650091.outbound.protection.outlook.com [40.107.65.91]) (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 0CF191201EA for ; Fri, 21 Feb 2020 08:31:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Up+qulFmcD550SNWHnaX7viwuqCToGJTm9RLc9Rmq8uHGaCWnDRkzHbXDWhIoVfRu2PohYj238NuFYOsrhNKCoXVIDB2rOdoqswolwLl/805Y0GSrRcdMP2Xes/Hd3S919ljHMq5vuU69hy03RtfVqIn0eza47bjRiJtsQDQsVdE/Ah6aMI+dbQITS4LpNb1frAewe/b4V9k0p4bDqNusxmSLeL8cV+GDCN7X4xPbCEciItPMU0cXiBekyWLtDaS7rPhWEHqHujNqVstAw++HSbnWg5voe6UTFzTuqPicIcPyHvsgsplnOhI6aKmJaEJ6zX4kkNvHITQfqG4mSoFkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bS8R67jLXIMz0zpeHzmIJLEcte5gVln5WHrotwsTT4k=; b=B2Gu7U0IPAZp4enc8Q0nhXu24JVy2/cQNS+29JhNk0Lg0XRWJbkVbLjS9jxqWc+vrIqQrGgcY+o+fxH5lfPiY7uDJ6PF1tsgssZVZFPBiErQIsc6HERVgJanYchje4xxmxl70tSqFT68qrcyiH7MlR0nm1mH2xHhknCoUztlc8wrR3VrLxuz7N6hT4zemdnNPR8/bfBzvWwbJpp45T0ijlMzPKNVT8xNYslDpGs5xErL2svFkLNP6E5CKwAHJfC5YFcomiwT46SDoxWPF2TY1hXfZ/pDhu0EEuYk5L2XObAqjM1VL2wk7X7qgKiXj+rzmiK56YyGYxJADXbaxHH66A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bS8R67jLXIMz0zpeHzmIJLEcte5gVln5WHrotwsTT4k=; b=P0HY3MhlF82y5d+wo25PXfNq9ozdVXEL/1DtnB0ZLxaEotMrBGG4MyPv9qI9vx8Lf7QLbWn5irN3QrYbZAaSaITkWPT9YTY/HPTpUK28pY+bQA3pRFQEsJKuu3DihhOYeJVUbcJqvNZg5yM39c962cnyn7oEIq5YCA42gkmRDEk= Received: from DM6PR00MB0459.namprd00.prod.outlook.com (20.178.29.88) by DM6PR00MB0681.namprd00.prod.outlook.com (10.141.187.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2797.0; Fri, 21 Feb 2020 16:31:24 +0000 Received: from DM6PR00MB0459.namprd00.prod.outlook.com ([fe80::6550:36f1:4f90:ca35]) by DM6PR00MB0459.namprd00.prod.outlook.com ([fe80::6550:36f1:4f90:ca35%4]) with mapi id 15.20.2769.000; Fri, 21 Feb 2020 16:31:24 +0000 From: Praveen Balasubramanian To: "quic@ietf.org" Subject: RE: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt Thread-Topic: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt Thread-Index: AQHV6JkVDf8rlAOHoUSNHQBSxDl6/Kgl1uCA Date: Fri, 21 Feb 2020 16:31:24 +0000 Message-ID: References: <158227713414.29005.17669139647692674238@ietfa.amsl.com> In-Reply-To: <158227713414.29005.17669139647692674238@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-21T16:31:22.7279078Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=4fbb1ada-622d-418c-9208-49aec0ce62ec; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:a:6c74:cda3:12a0:f9f8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a263a821-f930-4122-fff7-08d7b6eb7e11 x-ms-traffictypediagnostic: DM6PR00MB0681: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0320B28BE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39860400002)(136003)(376002)(346002)(366004)(199004)(189003)(10290500003)(33656002)(52536014)(8936002)(66574012)(316002)(7696005)(2906002)(66446008)(66556008)(478600001)(9686003)(55016002)(64756008)(66476007)(76116006)(66946007)(8990500004)(6916009)(966005)(6506007)(53546011)(86362001)(186003)(8676002)(81156014)(5660300002)(81166006)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0681; H:DM6PR00MB0459.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fb3OwaoJBdrMhHB+ShbrZCYTE3o5Ru6LHLbFuHv/UvSFj8b4t79kSdbwwylP0Lfys0MLOY1IoLL5Dy8DSncgd/qpZWn0+JMwazDSHnIVnlcGYqO79Dg9MSlXqZA+VwDU4TX7XIc/KMKtHYPmRUUtEPcwbgk3utPLhH9/ZnT5SWLhdT3qZHeXJS2QJMiAwdRNHXM2yQjtOoMcVHltjFjHztk7/ziVR7Bb/jzm6oErUSoQ3QpWdlrVhX/07pBbcK6ZiP4Oc4RBrasyRj60L7mGZqTTS9GPdDPr4s4vAT/jFinl7wz9FnjHXqvgRi3NrZZrLf05okYJyvQw8hQfk+fDouGmh/Q6b9koEaS91gu9xLdWBGnsTc1I0c5dhxJy1huF7KOtJah0l8aqKaXR/AkcMpHgdtZh1X3wbujHGV/Vvwq2kn0B/JUuwlaXgX5V8R0clVREqn5RX3cz3og5eXk32KtJBSn8NX44i3D5F5L1L6C7df7JzVjQ2fG0+H/63ph6igRXiLDrKXIzSM3mU9HcAA== x-ms-exchange-antispam-messagedata: MsIcjWYvYmsVHYAnJrYglxMZlNAMguRQuejW+BPyy3G4BAdHScqXpQt3fTVYCPQ5MCRJwVQhjjwIkzyI6QR9Z7qlaJOWRdoTkVkuWa2Cs+pQCCxJy2BuftyE8rJq1UbDRRyxvcuet0sdWVBgCk0DNfbkI1DpvSxxwzpRG+diVYwvVg+2/89v0AJfTDsXuxbj2WHwWfknmVkOwjmFYr8NUQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a263a821-f930-4122-fff7-08d7b6eb7e11 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2020 16:31:24.4193 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p4DBVDj7tynNWU9XQpYqcHj8DJwpWkvckmEjGEa9vQfE5nA5tvDmzLk8vmAOK7xmYVHNI4UkaUlS7N0y2Vz0GvEXLtYuRJwCDoeZyHSE124= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0681 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 16:31:30 -0000 RHJhZnQtMjYganVzdCBkcm9wcGVkIHdpdGggbWlub3IgY2hhbmdlcy4gVGhlIHBsYW5uaW5nIGRp c2N1c3Npb24gaW4gSUVURiAxMDYgd2FzIHRvIHN0YWJpbGl6ZSBhbmQgc2V0dGxlIG9uIGEgZHJh ZnQgdmVyc2lvbiBmb3Igc2l4IG1vbnRocyBvciBzbyB0byBnZXQgZGVwbG95bWVudHMgYW5kIGRh dGEuIEl0J2QgYmUgbmljZSBmb3IgaW1wbGVtZW50ZXJzIHRvIGdldCBzb21lIGlkZWEgb2Ygd2hh dCB0aGF0IHZlcnNpb24gaXMgc3VwcG9zZWQgdG8gYmUuIEkgd2FzIGFzc3VtaW5nIGl0J2QgYmUg ZHJhZnQtMjUgYnV0IHRoYXQncyBjbGVhcmx5IG5vdCB0aGUgY2FzZS4gQXJlIHRoZXJlIGFueSBt b3JlIGNoYW5nZXMgdGhhdCBhcmUgYSBtdXN0IGhhdmUgZm9yIHdpZGUgZGVwbG95bWVudD8gSSB0 aGluayBvbmx5IG1ham9yIHNlY3VyaXR5IGlzc3VlcyBvciBkZXBsb3ltZW50IGJsb2NrZXJzIHdv dWxkIHF1YWxpZnkuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMg PHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZw0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyMSwgMjAyMCAxOjI2IEFNDQpUbzogaS1kLWFu bm91bmNlQGlldGYub3JnDQpDYzogcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogW0VYVEVSTkFMXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0LTI2LnR4dA0KDQoNCkEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFFVSUMgV0cg b2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogUVVJQzogQSBVRFAtQmFz ZWQgTXVsdGlwbGV4ZWQgYW5kIFNlY3VyZSBUcmFuc3BvcnQNCiAgICAgICAgQXV0aG9ycyAgICAg ICAgIDogSmFuYSBJeWVuZ2FyDQogICAgICAgICAgICAgICAgICAgICAgICAgIE1hcnRpbiBUaG9t c29uDQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yNi50eHQN CglQYWdlcyAgICAgICAgICAgOiAxNzQNCglEYXRlICAgICAgICAgICAgOiAyMDIwLTAyLTIxDQoN CkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBjb3JlIG9mIHRoZSBRVUlD IHRyYW5zcG9ydCBwcm90b2NvbC4NCiAgIEFjY29tcGFueWluZyBkb2N1bWVudHMgZGVzY3JpYmUg UVVJQydzIGxvc3MgZGV0ZWN0aW9uIGFuZCBjb25nZXN0aW9uDQogICBjb250cm9sIGFuZCB0aGUg dXNlIG9mIFRMUyBmb3Iga2V5IG5lZ290aWF0aW9uLg0KDQpOb3RlIHRvIFJlYWRlcnMNCg0KICAg RGlzY3Vzc2lvbiBvZiB0aGlzIGRyYWZ0IHRha2VzIHBsYWNlIG9uIHRoZSBRVUlDIHdvcmtpbmcg Z3JvdXANCiAgIG1haWxpbmcgbGlzdCAocXVpY0BpZXRmLm9yZyksIHdoaWNoIGlzIGFyY2hpdmVk IGF0DQogICA8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGbWFpbGFyY2hpdmUuaWV0Zi5vcmclMkZhcmNoJTJGc2VhcmNoJTJG JTNGZW1haWxfbGlzdCUzRHF1aWMmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0 LmNvbSU3Q2E1OGMxNzMwZGNjYTQ2ZTIxZThmMDhkN2I2YjAzNDQyJTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE3ODc0MDIyNjA4OTE0NiZhbXA7c2RhdGE9 ZDdKeiUyQnZHRHQyQVpLa2VWVktZdlpEZkF2RlphQ2NiSDdLeTdtenBOZndZJTNEJmFtcDtyZXNl cnZlZD0wPi4NCg0KICAgV29ya2luZyBHcm91cCBpbmZvcm1hdGlvbiBjYW4gYmUgZm91bmQgYXQg PGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRmdpdGh1Yi5jb20lMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9z b2Z0LmNvbSU3Q2E1OGMxNzMwZGNjYTQ2ZTIxZThmMDhkN2I2YjAzNDQyJTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE3ODc0MDIyNjA4OTE0NiZhbXA7c2Rh dGE9YW1JJTJGOHVWeGNFMGpJVTJOazlmbHlZdVRsYVlOTlY1aGU2WjE5OEY0a2p3JTNEJmFtcDty ZXNlcnZlZD0wDQogICBxdWljd2c+OyBzb3VyY2UgY29kZSBhbmQgaXNzdWVzIGxpc3QgZm9yIHRo aXMgZHJhZnQgY2FuIGJlIGZvdW5kIGF0DQogICA8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3 ZyUyRmJhc2UtZHJhZnRzJTJGbGFiZWxzJTJGLXRyYW5zcG9ydCZhbXA7ZGF0YT0wMiU3QzAxJTdD cHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDYTU4YzE3MzBkY2NhNDZlMjFlOGYwOGQ3YjZiMDM0NDIl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTc4NzQwMjI2 MDg5MTQ2JmFtcDtzZGF0YT1VWmclMkYlMkIzbkpyc3AlMkZoVFRoeVhZdnclMkJxdnZDakN3RnpT Q1o2R0xlOUxQQlklM0QmYW1wO3Jlc2VydmVkPTA+Lg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2Vy IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0 Zi5vcmclMkZkb2MlMkZkcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0JTJGJmFtcDtkYXRhPTAyJTdD MDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0NhNThjMTczMGRjY2E0NmUyMWU4ZjA4ZDdiNmIw MzQ0MiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcxNzg3 NDAyMjYwODkxNDYmYW1wO3NkYXRhPTV4Tk56R0lkRDhxa2tpWUQ4SmZKZDN6S0tXTnFSekdVMHkz UnFFZU1pT1ElM0QmYW1wO3Jlc2VydmVkPTANCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVy c2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJh ZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yNiZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNy b3NvZnQuY29tJTdDYTU4YzE3MzBkY2NhNDZlMjFlOGYwOGQ3YjZiMDM0NDIlN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTc4NzQwMjI2MDg5MTQ2JmFtcDtz ZGF0YT1pVFd1SFpFMEQxaWx0cEdRTCUyRkpyMzVhQmw4OXV3eWRhb3FLejMlMkZqRzFCbyUzRCZh bXA7cmVzZXJ2ZWQ9MA0KaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1s JTJGZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yNiZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIl NDBtaWNyb3NvZnQuY29tJTdDYTU4YzE3MzBkY2NhNDZlMjFlOGYwOGQ3YjZiMDM0NDIlN0M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MTc4NzQwMjI2MDg5MTQ2 JmFtcDtzZGF0YT1ubTd6WSUyQnlORmUlMkZpTmJjQllBWExabnltOVZxSGJRRmRoV0MwbldqRHBR YyUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBp cyBhdmFpbGFibGUgYXQ6DQpodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZyZmNkaWZmJTNGdXJsMiUz RGRyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQtMjYmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQw bWljcm9zb2Z0LmNvbSU3Q2E1OGMxNzMwZGNjYTQ2ZTIxZThmMDhkN2I2YjAzNDQyJTdDNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzE3ODc0MDIyNjA4OTE0NiZh bXA7c2RhdGE9YllqU05ocEtuU2wzTDhBWVZIQ09PeUxZdnZvb1NBZVpva1FjdUpRakhoOCUzRCZh bXA7cmVzZXJ2ZWQ9MA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K From nobody Fri Feb 21 08:57:30 2020 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 7B5B312088F for ; Fri, 21 Feb 2020 08:57:29 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 foZXTT2uGosr for ; Fri, 21 Feb 2020 08:57:27 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 0A30812087C for ; Fri, 21 Feb 2020 08:57:27 -0800 (PST) Received: from xse453.mail2web.com ([66.113.197.199] helo=xse.mail2web.com) by mx128.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1j5Bc8-000NU5-Jx for quic@ietf.org; Fri, 21 Feb 2020 17:57:24 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 48PHgf0KLSz7BM4 for ; Fri, 21 Feb 2020 08:57:18 -0800 (PST) Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j5Bc5-0006w9-Tm for quic@ietf.org; Fri, 21 Feb 2020 08:57:17 -0800 Received: (qmail 9653 invoked from network); 21 Feb 2020 16:57:17 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.22]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Feb 2020 16:57:17 -0000 To: Praveen Balasubramanian , "quic@ietf.org" References: <158227713414.29005.17669139647692674238@ietfa.amsl.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Subject: Re: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt Message-ID: Date: Fri, 21 Feb 2020 08:57:19 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.197.199 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0UaqOYGQPGxXNcBH7FeyDZOpSDasLI4SayDByyq9LIhVft+tNpdzI6jX fzqHqH1X4UTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fs00Xq/1h4F0ZYii9vl+unVU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/+iU2d2HKPwiXQ4BZ4N2yebyme9ldZJ7uNXfg/GfS8fXOC4kn OJkMS8NGDKsP9r3Khy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8Z1crS5Y26dkj+rcJnpGpvK5dExkfODwJKeaajkWEaqQOmMnmpIzEnLqQ/+6ek1vQ72 ie80q3LAG2MiIaIREzT1xNjuO97khcUFBr/guEWv1bdCp3Zd9clP8wSiJZWbJCj+xRrjVmRxpGtS cvUmgj1LAEh8XLX9ld36lutKOYcqIV2jZAOanSBpz6Rja2u/0jKiWYlJx69EBB62vKdcKQzxh+Xw USsu3r8c/nSA6bEnnvysta6u1iHEyuS7GD1uvcqxsgSr0TsA9Y7KUy3xDWvOJOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 16:57:30 -0000 On 2/21/2020 8:31 AM, Praveen Balasubramanian wrote: > Draft-26 just dropped with minor changes. The planning discussion in IE= TF 106 was to stabilize and settle on a draft version for six months or s= o to get deployments and data. It'd be nice for implementers to get some = idea of what that version is supposed to be. I was assuming it'd be draft= -25 but that's clearly not the case. Are there any more changes that are = a must have for wide deployment? I think only major security issues or de= ployment blockers would qualify. There are=C2=A0 open 41 PRs, 15 of which are marked "design" . In particu= lar, PR #3169 did not make it into the draft. That PR would change the format of transport parameters. There was a rough consensus to adopt it in Zurich (I was in the rough). Since we don't see it in draft-26, shall we conclude that it was abandoned? Or is "stabilizing for 6 months" just one of those things that people say but don't really mean? -- Christian Huitema > > > -----Original Message----- > From: QUIC On Behalf Of internet-drafts@ietf.or= g > Sent: Friday, February 21, 2020 1:26 AM > To: i-d-announce@ietf.org > Cc: quic@ietf.org > Subject: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the QUIC WG of the IETF. > > Title : QUIC: A UDP-Based Multiplexed and Secure Tran= sport > Authors : Jana Iyengar > Martin Thomson > Filename : draft-ietf-quic-transport-26.txt > Pages : 174 > Date : 2020-02-21 > > Abstract: > This document defines the core of the QUIC transport protocol. > Accompanying documents describe QUIC's loss detection and congestion= > control and the use of TLS for key negotiation. > > Note to Readers > > Discussion of this draft takes place on the QUIC working group > mailing list (quic@ietf.org), which is archived at > . > > Working Group information can be found at quicwg>; source code and issues list for this draft can be found at > . > > > The IETF datatracker status page for this draft is: > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdat= atracker.ietf.org%2Fdoc%2Fdraft-ietf-quic-transport%2F&data=3D02%7C01= %7Cpravb%40microsoft.com%7Ca58c1730dcca46e21e8f08d7b6b03442%7C72f988bf86f= 141af91ab2d7cd011db47%7C1%7C0%7C637178740226089146&sdata=3D5xNNzGIdD8= qkkiYD8JfJd3zKKWNqRzGU0y3RqEeMiOQ%3D&reserved=3D0 > > There are also htmlized versions available at: > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftoo= ls.ietf.org%2Fhtml%2Fdraft-ietf-quic-transport-26&data=3D02%7C01%7Cpr= avb%40microsoft.com%7Ca58c1730dcca46e21e8f08d7b6b03442%7C72f988bf86f141af= 91ab2d7cd011db47%7C1%7C0%7C637178740226089146&sdata=3DiTWuHZE0D1iltpG= QL%2FJr35aBl89uwydaoqKz3%2FjG1Bo%3D&reserved=3D0 > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdat= atracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-quic-transport-26&data=3D= 02%7C01%7Cpravb%40microsoft.com%7Ca58c1730dcca46e21e8f08d7b6b03442%7C72f9= 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C637178740226089146&sdata=3Dnm7= zY%2ByNFe%2FiNbcBYAXLZnym9VqHbQFdhWC0nWjDpQc%3D&reserved=3D0 > > A diff from the previous version is available at: > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= =2Eietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-quic-transport-26&data=3D02= %7C01%7Cpravb%40microsoft.com%7Ca58c1730dcca46e21e8f08d7b6b03442%7C72f988= bf86f141af91ab2d7cd011db47%7C1%7C0%7C637178740226089146&sdata=3DbYjSN= hpKnSl3L8AYVHCOOyLYvvooSAeZokQcuJQjHh8%3D&reserved=3D0 > > > Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org= =2E > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > From nobody Fri Feb 21 09:08:40 2020 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 C49B4120168 for ; Fri, 21 Feb 2020 09:08:38 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 11qVKTODkjLD for ; Fri, 21 Feb 2020 09:08:37 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 D706B120147 for ; Fri, 21 Feb 2020 09:08:36 -0800 (PST) Received: from xse17.mail2web.com ([66.113.196.17] helo=xse.mail2web.com) by mx181.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1j5Bmv-000Ygc-S1 for quic@ietf.org; Fri, 21 Feb 2020 18:08:32 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 48PHvc2gw0z5KXC for ; Fri, 21 Feb 2020 09:07:40 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j5Bm8-0002lK-2X for quic@ietf.org; Fri, 21 Feb 2020 09:07:40 -0800 Received: (qmail 1392 invoked from network); 21 Feb 2020 17:07:39 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.22]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Feb 2020 17:07:39 -0000 Subject: Re: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt From: Christian Huitema To: Praveen Balasubramanian , "quic@ietf.org" References: <158227713414.29005.17669139647692674238@ietfa.amsl.com> Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Fri, 21 Feb 2020 09:07:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 66.113.196.17 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.17/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.17/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0UaqOYGQPGxXNcBH7FeyDZOpSDasLI4SayDByyq9LIhVAuc5ncAXmSml sqnlxqBxB0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59ftlnCC8n4vCfX/xbqBauYEhU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/ICKD+bz1QuA8GxLVsb4edbyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilWEbX+OBfQvZ a2Z4uSB28NKCS+noqnLkLJ1dbiS8jHdfk2J32VroMjrIy0DsmZ9K5yjUteVLhBzUpTzZopPAch70 lSfuxANzRU5MAZzTOSGBJ31C5K4rjWR+ptoqoAPm6fKY2AXNZGS5G93aGyH8MqMNONNOB63tZ91H 4Bn0Oix6chmsDLijuW2dTdMwK8e04pxMPnetLBJMh51NiRRoHIAQyMb6Bp/GI3JiRLsHVRkjmiK7 x42VjdzChZMe6O/DiWiiIzuXMTE3l4bIsk+O50vxD222yzPjkvH+X154lGiD08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 17:08:39 -0000 On 2/21/2020 8:57 AM, Christian Huitema wrote: > On 2/21/2020 8:31 AM, Praveen Balasubramanian wrote: >> Draft-26 just dropped with minor changes. The planning discussion in IETF 106 was to stabilize and settle on a draft version for six months or so to get deployments and data. It'd be nice for implementers to get some idea of what that version is supposed to be. I was assuming it'd be draft-25 but that's clearly not the case. Are there any more changes that are a must have for wide deployment? I think only major security issues or deployment blockers would qualify. > There are  open 41 PRs, 15 of which are marked "design" . In particular, > PR #3169 did not make it into the draft. That PR would change the format > of transport parameters. There was a rough consensus to adopt it in > Zurich (I was in the rough). Since we don't see it in draft-26, shall we > conclude that it was abandoned? Or is "stabilizing for 6 months" just > one of those things that people say but don't really mean? On the same topic, there is a poll in the implementers' Slack chat. Results so far are 12 votes to "abandon draft-26 and release draft-27 immediately", 0 against. There seem to be little appetite to rev the implementations for minor changes, and a willingness to test the new transport parameter format asap. -- Christian Huitema From nobody Fri Feb 21 09:17:16 2020 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 18BC712080E; Fri, 21 Feb 2020 09:17:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" Subject: WG Action: Rechartered QUIC (quic) X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , quic@ietf.org, quic-chairs@ietf.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158230542609.29045.17257270897680377388.idtracker@ietfa.amsl.com> Date: Fri, 21 Feb 2020 09:17:06 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 17:17:07 -0000 The QUIC (quic) WG in the Transport Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. QUIC (quic) ----------------------------------------------------------------------- Current status: Active WG Chairs: Mark Nottingham Lars Eggert Lucas Pardue Assigned Area Director: Magnus Westerlund Transport Area Directors: Mirja Kühlewind Magnus Westerlund Mailing list: Address: quic@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/quic Archive: https://mailarchive.ietf.org/arch/browse/quic/ Group page: https://datatracker.ietf.org/group/quic/ Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/ The QUIC working group will provide standards-track specifications for a UDP-based, stream-multiplexing, encrypted transport protocol, based on pre-standardization implementation and deployment experience. Key goals for QUIC are: - Minimizing connection establishment and overall transport latency for applications, starting with HTTP; - Providing multiplexing without head-of-line blocking; - Requiring only changes to path endpoints to enable deployment; - Enabling multipath and forward error correction extensions; and - Providing always-secure transport, using TLS 1.3 by default. The work of the group will have five main focus areas, corresponding to five core deliverables. 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 options negotiation. Work on congestion control will describe use of a standardized congestion controller as a default scheme for QUIC. Defining new congestion control schemes is explicitly out of scope for this group. QUIC is expected to support rapid, distributed development and testing of features. The second of these focus areas is security. This work will describe how the protocol uses TLS 1.3 for key negotiation and will also describe how those keys are used to provide confidentiality and integrity protection of both application data and QUIC headers. This work will ensure that QUIC has security and privacy properties that are at least as good as a stack composed of TLS 1.3 using TCP (or MPTCP when using multipath). The third focus area describes the mapping between the HTTP application protocol and the transport facilities of QUIC. This mapping will have performance characteristics comparable with HTTP/2, and provide extension mechanisms similar to HTTP/2. Upon completion of this mapping, work to define additional mappings may be included by updates to this charter, or may be worked on by other working groups. The fourth focus area will be on extensions to core protocol facilities, to enable datagram delivery, version negotiation, and multipath capabilities. Other extensions are out of the scope of this charter. The fifth focus area will provide an Applicability and Manageability Statement, describing how, and under what circumstances, QUIC may be safely used, and describing deployment and manageability implications of the protocol. Additionally, the Working Group will provide guidance on how to handle QUIC traffic in load balancers. Current practices for network management of transport protocols include the ability to apply access control lists (ACLs), hashing of flows for equal-cost multipath routing (ECMP), directional signaling of flows, signaling of flow setup and teardown, and the ability to export information about flows for accounting purposes. The QUIC protocol need not be defined to enable each of these abilities, or enable them in the same way as they are enabled by TCP when used with TLS 1.3, but the working group must consider the impact of the protocol on network management practices, reflecting the tensions described in RFC 7258. The QUIC working group will work closely with the HTTPbis working group, especially on the QUIC mapping for HTTP. Milestones: Jul 2020 - Core Protocol document to IESG Jul 2020 - Loss detection and Congestion Control document to IESG Jul 2020 - TLS 1.3 Mapping document to IESG Jul 2020 - HTTP/2 mapping document to IESG Jul 2020 - QUIC Applicability and Manageability Statement to IESG Jul 2020 - Version-Independent Properties of QUIC to IESG Jul 2020 - QPACK: Header Compression for HTTP over QUIC to IESG Dec 2020 - Working group adoption of Multipath extension document Mar 2021 - Datagram Extension to IESG Mar 2021 - Version Negotiation Extension to IESG Dec 2021 - Multipath extension document to IESG From nobody Fri Feb 21 13:08:32 2020 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 EFA37120086 for ; Fri, 21 Feb 2020 13:08:29 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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 YBkO8obFkph8 for ; Fri, 21 Feb 2020 13:08:27 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::728]) (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 385FA12006B for ; Fri, 21 Feb 2020 13:08:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SJfV97qWnVK5XUHmg9CojEA5ioLg1UakreL9CmqZ3UKlW+COydOniVlxvazefdDdGqCbVfT+wNKU2SOqTgq22fKNhs8oLtPw5HKg3iSzHxElj09OipgeIwRQGm+BOo0guephw/BLMmqjZkZBwv8LScLkvti0SNfepPDdVK2+y2wXKihB0F1fRR3CFVc2ruYWKqeCmYnZb+8cwhJFq8dFG0lV3hgAgshdPbbrtIP8y4WTwiVinUt0WAn1fhFzt6EMnyLo6fUAiFCUUcWCNADzNqla6uMkleewqqJJwRmJMhu+pAo72gqx6WRW/Ad+uC6p8TGIcQ9XnyCKEcoP/+l3fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sBnN1806DEeq/OhMHrmJBEeFMBNhNesfRescIbPTOac=; b=W0idqZB/UCnAhGChoX/c0JTZARSK7nVEAGBLiC6ICCPNyku2Iuo7jEhDf5HnZ144E+2V2fZOhK4kk4m+y2yFSMKAadOodNHH/rOkuU7aa9jGhn4IoB8B5jbe+zDCFUFsX3tu80oU67jZUGgzEkCJMOzWJysN7FxIDBjgnqh4ABEj3yucISRPMX37Z3JbTQ6vrvwSDO9WCb4WxSZY7VX+vXghKfREzxH/vVTL8IS+9q+N8RTvOnOBCaMc22nfoDGQZz8A6ok0OYBVX3WqfRALAaYRLwNPRVXt8W0owhSd7FLXb+KseLDs+RaWK+FX1Lyq9Suq6LD0lykCV6Fu26HqiA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sBnN1806DEeq/OhMHrmJBEeFMBNhNesfRescIbPTOac=; b=FiZ8exOJTi2209yVyb090CAF6R5wL34KZ3snG0R76ob5nbPVKLMjQZwruXghhO61jqzCVCDGfgFYMnFdPm1AcU9a309aVRMhbLRTJhy2W+nusCLxbWeQAWDQ0262WC6c4DM7jGAl9ghPur9yKktO70PY8J/XkSVg58JrKqEpqN0= Received: from DM6PR00MB0459.namprd00.prod.outlook.com (20.178.29.88) by DM6PR00MB0585.namprd00.prod.outlook.com (20.179.51.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2797.0; Fri, 21 Feb 2020 21:08:25 +0000 Received: from DM6PR00MB0459.namprd00.prod.outlook.com ([fe80::6550:36f1:4f90:ca35]) by DM6PR00MB0459.namprd00.prod.outlook.com ([fe80::6550:36f1:4f90:ca35%4]) with mapi id 15.20.2769.000; Fri, 21 Feb 2020 21:08:25 +0000 From: Praveen Balasubramanian To: Christian Huitema , "quic@ietf.org" Subject: RE: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt Thread-Topic: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt Thread-Index: AQHV6JkVDf8rlAOHoUSNHQBSxDl6/Kgl1uCAgAAH4oCAAALlgIAAAR2A Date: Fri, 21 Feb 2020 21:08:25 +0000 Message-ID: References: <158227713414.29005.17669139647692674238@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-02-21T21:08:23.8537712Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d2014ee9-7cbf-4aed-9dad-b663105276a6; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:a:6c74:cda3:12a0:f9f8] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9edcf1da-ba92-45d8-4353-08d7b71230fd x-ms-traffictypediagnostic: DM6PR00MB0585: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0320B28BE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(39860400002)(136003)(346002)(366004)(396003)(189003)(199004)(2906002)(33656002)(8936002)(8676002)(81166006)(81156014)(71200400001)(53546011)(9686003)(55016002)(186003)(6506007)(316002)(110136005)(10290500003)(478600001)(7696005)(66946007)(76116006)(66446008)(66556008)(8990500004)(52536014)(66476007)(64756008)(5660300002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0585; H:DM6PR00MB0459.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0iSMvTcFR1Ox3ecrQbiTPous73TMrm+oK1yZOgaploGvmcYDYLOXKejf7n9TyczSD7VclyVEDEWNuM4Ao3mikYVoUJ/DjfUeL7iR4TVrXs7LhQ46fuUK2NPcrhNLOhCjNDjcL9jVCc1jBzVA3mBg5+kICZYkwSZG0SQQS/N0D9Q1T+2F8Rekj5+i7RG38ctJ104/sAvdASBb/uHkLngbhSN7+jXb1zFbZ/yhTmHo5L7vlgsQnh6doX1a91BSqPnykz6jDh4dUdOOia6NPFh4V6PGZV2fu5k4lgMGKf70xKNKasEmPhDH4wKMilFvE2vypj4Hwhq2qEUFwYE7IrzJ30P3Ls1C3FIYeOw6sFqr1/O9yOV/qIUkVK07zgTbc6DgCw368rjOu4eMd+NmXC/7+eg8A48CzKaI3Klwbg6tQDJm1J9CEOeFKw4BDYnQwO91 x-ms-exchange-antispam-messagedata: eY+f9JTtb46aRmRvPQA5QuccP2tO1NvPEiVW7Rl/Ma7do/myIkUkFAvbAixD/YXhmjTdXKQ7nPXjMVRk5mK4kPFEyWuXVFSkj93BYX7NIjZ9R2zwpWFlU5yrPgffJ+45lvChZ1+wvVnhnkYQeVZQEyt82umbvxWc398DeObJsFNQu/lJBKc6Pfebeqdxh8EkuxKYjxAvodXjPmgYlEbgfQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9edcf1da-ba92-45d8-4353-08d7b71230fd X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2020 21:08:25.3704 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: c6CY/hEaaDPeafQ0ocO6md9N3dEKULLEDmcyu1QF996ATVFvuDWCqMkzGQVQ95pQD/twd9CxkFclFT4J9cp8EdBdUCKM6+aKF4BNxyQhSNs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0585 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 21:08:30 -0000 SXQgbWFrZXMgc2Vuc2UgdG8gaW5jbHVkZSBhbnkgVFAgZm9ybWF0IGNoYW5nZSBhbmQgcHVibGlz aCBkcmFmdC0yNyBpbW1lZGlhdGVseS4gQnV0IGluZGVwZW5kZW50IG9mIHRoYXQgSSdkIGxpa2Ug dGhlIFdHIHRvIGRlY2xhcmUgdGhlIGludGVuZGVkIHN0YWJsZSBkcmFmdCB2ZXJzaW9uLiBNYXli ZSBhdCB0aGUgSUVURiAxMDcgbWVldGluZz8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PiANClNlbnQ6IEZy aWRheSwgRmVicnVhcnkgMjEsIDIwMjAgOTowOCBBTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFu aWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtF WFRFUk5BTF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yNi50eHQNCg0K DQpPbiAyLzIxLzIwMjAgODo1NyBBTSwgQ2hyaXN0aWFuIEh1aXRlbWEgd3JvdGU6DQo+IE9uIDIv MjEvMjAyMCA4OjMxIEFNLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiB3cm90ZToNCj4+IERyYWZ0 LTI2IGp1c3QgZHJvcHBlZCB3aXRoIG1pbm9yIGNoYW5nZXMuIFRoZSBwbGFubmluZyBkaXNjdXNz aW9uIGluIElFVEYgMTA2IHdhcyB0byBzdGFiaWxpemUgYW5kIHNldHRsZSBvbiBhIGRyYWZ0IHZl cnNpb24gZm9yIHNpeCBtb250aHMgb3Igc28gdG8gZ2V0IGRlcGxveW1lbnRzIGFuZCBkYXRhLiBJ dCdkIGJlIG5pY2UgZm9yIGltcGxlbWVudGVycyB0byBnZXQgc29tZSBpZGVhIG9mIHdoYXQgdGhh dCB2ZXJzaW9uIGlzIHN1cHBvc2VkIHRvIGJlLiBJIHdhcyBhc3N1bWluZyBpdCdkIGJlIGRyYWZ0 LTI1IGJ1dCB0aGF0J3MgY2xlYXJseSBub3QgdGhlIGNhc2UuIEFyZSB0aGVyZSBhbnkgbW9yZSBj aGFuZ2VzIHRoYXQgYXJlIGEgbXVzdCBoYXZlIGZvciB3aWRlIGRlcGxveW1lbnQ/IEkgdGhpbmsg b25seSBtYWpvciBzZWN1cml0eSBpc3N1ZXMgb3IgZGVwbG95bWVudCBibG9ja2VycyB3b3VsZCBx dWFsaWZ5Lg0KPiBUaGVyZSBhcmXCoCBvcGVuIDQxIFBScywgMTUgb2Ygd2hpY2ggYXJlIG1hcmtl ZCAiZGVzaWduIiAuIEluIA0KPiBwYXJ0aWN1bGFyLCBQUiAjMzE2OSBkaWQgbm90IG1ha2UgaXQg aW50byB0aGUgZHJhZnQuIFRoYXQgUFIgd291bGQgDQo+IGNoYW5nZSB0aGUgZm9ybWF0IG9mIHRy YW5zcG9ydCBwYXJhbWV0ZXJzLiBUaGVyZSB3YXMgYSByb3VnaCBjb25zZW5zdXMgDQo+IHRvIGFk b3B0IGl0IGluIFp1cmljaCAoSSB3YXMgaW4gdGhlIHJvdWdoKS4gU2luY2Ugd2UgZG9uJ3Qgc2Vl IGl0IGluIA0KPiBkcmFmdC0yNiwgc2hhbGwgd2UgY29uY2x1ZGUgdGhhdCBpdCB3YXMgYWJhbmRv bmVkPyBPciBpcyAic3RhYmlsaXppbmcgDQo+IGZvciA2IG1vbnRocyIganVzdCBvbmUgb2YgdGhv c2UgdGhpbmdzIHRoYXQgcGVvcGxlIHNheSBidXQgZG9uJ3QgcmVhbGx5IG1lYW4/DQoNCk9uIHRo ZSBzYW1lIHRvcGljLCB0aGVyZSBpcyBhIHBvbGwgaW4gdGhlIGltcGxlbWVudGVycycgU2xhY2sg Y2hhdC4NClJlc3VsdHMgc28gZmFyIGFyZSAxMiB2b3RlcyB0byAiYWJhbmRvbiBkcmFmdC0yNiBh bmQgcmVsZWFzZSBkcmFmdC0yNyBpbW1lZGlhdGVseSIsIDAgYWdhaW5zdC4gVGhlcmUgc2VlbSB0 byBiZSBsaXR0bGUgYXBwZXRpdGUgdG8gcmV2IHRoZSBpbXBsZW1lbnRhdGlvbnMgZm9yIG1pbm9y IGNoYW5nZXMsIGFuZCBhIHdpbGxpbmduZXNzIHRvIHRlc3QgdGhlIG5ldyB0cmFuc3BvcnQgcGFy YW1ldGVyIGZvcm1hdCBhc2FwLg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg== From nobody Fri Feb 21 13:28:58 2020 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 1324B12008A; Fri, 21 Feb 2020 13:28:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-http-27.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <158232052792.29009.18397471679220082915@ietfa.amsl.com> Date: Fri, 21 Feb 2020 13:28:48 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 21:28:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Hypertext Transfer Protocol Version 3 (HTTP/3) Author : Mike Bishop Filename : draft-ietf-quic-http-27.txt Pages : 61 Date : 2020-02-21 Abstract: The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-http/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-http-27 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 21 13:33:31 2020 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 116E21200B8; Fri, 21 Feb 2020 13:33:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-transport-27.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <158232080397.29129.3971909070873362737@ietfa.amsl.com> Date: Fri, 21 Feb 2020 13:33:24 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 21:33:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-27.txt Pages : 174 Date : 2020-02-21 Abstract: This document defines the core of the QUIC transport protocol. Accompanying documents describe QUIC's loss detection and congestion control and the use of TLS for key negotiation. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at . Working Group information can be found at ; source code and issues list for this draft can be found at . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-transport-27 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 21 13:33:49 2020 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 7E9571200FE; Fri, 21 Feb 2020 13:33:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-tls-27.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <158232080945.29097.1608874746356694438@ietfa.amsl.com> Date: Fri, 21 Feb 2020 13:33:29 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 21:33:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Using TLS to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-27.txt Pages : 52 Date : 2020-02-21 Abstract: This document describes how Transport Layer Security (TLS) is used to secure QUIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-tls-27 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 21 13:53:00 2020 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 AD41C1200C5; Fri, 21 Feb 2020 13:52:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-qpack-14.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <158232197862.29073.13455431900231010267@ietfa.amsl.com> Date: Fri, 21 Feb 2020 13:52:58 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 21:52:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QPACK: Header Compression for HTTP/3 Authors : Charles 'Buck' Krasic Mike Bishop Alan Frindell Filename : draft-ietf-quic-qpack-14.txt Pages : 38 Date : 2020-02-21 Abstract: This specification defines QPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/3. This is a variation of HPACK header compression that seeks to reduce head-of-line blocking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-qpack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-qpack-14 https://datatracker.ietf.org/doc/html/draft-ietf-quic-qpack-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-qpack-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 21 14:02:36 2020 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 298C31200C1 for ; Fri, 21 Feb 2020 14:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 gekKTInVDiyt for ; Fri, 21 Feb 2020 14:02:31 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 52EF512008A for ; Fri, 21 Feb 2020 14:02:31 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id w15so3666133wru.4 for ; Fri, 21 Feb 2020 14:02:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hq6N2F9ViNAwOXFU2I9Tyz7jrBL0yggu9+29Ka8WUUs=; b=f9zS0SrSbZWMMA+PyxJEqhEydF1W4a2k7I48yb951VmQh4yw8RuW+7Eyq+Nj0ipE5l UxG6tVy9qOo3k9PmDZZZ57lBc4Sh++lifVAduC1VtzAUStEVEtFZsMO++dnTV5Pb6Nq5 ro3/WjIA3sxc6JdAAsetk6CCawq/EkPBjFNNzaoiLozlMoWBiqIk5yeks0oUvjPeunPY oBalD3VVCyva+NkyeW4MKngWyu9HjFDikn/e/3KUf3pP3W6nPi2+LEJv034Iz91nRE6P 2x1QLub5tzI5z0unQ21XwWzWJ+tiqCqzE3cWT/hpWhHYhdn5SdplfEswNLv8WwjZTsEk /bhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Hq6N2F9ViNAwOXFU2I9Tyz7jrBL0yggu9+29Ka8WUUs=; b=T1v2xc19P2UHV6bjiBCXIlT7zbKlPpH5TA2MxavhBcoQKtfSSu4UEqxK+L8Jl+QIAb /hqMY5zfZjDF9rljbnMZBsUlGy9vAJldNRaCHY1qkx17LTOKmU9dgkNeZD2CYxuwGdT3 +FesrUDCQSEvPB/8YXpVCGa31HccGHda0FUu4YyDDGSrRfDEzBIwludvGrgbLxoX8CAG XmePcHQ0A0zNkBVs0TYxVRMJW6fMOLNi5DJ/wC8NoZ9UQs3njG+LNHBGLHW0emIxXNd4 oOBAgJoxNY9sFDpP3vrmZTNIZqyuW847WKr5YvK8NT/q04+exsClDw7V5TxghSJ3vRIU WA7A== X-Gm-Message-State: APjAAAVOzlUtlHxEH/8vLbAA39hrMYu0+ZGDKHhZo4uZMx8tGvyulO3y /nEr7rt3lzxZEp+cRlbP5uuWrU3c5Zuz5MiBq2onKg== X-Google-Smtp-Source: APXvYqyS4uRi2vHPQsK26imlOVbt5eeBTHXbzBI0f5P3RVp65SoQA/OHfFDtYNYJTS6pFrjYJc4MVcRh54u7BA88Kf8= X-Received: by 2002:adf:e8ca:: with SMTP id k10mr47823065wrn.50.1582322549478; Fri, 21 Feb 2020 14:02:29 -0800 (PST) MIME-Version: 1.0 References: <158227713414.29005.17669139647692674238@ietfa.amsl.com> In-Reply-To: From: Ian Swett Date: Fri, 21 Feb 2020 17:02:17 -0500 Message-ID: Subject: Re: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt To: Praveen Balasubramanian Cc: Christian Huitema , "quic@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007bc2c0059f1d2d26" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 22:02:34 -0000 --0000000000007bc2c0059f1d2d26 Content-Type: text/plain; charset="UTF-8" As you saw, -27 was released because it did not include #3169. The intent of Google and Chrome is to implement and ship -27 as widely as possible. There are a number of design issues out for consensus call, but most should not have significant impact upon deployments and none are wire format changes. If the WG would like to declare -27 as a more stable deployment draft, that sounds great to me, since we intend to operate as though it is unless something drastic arises. Ian On Fri, Feb 21, 2020 at 4:08 PM Praveen Balasubramanian wrote: > It makes sense to include any TP format change and publish draft-27 > immediately. But independent of that I'd like the WG to declare the > intended stable draft version. Maybe at the IETF 107 meeting? > > -----Original Message----- > From: Christian Huitema > Sent: Friday, February 21, 2020 9:08 AM > To: Praveen Balasubramanian ; quic@ietf.org > Subject: Re: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt > > > On 2/21/2020 8:57 AM, Christian Huitema wrote: > > On 2/21/2020 8:31 AM, Praveen Balasubramanian wrote: > >> Draft-26 just dropped with minor changes. The planning discussion in > IETF 106 was to stabilize and settle on a draft version for six months or > so to get deployments and data. It'd be nice for implementers to get some > idea of what that version is supposed to be. I was assuming it'd be > draft-25 but that's clearly not the case. Are there any more changes that > are a must have for wide deployment? I think only major security issues or > deployment blockers would qualify. > > There are open 41 PRs, 15 of which are marked "design" . In > > particular, PR #3169 did not make it into the draft. That PR would > > change the format of transport parameters. There was a rough consensus > > to adopt it in Zurich (I was in the rough). Since we don't see it in > > draft-26, shall we conclude that it was abandoned? Or is "stabilizing > > for 6 months" just one of those things that people say but don't really > mean? > > On the same topic, there is a poll in the implementers' Slack chat. > Results so far are 12 votes to "abandon draft-26 and release draft-27 > immediately", 0 against. There seem to be little appetite to rev the > implementations for minor changes, and a willingness to test the new > transport parameter format asap. > > -- Christian Huitema > > > --0000000000007bc2c0059f1d2d26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As you saw, -27 was released because it did not include #3= 169.

The intent of Google and Chrome is to implement=C2= =A0and ship -27 as widely as=C2=A0possible.=C2=A0 There are a number of des= ign issues out for consensus call, but most should not have significant imp= act upon deployments and none are wire format changes.

=
If the WG would like to declare -27 as a more stable deployment draft,= that sounds great to me, since we intend to operate as though it is unless= something drastic arises.

Ian



On Fri, Feb 21, 2020 at 4:08 PM Praveen Balasubramanian <= ;pravb=3D40microsoft.com@= dmarc.ietf.org> wrote:
It makes sense to include any TP format change and publish dr= aft-27 immediately. But independent of that I'd like the WG to declare = the intended stable draft version. Maybe at the IETF 107 meeting?

-----Original Message-----
From: Christian Huitema <huitema@huitema.net>
Sent: Friday, February 21, 2020 9:08 AM
To: Praveen Balasubramanian <pravb@microsoft.com>; quic@ietf.org
Subject: Re: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt


On 2/21/2020 8:57 AM, Christian Huitema wrote:
> On 2/21/2020 8:31 AM, Praveen Balasubramanian wrote:
>> Draft-26 just dropped with minor changes. The planning discussion = in IETF 106 was to stabilize and settle on a draft version for six months o= r so to get deployments and data. It'd be nice for implementers to get = some idea of what that version is supposed to be. I was assuming it'd b= e draft-25 but that's clearly not the case. Are there any more changes = that are a must have for wide deployment? I think only major security issue= s or deployment blockers would qualify.
> There are=C2=A0 open 41 PRs, 15 of which are marked "design"= . In
> particular, PR #3169 did not make it into the draft. That PR would > change the format of transport parameters. There was a rough consensus=
> to adopt it in Zurich (I was in the rough). Since we don't see it = in
> draft-26, shall we conclude that it was abandoned? Or is "stabili= zing
> for 6 months" just one of those things that people say but don= 9;t really mean?

On the same topic, there is a poll in the implementers' Slack chat.
Results so far are 12 votes to "abandon draft-26 and release draft-27 = immediately", 0 against. There seem to be little appetite to rev the i= mplementations for minor changes, and a willingness to test the new transpo= rt parameter format asap.

-- Christian Huitema


--0000000000007bc2c0059f1d2d26-- From nobody Fri Feb 21 14:25:37 2020 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 B47291200C3 for ; Fri, 21 Feb 2020 14:25:35 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=litespeedtech-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 475gnB_VnqA5 for ; Fri, 21 Feb 2020 14:25:34 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 213DF12008A for ; Fri, 21 Feb 2020 14:25:34 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id j8so3343742qka.11 for ; Fri, 21 Feb 2020 14:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=fRpu2sHYtMGXJ7fE93OIFls+fCO+rHbrDrDA90V0gPo=; b=kEkFoZobMCBDzarEDSXUVGaK1PCYJzxaLVB9lzY9FV8JyyOB79nkp6ZpCdPdDnzSLA 029fkh41AFLJV1QozHZuWu/mIX0dwWUw7/6/ZAwBK/UAIJ+GF8gwLR6zBVaOBnz2idXt dGRqHlsgmKLPNQqPfaHOz40iQTh1tH2NQHVK4cd6TYcXuIis3+R0HMlT1e10S/1LJrGA tcfvPyT1ZeGhE25AwKlUc79IQ75UcMuUWuwmcplttSoEcqktbfOQTTq5YJB55i4DAJY+ 86Lz2JLb9fODrwx4fwqGkW2bbrZv0pNjalhB9vA9KaG6gQngW4sK/My22y/jYDFxTfcM aRGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=fRpu2sHYtMGXJ7fE93OIFls+fCO+rHbrDrDA90V0gPo=; b=s2MF0ZeFdoVreqbGVxdW3F8Y1PggS3yIouLc17MDJPIjBm8siAoNInTWY5zAGTpftS kOIM5DH5BnpFOtcqzEaoBTAp10GMVYYS9BqZ6GQTx2W4ofLFt09gZcrYAKiCNCED2NCS 7og0cpKTnRiXpUmfD/BGoYd8OXbDwVAFotx6Vac8csuD8Y0hAKzMdQY88nZMEcg9eYN5 6bNY8MlmGSkjfvKDzXE+/F3n0bNgHF7WBqp46EfjtknEr+mdMa4loOT/eU/6LXMDoSof S3yV3Ik4I/J561iS7QqCtkk1aRFmJtywQQQZJXr2rD4FX6QPTMn9xXVHxE86UCdF3uwC i8aw== X-Gm-Message-State: APjAAAU2F6/t0SUsB2okrgIOHNT7lGt1fkC6BTr0xue5+dDjZEHyeA55 miS26BxbCSEJOvv9XAgMt8DsCjLluqY= X-Google-Smtp-Source: APXvYqxzNiq1y2NVOu17RPTszXvbCuaTeohnh7cYfOO3OfkpjSHMvKx04ex7k3/GVMwFVwiHkTZh2Q== X-Received: by 2002:a05:620a:47:: with SMTP id t7mr34122951qkt.432.1582323933305; Fri, 21 Feb 2020 14:25:33 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id a196sm2185376qkg.105.2020.02.21.14.25.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 14:25:33 -0800 (PST) Date: Fri, 21 Feb 2020 17:25:25 -0500 From: Dmitri Tikhonov To: Ian Swett Cc: Praveen Balasubramanian , "quic@ietf.org" , Christian Huitema Subject: Re: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt Message-ID: <20200221222525.GA11213@ubuntu-dmitri> Mail-Followup-To: Ian Swett , Praveen Balasubramanian , "quic@ietf.org" , Christian Huitema References: <158227713414.29005.17669139647692674238@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 22:25:36 -0000 On Fri, Feb 21, 2020 at 05:02:17PM -0500, Ian Swett wrote: > The intent of Google and Chrome is to implement and ship -27 as widely > as possible. On the server as well? - Dmitri. From nobody Fri Feb 21 14:32:03 2020 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 894EB120147 for ; Fri, 21 Feb 2020 14:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCwydUFOdDqK for ; Fri, 21 Feb 2020 14:31:53 -0800 (PST) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 09E0F120800 for ; Fri, 21 Feb 2020 14:31:53 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id n27so2289931vsa.0 for ; Fri, 21 Feb 2020 14:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T4MZByEJ8fXM3SuqlZ707y/mHfKLSGUxjI9zb7S8iSc=; b=mYnyb8q1DGAa2HFkExtqVKjZCRb1kfDcX4vddThk2XW1i8vB/4k9ZkZAZRqKpqss+I jmyT0hokUBkNfcIGv/820qzInQplfowEhycSmNRvPqyE22VmnG3qAEq6NERph/UiqSdP Fo8KIn5G00upU1aC5JlYsVrDhCe/l+JSej5mlZQ+1LULYyRER4W0myIKYJpfCTPMkIh8 LhALoaNHUiunPAXXIW53GOYlcLUi8kO0oZpS/ux3OY7AlCrzFJK7T/xHzlQFbf6z/nAd pPqgX9Yrtkxl6oYgASiOEHY0WDWIhKXkhkFM1PwxDM5uHU1Kz3LKPM/069zpyooGMFxA wsDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T4MZByEJ8fXM3SuqlZ707y/mHfKLSGUxjI9zb7S8iSc=; b=cuRBLqTZdDdzyXUVeGwceLqrbSH8cBiWL8RdU9DrQYN2HQMeOhTkjqkJFyyU78VAiA B9MMjsCJrycRREQUi8XqVh1T94SjfPO08QVCA+gOqVei/e/Knj5PKzQIVTtXR88LDpbL aC91buiA4Yvr8CjFfbiFdX6RGPeOJ8OonnULhYRAnKnJfE+9x8FPf9W8/UT5fsgBV725 F5f3mzexFbE++LiqXcVjRj1cFQioI28GhZc/fpkWXMfm+kmRj4DZP0WdgN5BG9FEX0Sw oITFvqKzvwQ9kteq1ji/zJ7IDfn4+WhVazQkremuLyWLHLNGgwaAExJ47FvMBjyr9PEy BoIg== X-Gm-Message-State: APjAAAVVLa8zHmxlZOoTfKYyw/h3vNrB1Lgwp9iU0SQGv6rVJ+aw0vh6 LRE8rVUYWg+saejSIxb7vMOZPw5LR9orLX0pjioJ+juc X-Google-Smtp-Source: APXvYqwVpD02jHnCTtPectU2zJUbP55xiGquEfX/Awj6qtAX26H1nHoYn21syKeYeUQgQRoxcHOhVmksJUTCmFCZ6fo= X-Received: by 2002:a67:e3cc:: with SMTP id k12mr21375156vsm.213.1582324311918; Fri, 21 Feb 2020 14:31:51 -0800 (PST) MIME-Version: 1.0 References: <158227713414.29005.17669139647692674238@ietfa.amsl.com> In-Reply-To: From: Matt Joras Date: Fri, 21 Feb 2020 14:31:39 -0800 Message-ID: Subject: Re: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt To: Ian Swett Cc: Praveen Balasubramanian , IETF QUIC WG , Christian Huitema Content-Type: multipart/alternative; boundary="000000000000880c2a059f1d964d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 22:32:02 -0000 --000000000000880c2a059f1d964d Content-Type: text/plain; charset="UTF-8" +1. Facebook has a similar intention. We currently have a variant of draft-24 (with a different QUIC version number) widely deployed and have been waiting on the (hopefully) last wire format change which is now in -27. After that I am hoping we will be on that version for the foreseeable future as a stable version. Matt Joras On Fri, Feb 21, 2020, 2:02 PM Ian Swett wrote: > As you saw, -27 was released because it did not include #3169. > > The intent of Google and Chrome is to implement and ship -27 as widely > as possible. There are a number of design issues out for consensus call, > but most should not have significant impact upon deployments and none are > wire format changes. > > If the WG would like to declare -27 as a more stable deployment draft, > that sounds great to me, since we intend to operate as though it is unless > something drastic arises. > > Ian > > > > On Fri, Feb 21, 2020 at 4:08 PM Praveen Balasubramanian 40microsoft.com@dmarc.ietf.org> wrote: > >> It makes sense to include any TP format change and publish draft-27 >> immediately. But independent of that I'd like the WG to declare the >> intended stable draft version. Maybe at the IETF 107 meeting? >> >> -----Original Message----- >> From: Christian Huitema >> Sent: Friday, February 21, 2020 9:08 AM >> To: Praveen Balasubramanian ; quic@ietf.org >> Subject: Re: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt >> >> >> On 2/21/2020 8:57 AM, Christian Huitema wrote: >> > On 2/21/2020 8:31 AM, Praveen Balasubramanian wrote: >> >> Draft-26 just dropped with minor changes. The planning discussion in >> IETF 106 was to stabilize and settle on a draft version for six months or >> so to get deployments and data. It'd be nice for implementers to get some >> idea of what that version is supposed to be. I was assuming it'd be >> draft-25 but that's clearly not the case. Are there any more changes that >> are a must have for wide deployment? I think only major security issues or >> deployment blockers would qualify. >> > There are open 41 PRs, 15 of which are marked "design" . In >> > particular, PR #3169 did not make it into the draft. That PR would >> > change the format of transport parameters. There was a rough consensus >> > to adopt it in Zurich (I was in the rough). Since we don't see it in >> > draft-26, shall we conclude that it was abandoned? Or is "stabilizing >> > for 6 months" just one of those things that people say but don't really >> mean? >> >> On the same topic, there is a poll in the implementers' Slack chat. >> Results so far are 12 votes to "abandon draft-26 and release draft-27 >> immediately", 0 against. There seem to be little appetite to rev the >> implementations for minor changes, and a willingness to test the new >> transport parameter format asap. >> >> -- Christian Huitema >> >> >> --000000000000880c2a059f1d964d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1. Facebook has a similar intention. We currently h= ave a variant of draft-24 (with a different QUIC version number) widely dep= loyed and have been waiting on the (hopefully) last wire format change whic= h is now in -27. After that I am hoping we will be on that version for the = foreseeable future as a stable version.

Matt Joras


On Fri, Feb 21, 2020, 2:02 PM Ian Swett <ianswet= t=3D40google.com@dmarc.ietf.= org> wrote:
As you saw, -27 was released because it did not include #3169.

The intent of Google and Chrome is to implement=C2=A0and ship -27 a= s widely as=C2=A0possible.=C2=A0 There are a number of design issues out fo= r consensus call, but most should not have significant impact upon deployme= nts and none are wire format changes.

If the WG wo= uld like to declare -27 as a more stable deployment draft, that sounds grea= t to me, since we intend to operate as though it is unless something drasti= c arises.

Ian


<= /div>
O= n Fri, Feb 21, 2020 at 4:08 PM Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:
It makes sense to include any TP format = change and publish draft-27 immediately. But independent of that I'd li= ke the WG to declare the intended stable draft version. Maybe at the IETF 1= 07 meeting?

-----Original Message-----
From: Christian Huitema <huitema@huitema.net>
Sent: Friday, February 21, 2020 9:08 AM
To: Praveen Balasubramanian <pravb@microsoft.com>; quic@ietf.org<= br> Subject: Re: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt


On 2/21/2020 8:57 AM, Christian Huitema wrote:
> On 2/21/2020 8:31 AM, Praveen Balasubramanian wrote:
>> Draft-26 just dropped with minor changes. The planning discussion = in IETF 106 was to stabilize and settle on a draft version for six months o= r so to get deployments and data. It'd be nice for implementers to get = some idea of what that version is supposed to be. I was assuming it'd b= e draft-25 but that's clearly not the case. Are there any more changes = that are a must have for wide deployment? I think only major security issue= s or deployment blockers would qualify.
> There are=C2=A0 open 41 PRs, 15 of which are marked "design"= . In
> particular, PR #3169 did not make it into the draft. That PR would > change the format of transport parameters. There was a rough consensus=
> to adopt it in Zurich (I was in the rough). Since we don't see it = in
> draft-26, shall we conclude that it was abandoned? Or is "stabili= zing
> for 6 months" just one of those things that people say but don= 9;t really mean?

On the same topic, there is a poll in the implementers' Slack chat.
Results so far are 12 votes to "abandon draft-26 and release draft-27 = immediately", 0 against. There seem to be little appetite to rev the i= mplementations for minor changes, and a willingness to test the new transpo= rt parameter format asap.

-- Christian Huitema


--000000000000880c2a059f1d964d-- From nobody Fri Feb 21 14:33:11 2020 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 85CCF1200F4 for ; Fri, 21 Feb 2020 14:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 UePAvjt28Efp for ; Fri, 21 Feb 2020 14:33:07 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 0D80C1200DB for ; Fri, 21 Feb 2020 14:33:07 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id t23so3347272wmi.1 for ; Fri, 21 Feb 2020 14:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NMHwHwpZKp0NtYu6Myf9Pvucq1xkkuXfeqYJ205M8LM=; b=kaab/NVXxwjLInxJRNbEFn1MVCTbiW0WPUaAIZNyze3aZQCAQxI/V/JnqvHLE/0Q3r 7u1iDgbjThkrR9cAGiAVUWjjjCvRNXhr+3YUHam5aZs3G/afqAJrtW+70v+Y9gTEGvdD HHysYtQQERPruxntxnkH2DGaiIW0lMuYRWPnKFnedJuhbbLoN96MAkuQd32BA4S/tfgq kbdWDULUQl9iilaBWNFVz5A571YNfg7cEv80mEn0HqRJkbzq6RlWMEUmTB/L+Ery+QSH jcoQg+zK63LVN16c1RlMf3cZnvhMwQKxscIiM6r3KvXIjO1GIPFLlDR1VPaMV3BovH6c RCYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NMHwHwpZKp0NtYu6Myf9Pvucq1xkkuXfeqYJ205M8LM=; b=HAlCDDU5Sj6o5aEmJUiO64tqfNBp/2IHuNnsbyBwY8SthZAwf4fD8F4pj/QShLZqPN pSEJS3AJCJVjwQwHfnLexv3v8/P1KnzWD5QI+xbZRe1X53XBugI7ejNDSenuYEiz57al Rr90u1XRXvaIPgBybMq+ymHhmSNVBAbgIzwYHRj5JiD5kLwwwQMGCcLPdeqYV7SYs3x0 Yugh9NZlFFS38eIsA2dhrN2A559Mzv1o3fPzNWabl2ler1v/IkkBmJwCE5x0sIPMezyJ wP35ek3Ee17eNGHULecdrT56iv2B0ntPpMzPvDoZwVZWIgw9CmecnpRvy3YXC8tqPk1c 2AqQ== X-Gm-Message-State: APjAAAVw1mXbbwDVbV6bPPWFltuUy3RA/XTkoR9XZWDT0tIwqKGJrmUU 30R0TYlyXZyTkcjA4J6kIvFVhliUcef/EFwWuTyIRKb2 X-Google-Smtp-Source: APXvYqyj7U+jlSAfDVcSsnr1KfGK6Tq/C/dHA/8MXexAsx+0VCFUODm0SwY20xnre/kN8luKDV1GlJ9XOOrm4FJeeWQ= X-Received: by 2002:a1c:4b0f:: with SMTP id y15mr5933327wma.87.1582324385173; Fri, 21 Feb 2020 14:33:05 -0800 (PST) MIME-Version: 1.0 References: <158227713414.29005.17669139647692674238@ietfa.amsl.com> <20200221222525.GA11213@ubuntu-dmitri> In-Reply-To: <20200221222525.GA11213@ubuntu-dmitri> From: Ian Swett Date: Fri, 21 Feb 2020 17:32:52 -0500 Message-ID: Subject: Re: [EXTERNAL] I-D Action: draft-ietf-quic-transport-26.txt To: Ian Swett , Praveen Balasubramanian , "quic@ietf.org" , Christian Huitema Cc: Praveen Balasubramanian Content-Type: multipart/alternative; boundary="000000000000e64bc3059f1d9a38" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 22:33:10 -0000 --000000000000e64bc3059f1d9a38 Content-Type: text/plain; charset="UTF-8" That is the intent. As always, widely enabling IETF QUIC draft 27 may be delayed by any performance regressions. On Fri, Feb 21, 2020 at 5:25 PM Dmitri Tikhonov wrote: > On Fri, Feb 21, 2020 at 05:02:17PM -0500, Ian Swett wrote: > > The intent of Google and Chrome is to implement and ship -27 as widely > > as possible. > > On the server as well? > > - Dmitri. > --000000000000e64bc3059f1d9a38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That is the intent.=C2=A0 As always, widely enabling IETF = QUIC draft 27 may be delayed by any performance regressions.

On Fri, Feb 21,= 2020 at 5:25 PM Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
On Fri, Feb 21, 2020 at 05:02:17PM -050= 0, Ian Swett wrote:
> The intent of Google and Chrome is to implement and ship -27 as widely=
> as possible.

On the server as well?

=C2=A0 - Dmitri.
--000000000000e64bc3059f1d9a38-- From nobody Fri Feb 21 16:23:50 2020 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 7C0D81200E5; Fri, 21 Feb 2020 16:23:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-recovery-26.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <158233102032.29009.4315590876332662594@ietfa.amsl.com> Date: Fri, 21 Feb 2020 16:23:40 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 00:23:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-26.txt Pages : 41 Date : 2020-02-21 Abstract: This document describes loss detection and congestion control mechanisms for QUIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-26 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-26 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 22 00:57:30 2020 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 232A3120132 for ; Sat, 22 Feb 2020 00:57:29 -0800 (PST) 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 (2048-bit key) header.d=lowentropy.net header.b=m+zOpDeI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q7gC2voE 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 9oDsH2y2psLa for ; Sat, 22 Feb 2020 00:57:27 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6844120123 for ; Sat, 22 Feb 2020 00:57:26 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9AD0E22101 for ; Sat, 22 Feb 2020 03:57:22 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sat, 22 Feb 2020 03:57:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=ehC+saDv2D4D0hvpVgV6T6LsNtbQmMP HP+fVjYSJf2M=; b=m+zOpDeIhkJl7jy0r2Z3fsUI/4qBpZtea9zzJmet5B53Uce F5VksL72CM26copEHeFVTHzwIXJo3R9xpbWFizpDbhFtvNYd1uc4mGrRRVxMgahx fsPBMETZp0n2mNgLuxI/nwoTI9lw+IjZRgx98wjyjSlA3A/Sa9vyBDl0jRK+IH7J VzATcrs3m4JVe8jCq6/tv8wXlTvTaL0as3lmeOYppvdpGGlQrQPJXwYC1kTQs6iC W3OiANFLEJ/w59dx9zYqvIxQPeYh+ZS256GnIq7Pv07gdV6+mj6kVynoNlnF/y3V lPYMwP2XWrRoImqVgiNx0LT3bP0mW9eZ5fRHPAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ehC+sa Dv2D4D0hvpVgV6T6LsNtbQmMPHP+fVjYSJf2M=; b=q7gC2voEGagPPOej3/Hxaf V+/GMPGlLnMXXo+xDHBXO2b/B+pYCKroTrdvMlm/7Av1rKHcD+FG0OC9wkSMYu1c 9MiYA5KIBRogv1f4KCd3rsZeT0IJ11DYxDwTNuKQg9xBx0vNjv6oticEWEvfRLSL YFuHYDviwnLDH5fmNH5v3kUkBWVDhDcfDkzJeRbF+h8OB8v2nMlB3jknPFsnMMQm cp+zHeHd/KMEMxJCDItUVixXLk7QOzrIHy6l4SgQvYaMBC5kp1NVSMSM26HA4dvV x0BvFTN+xukEPLZpzyR5PtNJCCWf7R9aTtAR9/SP0yY3awg3knsb5Z1FQ2kbEjUA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeehgdduvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepqhhuihgtfihgrdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohif vghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1E9C6E00B1; Sat, 22 Feb 2020 03:57:22 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 22 Feb 2020 19:57:00 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Re: How do treat CID changes before HANDSHAKE_DONE Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 08:57:29 -0000 Hi Christian, I think that perhaps you are conflating the two concepts of migration and connection ID use here, but your conclusion is absolutely correct. Using a new connection ID does not imply migration, though migration implies use of a new connection ID. So while a client can use new connection IDs during the handshake, it cannot move to a new path until it sees HANDSHAKE_DONE. There are a few things implied by this. Most relevant here is that when an endpoint issues a new connection ID, by any means, it has to be prepared to receive packets that use that connection ID. If you think that you can see a way to improve the description of this in the draft, I'd appreciate your thoughts. Cheers, Martin On Fri, Feb 21, 2020, at 12:10, Christian Huitema wrote: > > In the past, we have discussed the potential benefits for the client of > quickly switching to a new connection ID once the handshake is > complete. Suppose for example that there are several connections > multiplexed on the same 5 tuple between a client and a server. Without > migration, attackers can observe the pairing between CID used in each > direction of traffic, associate a client sub-stream to a server > sub-stream, and use that for example as input in a fingerprinting > mechanism. If clients and server migrate to new CIDs, that pairing > becomes more difficult. The question is, when to start doing that? And > my proposal is, "after handshake complete", which in the client case > means "after receiving handshake done". > > I have two worries. On one hand, I am concerned that staring a > migration while the handshake is not finished makes the handshake > process less robust to packet loss. On the other hand, I am also > concerned that all potential privacy benefits of migrating to new CIDs > are lost if the peer sends handshake packets with long headers > associating the new DCID with the old SCID. For example, the client may > have to repeat the final handshake packet on a timer. It will have to > use a pair of CID in the long header. If it uses the new ones, it will > reveal the linkage between the new client and server CID. If it uses > the old one, it might end up using a CID that the server already > discarded after the transition. The client can avoid these issues by > simply waiting "handshake done" before migrating to new CID. > > There is some ambiguity in the spec on this subject. On one hand, > section 9 says that "An endpoint MUST NOT initiate connection migration > before the handshake is confirmed, as defined in section 4.1.2 of > [QUIC-TLS > ]." On the other hand, section 9.5 says that "At any time, endpoints MAY change the Destination Connection ID they send to a value that has not been used on another path." What shall the peer do if it receive data on a new DCID before the handshake is complete, before the handshake encryption keys have been discarded? My simplifying assumption is that before the handshake is done, peer can simply treat all incoming DCID as equivalent to DCID[0], and not trigger any specific processing. Is that correct? > > -- Christian Huitema > From nobody Sat Feb 22 14:00:50 2020 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 528FC3A08B8 for ; Sat, 22 Feb 2020 14:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Or8Unn_E9OtH for ; Sat, 22 Feb 2020 14:00:47 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 A3B2F3A08B7 for ; Sat, 22 Feb 2020 14:00:46 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id x7so5964610ljc.1 for ; Sat, 22 Feb 2020 14:00:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xh/gXyJoY2TLHOqF+HpX6XizhydzI8NYc0AKZ4mWGms=; b=0VAWUxh9GB0M2KBqol3MR7EKhW6P9f24dF7bNvMdVv8hpDtH4ZcnJTyGwGAyQ7yICQ zuDJMg5zVwQ0KSlJZc0a2xsGNYT9vI6uvTXkCGx7iAr4WVd/TCYMZAbTqvztEo790WKr xuyKY3e/ebVAkW7fhgNyFiXsLoWq12YGcf0hLqMu2s7TWB30jlnr5NTnew3PCvBl6ZV8 NqpCAHRGCanMSwF1p4ly41zEvw2hJjdroC+flxb48BOmhyzDreI3N0pT8o8BOa4oifwI AOpJV8o/olC7S6nzKYnv0rvUrHPfEODSjkXTCe1pdT2owqwswIfYj6Hm/x/VhrvSKR1j DQ6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xh/gXyJoY2TLHOqF+HpX6XizhydzI8NYc0AKZ4mWGms=; b=XZar+XkyryY5UwSnHm9LBfxSEe2hWomnBCGp6+xC7MQ8bwaEt04kk43YtaD66R6mqe 3KY0tIxr28zsnpv6C9xx+GT6EL9kj9K2rgo443t0r3iWW/LrYy1Mf48sSZy7RXavXBS9 06RgH9/POVj5MHES+ISF6/COsA5b8qYot6Gep1B4DtGqUXXTQjqQfk/iqXyWLMYVN3aN hRn53jML2bVMcWvVKDT5DEsB96G9BfY+t8ix6wbOOytKixhuXm1IN8w7uyndhC/GNdQT clN9IqivXBkDmyMnNXnwuN4OrFgtKVKGP05VgEjd8cS6CnPWP/zp8G/JXwM114fXQwEF zqDQ== X-Gm-Message-State: APjAAAVl8L715RFbe9wLIj7uAshD49zfN1uyGVsTbnBEVfALPYDxPLsI f9lIzqyFP+q4z8N91UGozk4+d7zL2kZSgNeg4/hwiB++I0Q= X-Google-Smtp-Source: APXvYqyfx1ioXcyx92cjZNqVet/pqj96DBg77gFju7AgJ/GrO1+Wshv4G/tLMUpRAQFySzAODOvtl4QRHL/pAzEO2CU= X-Received: by 2002:a05:651c:448:: with SMTP id g8mr26557591ljg.35.1582408844690; Sat, 22 Feb 2020 14:00:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sat, 22 Feb 2020 14:00:08 -0800 Message-ID: Subject: Re: New mailer and IETF107 BoF on RIPT - voice over httpbis/quic To: Jonathan Rosenberg , v3@ietf.org Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000013dd67059f3145e2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 22:00:49 -0000 --00000000000013dd67059f3145e2 Content-Type: text/plain; charset="UTF-8" Jonathan, Thanks for sending this. While I think it's interesting to explore the question of how to reinvent the real-time comms infrastructure using modern Web-style technologies. I have a number of concerns with the design and assumptions embodied in this draft. WEB ARCHITECTURE This document talks multiple times about how it's designed to work with existing HTTP infrastructure and there are a number of features of this design that seem to be dictated by that. However, it seems to me that you are making a number of surprising (and perhaps incorrect) assumptions about architecture and in general this seems misguided. - Transport Connections and HTTP Requests Need Not Fate Share There seems to be an implicit assumption in this design that HTTP LBs have semi-persistent routing, such that if request 1 and request 2 go to different servers this is a "migration" event (S 8.9). This may be the case in some architectures but it's not by any means guaranteed. The LB is free to send every request to a different server, and Web applications need to be designed to accommodate this. (see, for instance: https://www.oreilly.com/library/view/programming-google-app/9781491900246/ch01.html . section The Runtime Environment). While this might in principle be compatible with RIPT as designed, it seems unlikely to work well if each byway goes to a different server. - Use Datagrams, not Raw H3 Relatedly, trying to simulate an unreliable channel by round-robining a reliable set of streams is clumsy at best. For instance, in cases where you are transmitting too quickly, you now build up a backlog of HTTP requests which must still be (re)transmitted even though they out of date -- and they may even be transmitted before the timely ones. We already have a technology designed to provide unreliable messaging for QUIC (https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/). As far as I can tell, the only reason not to use it is that you are trying to avoid making any new requirements on the server, but I think that is a mistake because (1) as noted above, you already are making non-standard assumptions and (2) the future is bigger than the past, especially given the state of QUIC deployment. - H3 Is Not Guaranteed Conversely, you can't assume that H3 will be available. A significant fraction of networks already do not pass QUIC, so if you want a viable system it has to gracefully fall back to H2. I would deal with this and the previous point by just pointing at WebTransport, which already is expected to provide both unreliable service and fallback. CALLING MODEL Assuming I am understanding this draft correctly, it does not meaingfully support incoming calls to end-user devices because you have to run a server (which end-user devices will not and generally cannot). I see you have some notion of having an extension for this, but that should be provided from the first. This seems like an odd omission to say the least. LACK OF E2E SECURITY Your charter specifies e2e security, but AFAICT, this is not provided by this specification, nor is it obvious how to enhance it to provide it. Indeed, it seems like there's not any support for a disjoint media path. You may recall that I made similar comments at the DISPATCH session in SIN, and I had understood that it was your intention to accommodate these cases, but I don't see anything here, which is somewhat disappointing. I see that the charter says "The protocol uses HTTP techniques for authentication and authorization (notably OAuth), and requires hop by hop encryption (i.e., https). The protocol will also allow for e2e media encryption, although keying is out of scope, and is expected to be handled by other protocols such as MLS." I can't agree with this. If you're going to have STIR, then you have what you need to provide for E2E media encryption, and it's a regression from WebRTC not to provide it. DETAILED COMMENTS I also noted some more detailed issues, as noted below. S 3. REQ4: The solution should hide the number of servers behind the load balancer, allow the addition or removal of servers from the cluster at will, and not expose any of this information to the peer This seems like an odd requirement. I'm not sure how one would even analyze this. What about timing side channels, host-ids in cookies, etc.? S 6. To ensure authenticated caller ID everywhere, the TG specifies the set of allowed caller IDs through an [RFC8226] certificate. This not only informs the client about what numbers it can originate with, it also proves to the client that it is capable of vouching for those numbers. In what way does it prove to the client that it is capable of vouching? Certificates are public information. Is this tied to the TLS connection in some way? S 8.4. The customer TG URI has to be reachable by the server in order for the it to receive calls, and for security purposes it must also support TLS and present a valid domain certificate using the same trust chains configured into browsers. 1. There is no real IETF normative definition for the trust anchors for browsers. This is a local (And browser-specific matter) 2. It's worth noting that in this design it's not clear that you would need to have a WebPKI valid ceritifcae. S 8.5. I'm really not a fan of the handler syntax, which seems not very finished and kind of unspecified. For instance: "clientDirectives": "1 to 1: opus; 2 to 2: H264,max-width=1280,max-height=720", Why are you using JSON and then requiring me to parse a string? S 9.7. Why are you inventing your own cert enrollment protocol as opposed to using ACME? Now we have to analyze this protocol too. On Tue, Feb 18, 2020 at 7:46 AM Jonathan Rosenberg wrote: > There is a new work effort underway to standardize an application protocol > on top of httpbis for real-time voice and video, basically replacing SIP, > RTP and SDP. This takes advantage of the usage of QUIC and UDP-based > transport, that makes httpbis more amenable to real-time. The current draft > also makes use of webtransport. > > We've got a mailer set up: > https://www.ietf.org/mailman/listinfo/v3 > > And you can read the core draft here: > > https://datatracker.ietf.org/doc/draft-rosenbergjennings-dispatch-ript/?include_text=1 > > > We'll be holding a BoF at IETF107 in Vancouver with the aim of chartering > a working group. > > It would be great to get participation and support from the experts in the > quic community. > > Thx, > Jonathan R. > > -- > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > --00000000000013dd67059f3145e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jonathan,

Thanks for sending this.

While I t= hink it's interesting to explore the question of how
to reinvent the= real-time comms infrastructure using modern
Web-style technologies. I h= ave a number of concerns with
the design and assumptions embodied in thi= s draft.


WEB ARCHITECTURE
This document talks multiple times = about how it's designed to work
with existing HTTP infrastructure an= d there are a number of features
of this design that seem to be dictated= by that. However, it seems to
me that you are making a number of surpri= sing (and perhaps incorrect)
assumptions about architecture and in gener= al this seems misguided.

- Transport Connections and HTTP Requests N= eed Not Fate Share There
seems to be an implicit assumption in this desi= gn that HTTP LBs have
semi-persistent routing, such that if request 1 an= d request 2 go to
different servers this is a "migration" even= t (S 8.9). This may be the
case in some architectures but it's not b= y any means guaranteed. The
LB is free to send every request to a differ= ent server, and Web
applications need to be designed to accommodate this= .
(see, for instance: https://www.oreilly.com/libra= ry/view/programming-google-app/9781491900246/ch01.html.
section The = Runtime Environment).

While this might in principle be compatible wi= th RIPT as designed, it seems
unlikely to work well if each byway goes t= o a different server.

- Use Datagrams, not Raw H3
Relatedly, tryi= ng to simulate an unreliable channel by round-robining
a reliable set of= streams is clumsy at best. For instance, in cases
where you are transmi= tting too quickly, you now build up a backlog
of HTTP requests which mus= t still be (re)transmitted even though they
out of date -- and they may = even be transmitted before the timely
ones.

We already have a tec= hnology designed to provide unreliable messaging
for QUIC (https://datatrac= ker.ietf.org/doc/draft-pauly-quic-datagram/).
As far as I can tell, = the only reason not to use it is that you
are trying to avoid making any= new requirements on the server,
but I think that is a mistake because (= 1) as noted above, you
already are making non-standard assumptions and (= 2) the future
is bigger than the past, especially given the state of QUI= C deployment.


- H3 Is Not Guaranteed
Conversely, you can'= t assume that H3 will be available. A significant
fraction of networks a= lready do not pass QUIC, so if you want a
viable system it has to gracef= ully fall back to H2. I would deal with
this and the previous point by j= ust pointing at WebTransport, which
already is expected to provide both = unreliable service and fallback.


CALLING MODEL
Assuming I am = understanding this draft correctly, it does not
meaingfully support inco= ming calls to end-user devices because you
have to run a server (which e= nd-user devices will not and generally
cannot). I see you have some noti= on of having an extension for this,
but that should be provided from the= first. This seems like an odd
omission to say the least.


LAC= K OF E2E SECURITY
Your charter specifies e2e security, but AFAICT, this = is not
provided by this specification, nor is it obvious how to enhance<= br>it to provide it. Indeed, it seems like there's not any support
f= or a disjoint media path. You may recall that I made similar
comments at= the DISPATCH session in SIN, and I had understood
that it was your inte= ntion to accommodate these cases, but
I don't see anything here, whi= ch is somewhat disappointing.

I see that the charter says

&qu= ot;The protocol uses HTTP techniques for authentication and authorization(notably OAuth), and requires hop by hop encryption (i.e., https). Theprotocol will also allow for e2e media encryption, although keying is
o= ut of scope, and is expected to be handled by other protocols such as
ML= S."

I can't agree with this. If you're going to have ST= IR, then
you have what you need to provide for E2E media encryption,
= and it's a regression from WebRTC not to provide it.



DETAILED COMMENTS
I also noted some more detailed issues, as noted belo= w.

S 3.
=C2=A0 =C2=A0REQ4: The solution should hide the number of= servers behind the load
=C2=A0 =C2=A0balancer, allow the addition or re= moval of servers from the cluster
=C2=A0 =C2=A0at will, and not expose a= ny of this information to the peer

This seems like an odd requiremen= t. I'm not sure how one would even
analyze this. What about timing s= ide channels, host-ids in cookies, etc.?


S 6.
=C2=A0 =C2=A0To= ensure authenticated caller ID everywhere, the TG specifies the
=C2=A0 = =C2=A0set of allowed caller IDs through an [RFC8226] certificate.=C2=A0 Thi= s not
=C2=A0 =C2=A0only informs the client about what numbers it can ori= ginate with, it
=C2=A0 =C2=A0also proves to the client that it is capabl= e of vouching for those
=C2=A0 =C2=A0numbers.

In what way does it= prove to the client that it is capable of vouching?
Certificates are pu= blic information. Is this tied to the TLS connection
in some way?

S 8.4.
=C2=A0 =C2=A0The customer TG URI has to be reachable by the = server in order for
=C2=A0 =C2=A0the it to receive calls, and for securi= ty purposes it must also
=C2=A0 =C2=A0support TLS and present a valid do= main certificate using the same
=C2=A0 =C2=A0trust chains configured int= o browsers.

1. There is no real IETF normative definition for the tr= ust anchors
for browsers. This is a local (And browser-specific matter)<= br>
2. It's worth noting that in this design it's not clear that= you
would need to have a WebPKI valid ceritifcae.


S 8.5.
= I'm really not a fan of the handler syntax, which seems not
very fin= ished and kind of unspecified. For instance:

=C2=A0 =C2=A0"clie= ntDirectives": "1 to 1: opus;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A02 to 2: =C2=A0H264,max-width=3D1280,max-height=3D720",
Why are you using JSON and then requiring me to parse a string?

S 9.7.
Why are you inventing your own cert enrollment protocol as o= pposed
to using ACME? Now we have to analyze this protocol too.

<= br>


On Tue, Feb 18, 2020 at 7:46 AM Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
There i= s a new work effort underway to standardize an application protocol on top = of httpbis for real-time voice and video, basically replacing SIP, RTP and = SDP. This takes advantage of the usage of QUIC and UDP-based transport, tha= t makes httpbis more amenable to real-time. The current draft also makes us= e of webtransport.=C2=A0

We've got a mailer set up:<= /div>
And you can read the core draft here:

We'll be holding a BoF at IETF107 in Vancouver with the aim of = chartering a working group.=C2=A0

It would be grea= t to get participation and support from the experts in the quic community.= =C2=A0

Thx,
Jonathan R.=C2=A0=C2=A0

--
--00000000000013dd67059f3145e2-- From nobody Sat Feb 22 23:32:27 2020 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 E5D3F3A0F9A for ; Sat, 22 Feb 2020 23:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=IM1Psc01; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WFjefzKV 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 uGOzmIWja5dg for ; Sat, 22 Feb 2020 23:32:22 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B003A0F97 for ; Sat, 22 Feb 2020 23:32:22 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E292520F60 for ; Sun, 23 Feb 2020 02:32:21 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 23 Feb 2020 02:32:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=ipIEBrI1EFVXSfLin/M8ihHIkjLf6SildB59bUYm/rc=; b=IM1Psc01 NQRsKm2qIZRQ7+gujjlkD0eFSsH46bzm+S6HzlCL7/RIzhzeaIL4CJnobGmgnQIw i2b+pfRvqlspbaCoL2go94Yx1tJSx9lO1B4PAlBIUyKFeA84/UL3gZoF+xJo7OIT EH5FKFobe2kMbQSb9CUvG7TPUjqG1X/SklLCseAAWnA3LL3vfLs8YbLLwmxY2iGW mWAyWXNgaDUPe8GvR4iZ2TwmDQh4z3gw2KOC1BL/N7NdIPWc+DhQYOixEal3WNyQ 1XLBwBHs4uVtzsgjPgXEx0rgXK+KmbaXwc/Nq/hDRh7DUXuoK2nFuKpq2/PfKGha F+u22No8FHKD4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=ipIEBrI1EFVXSfLin/M8ihHIkjLf6 SildB59bUYm/rc=; b=WFjefzKVQuvUgsNjgoC4WMIu+JNsBDQugj3A/CdOh9WFi aDrQn371L4LB/W8UfRZUh+/PSwRfiXbdFijyX2RDr4cSRg8xsg6gO4JlT+bP77Cj yYRm/fTGlMJaZOtmi6GetmLvjiWXHADfS6dseuI9R0WwV2IqmdAwcayjDXANeJWW F/kD0tOJj30ZjpdNPQ9ntsCkpwn3d2Sb/b6w1YI9qMJN2nO1Q8ccvVDjBdt80RF7 y3qs67Eh25deSaLEffzzBCLR3ravqJbSl1nDkYNQfIeoN2CZHwiXq634GReMZfvj BdO9j3EyEKfM6hRLm7/lWTQBQKV9vcBNb8Vs8dk0g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeejgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphepudefrdeikedrvddvtddrudejvdenucevlhhushht vghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [13.68.220.172]) by mail.messagingengine.com (Postfix) with ESMTPA id 7D7203060BD1 for ; Sun, 23 Feb 2020 02:32:21 -0500 (EST) Content-Type: multipart/alternative; boundary="===============6731494977271228273==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: quic@ietf.org Subject: Weekly github digest (QUIC Activity Summary) Message-Id: <20200223073221.7D7203060BD1@mailuser.nyi.internal> Date: Sun, 23 Feb 2020 02:32:21 -0500 (EST) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2020 07:32:25 -0000 --===============6731494977271228273== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+5/-3/=F0=9F=92=AC45) 5 issues created: - Encrypting token in Retry packet (by nqv) https://github.com/quicwg/base-drafts/issues/3477=20 - Change max_packet_size to max_datagram_size (by kazuho) https://github.com/quicwg/base-drafts/issues/3471=20 - RTO in handshake in recovery draft (by mirjak) https://github.com/quicwg/base-drafts/issues/3467=20 - Text on migration in recovery draft seems outdated (by mirjak) https://github.com/quicwg/base-drafts/issues/3465=20 - Initial RTT for resumption (recovery draft) (by mirjak) https://github.com/quicwg/base-drafts/issues/3464=20 11 issues received 45 new comments: - #3477 Encrypting token in Retry packet (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/3477=20 - #3471 Change max_packet_size to max_datagram_size (15 by DavidSchinazi,= LPardue, ianswett, junhochoi, kazuho, martinduke, martinthomson, mikkelfj,= nibanks) https://github.com/quicwg/base-drafts/issues/3471 [-transport] [proposa= l-ready]=20 - #3467 RTO in handshake in recovery draft (1 by mirjak) https://github.com/quicwg/base-drafts/issues/3467 [-recovery]=20 - #3465 Text on migration in recovery draft seems outdated (2 by larsegge= rt, mirjak) https://github.com/quicwg/base-drafts/issues/3465 [-recovery]=20 - #3464 Initial RTT for resumption (recovery draft) (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/3464 [-recovery]=20 - #3459 Is ACK delay zero for Initial and Handshake ACK frames? (5 by ian= swett, larseggert) https://github.com/quicwg/base-drafts/issues/3459 [-recovery]=20 - #3451 Should we allow ACK-only packets to be declared lost? (4 by iansw= ett, igorlord, mikkelfj) https://github.com/quicwg/base-drafts/issues/3451 [-recovery] [design] = - #3447 max_packet_size in 0-RTT (11 by kazuho, larseggert, martinduke, m= artinthomson, nibanks) https://github.com/quicwg/base-drafts/issues/3447 [-transport]=20 - #3439 Authenticating connection IDs (1 by larseggert) https://github.com/quicwg/base-drafts/issues/3439 [-transport]=20 - #3430 It is unclear if some frames are forbidden in 0-RTT (1 by MikeBis= hop) https://github.com/quicwg/base-drafts/issues/3430 [-tls] [design]=20 - #3429 A fixed transport parameter profile is legitimate (3 by MikeBisho= p, larseggert, nharper) https://github.com/quicwg/base-drafts/issues/3429 [-transport]=20 3 issues closed: - Make transport parameter ID and length varint https://github.com/quicwg= /base-drafts/issues/3294 [-transport] [design] [has-consensus]=20 - Text on migration in recovery draft seems outdated https://github.com/q= uicwg/base-drafts/issues/3465 [-recovery]=20 - Is ACK delay zero for Initial and Handshake ACK frames? https://github.= com/quicwg/base-drafts/issues/3459 [-recovery]=20 Pull requests ------------- * quicwg/base-drafts (+7/-1/=F0=9F=92=AC17) 7 pull requests submitted: - Update reference to RFC8740 (by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/3479=20 - One of 'host' or ':authority' is required (by MikeBishop) https://github.com/quicwg/base-drafts/pull/3475 [-http] [design]=20 - renamed max_packet_size to max_udp_size (by martinduke) https://github.com/quicwg/base-drafts/pull/3473=20 - Count entire datagram for anti-amplification (by LPardue) https://github.com/quicwg/base-drafts/pull/3470=20 - Fix grammer: for indicate -> to indicate (by ghedo) https://github.com/quicwg/base-drafts/pull/3469=20 - Sending probe packet has duplicated text (by mirjak) https://github.com/quicwg/base-drafts/pull/3468=20 - Timeout handshake section in recovery draft (by mirjak) https://github.com/quicwg/base-drafts/pull/3466=20 9 pull requests received 17 new comments: - #3473 renamed max_packet_size to max_udp_size (3 by marten-seemann, mar= tinduke, mikkelfj) https://github.com/quicwg/base-drafts/pull/3473 [-transport] [design]=20 - #3469 Fix grammer: for indicate -> to indicate (1 by ghedo) https://github.com/quicwg/base-drafts/pull/3469=20 - #3468 Sending probe packet has duplicated text (3 by ianswett, mirjak) https://github.com/quicwg/base-drafts/pull/3468 [-recovery]=20 - #3463 Make congestion control more self-contained (1 by martinduke) https://github.com/quicwg/base-drafts/pull/3463 [-recovery]=20 - #3431 clarify that HANDSHAKE_DONE, NEW_TOKEN, PATH_RESPONSE, RCID frame= s MUST NOT appear in 0-RTT (1 by huitema) https://github.com/quicwg/base-drafts/pull/3431 [-tls]=20 - #3425 Remember active_connection_id_limit for 0-RTT (2 by MikeBishop, m= ikkelfj) https://github.com/quicwg/base-drafts/pull/3425 [-transport] [design]=20 - #3416 Added a word of caution before abandoning Initial packets (2 by h= uitema, martinthomson) https://github.com/quicwg/base-drafts/pull/3416=20 - #3157 Backoff on CONNECTION_CLOSE (2 by martinthomson, mikkelfj) https://github.com/quicwg/base-drafts/pull/3157 [-transport] [design]=20 - #3145 use a HANDSHAKE_DONE frame to drive the handshake to confirmation= (2 by huitema, mikkelfj) https://github.com/quicwg/base-drafts/pull/3145 [-tls] [-transport] [de= sign]=20 1 pull requests merged: - Make transport parameters varint https://github.com/quicwg/base-drafts/pull/3169 [-transport] [design]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============6731494977271228273== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Activity Summary)

Sunday February 23, 2020

Events without label "editorial"

Issues

quicwg/base-drafts (+5/-3/=F0=9F=92=AC45)

5 issues created:

11 issues received 45 new comments:

3 issues closed:

Pull requests

quicwg/base-drafts (+7/-1/=F0=9F=92=AC17)

7 pull requests submitted:

9 pull requests received 17 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============6731494977271228273==-- From nobody Mon Feb 24 07:48:28 2020 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 A8B9B3A0D8B; Mon, 24 Feb 2020 07:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFsNSin3-JZh; Mon, 24 Feb 2020 07:48:24 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 15B8C3A0D96; Mon, 24 Feb 2020 07:48:18 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id l16so7147078lfg.2; Mon, 24 Feb 2020 07:48:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mgbc9zYAEdmhBOiu05RkSboh08jIpkV6+DQahAz0ewI=; b=di1QdoOEPHH1TttieGv1BXsEX9etvWRnwd/+2kLvGySPQn3Z+osnaesUVESY0XT631 0WYYvChLX6BiHw8CT+4/DgxfYoeGIj2ipv5UtwQHpzO732WCk/Q1lkxJUHeHI8UAfW2Z 2pAv/F9Xq3TUUW+xF/TfjkksEnTYEc6aPlwD9UV3wGlDGMDkTfQIYBfHWzFDhMxC5g7M DlNX9+8dkwMvnarLY06jo0JZqPhkQdI+SZPH9qfN2FKuZZL6Vd7Z73OO0k6G4LJTHPUj x2ZDPxIY9Qi00soblWQAjYVJuWdGixWpnrU0gumhcAzSLHnsQuccANEZCv0ySnAF1pIV /dqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mgbc9zYAEdmhBOiu05RkSboh08jIpkV6+DQahAz0ewI=; b=tvEA2ozTdHcBY1FfwffjSgktxkmmb/T8GspDY2RnnrdwJSCZckiRpF0PVN746F8PK4 pMsKVthMiO2HNPqp+1ewUaz65Nzq1rlfDCRncqLdBROZLw4Nm/J5CjU6uF8VE4olLzYn UgbMVi9uRmFlWy5a/ereqwCHpsSpM/jbKoY3HI8JS2hVqfauBB2d8r7nU0Cnz64pOBXl N4YUS81hMo1vuGzTyDO3RKFFBfLf5fxNumgX67FqgnyusqY73P9m0OxNONzWEMJyUMQr UktiwgQUxS9e8RqLRYA0OfFuIttY813SwPyzeWW8ShjK4Nn7gE6BlNen4sIqWIxffUVX xU3A== X-Gm-Message-State: APjAAAUGBdINvraYQyML1IQb1KfauO2so7+vk1sUa6j/T+eO/IdXbVht ZY8GGxowJyA7P80qOlbCUKREWQleeeLSQ3oAVh7keogUXz4= X-Google-Smtp-Source: APXvYqx+yCAAoz0pD33gMsfuYz8NyzxCPMPKTwrXJbKCc3tDH2gGFfVKbuOMaNs+W1xoJ8a/ecgw3b2MYN1hlJci42Q= X-Received: by 2002:a19:ca59:: with SMTP id h25mr27858599lfj.27.1582559296182; Mon, 24 Feb 2020 07:48:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Mon, 24 Feb 2020 09:47:49 -0600 Message-ID: Subject: Re: New mailer and IETF107 BoF on RIPT - voice over httpbis/quic To: Eric Rescorla Cc: Jonathan Rosenberg , v3@ietf.org, IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000af5c52059f544c1f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 15:48:28 -0000 --000000000000af5c52059f544c1f Content-Type: text/plain; charset="UTF-8" Hi, Eric, I'm not Jonathan, or any of the proponents, but ... On Sat, Feb 22, 2020 at 4:00 PM Eric Rescorla wrote: > Jonathan, > > Thanks for sending this. > > While I think it's interesting to explore the question of how > to reinvent the real-time comms infrastructure using modern > Web-style technologies. I have a number of concerns with > the design and assumptions embodied in this draft. > > > WEB ARCHITECTURE > This document talks multiple times about how it's designed to work > with existing HTTP infrastructure and there are a number of features > of this design that seem to be dictated by that. However, it seems to > me that you are making a number of surprising (and perhaps incorrect) > assumptions about architecture and in general this seems misguided. > > - Transport Connections and HTTP Requests Need Not Fate Share There > seems to be an implicit assumption in this design that HTTP LBs have > semi-persistent routing, such that if request 1 and request 2 go to > different servers this is a "migration" event (S 8.9). This may be the > case in some architectures but it's not by any means guaranteed. The > LB is free to send every request to a different server, and Web > applications need to be designed to accommodate this.. > (see, for instance: > https://www.oreilly.com/library/view/programming-google-app/9781491900246/ch01.html > . > section The Runtime Environment). > > While this might in principle be compatible with RIPT as designed, it seems > unlikely to work well if each byway goes to a different server. > > - Use Datagrams, not Raw H3 > Relatedly, trying to simulate an unreliable channel by round-robining > a reliable set of streams is clumsy at best. For instance, in cases > where you are transmitting too quickly, you now build up a backlog > of HTTP requests which must still be (re)transmitted even though they > out of date -- and they may even be transmitted before the timely > ones. > > We already have a technology designed to provide unreliable messaging > for QUIC (https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/). > As far as I can tell, the only reason not to use it is that you > are trying to avoid making any new requirements on the server, > but I think that is a mistake because (1) as noted above, you > already are making non-standard assumptions and (2) the future > is bigger than the past, especially given the state of QUIC deployment. > I asked about this, too, in a different thread. The two things that came up were - They really do want to fate-share everything over HTTP (although you've added concerns about why that might not be a good thing), and - QUIC's recharter to include datagram support was only approved last Thursday, so there was a race condition between QUIC being chartered to do datagrams and other proposed charters that might make use of QUIC datagrams. I am hoping for continued discussion about the media story on list before the BOF, because I'd expect having this discussion during the BOF would be "more robust than we would hope". :-) Best, Spencer > - H3 Is Not Guaranteed > Conversely, you can't assume that H3 will be available. A significant > fraction of networks already do not pass QUIC, so if you want a > viable system it has to gracefully fall back to H2. I would deal with > this and the previous point by just pointing at WebTransport, which > already is expected to provide both unreliable service and fallback. > > > CALLING MODEL > Assuming I am understanding this draft correctly, it does not > meaingfully support incoming calls to end-user devices because you > have to run a server (which end-user devices will not and generally > cannot). I see you have some notion of having an extension for this, > but that should be provided from the first. This seems like an odd > omission to say the least. > > > LACK OF E2E SECURITY > Your charter specifies e2e security, but AFAICT, this is not > provided by this specification, nor is it obvious how to enhance > it to provide it. Indeed, it seems like there's not any support > for a disjoint media path. You may recall that I made similar > comments at the DISPATCH session in SIN, and I had understood > that it was your intention to accommodate these cases, but > I don't see anything here, which is somewhat disappointing. > > I see that the charter says > > "The protocol uses HTTP techniques for authentication and authorization > (notably OAuth), and requires hop by hop encryption (i.e., https). The > protocol will also allow for e2e media encryption, although keying is > out of scope, and is expected to be handled by other protocols such as > MLS." > > I can't agree with this. If you're going to have STIR, then > you have what you need to provide for E2E media encryption, > and it's a regression from WebRTC not to provide it. > > > > > DETAILED COMMENTS > I also noted some more detailed issues, as noted below. > > S 3. > REQ4: The solution should hide the number of servers behind the load > balancer, allow the addition or removal of servers from the cluster > at will, and not expose any of this information to the peer > > This seems like an odd requirement. I'm not sure how one would even > analyze this. What about timing side channels, host-ids in cookies, etc.? > > > S 6. > To ensure authenticated caller ID everywhere, the TG specifies the > set of allowed caller IDs through an [RFC8226] certificate. This not > only informs the client about what numbers it can originate with, it > also proves to the client that it is capable of vouching for those > numbers. > > In what way does it prove to the client that it is capable of vouching? > Certificates are public information. Is this tied to the TLS connection > in some way? > > > S 8.4. > The customer TG URI has to be reachable by the server in order for > the it to receive calls, and for security purposes it must also > support TLS and present a valid domain certificate using the same > trust chains configured into browsers. > > 1. There is no real IETF normative definition for the trust anchors > for browsers. This is a local (And browser-specific matter) > > 2. It's worth noting that in this design it's not clear that you > would need to have a WebPKI valid ceritifcae. > > > S 8.5. > I'm really not a fan of the handler syntax, which seems not > very finished and kind of unspecified. For instance: > > "clientDirectives": "1 to 1: opus; > 2 to 2: > H264,max-width=1280,max-height=720", > > Why are you using JSON and then requiring me to parse a string? > > > S 9.7. > Why are you inventing your own cert enrollment protocol as opposed > to using ACME? Now we have to analyze this protocol too. > > > > > > On Tue, Feb 18, 2020 at 7:46 AM Jonathan Rosenberg > wrote: > >> There is a new work effort underway to standardize an application >> protocol on top of httpbis for real-time voice and video, basically >> replacing SIP, RTP and SDP. This takes advantage of the usage of QUIC and >> UDP-based transport, that makes httpbis more amenable to real-time. The >> current draft also makes use of webtransport. >> >> We've got a mailer set up: >> https://www.ietf.org/mailman/listinfo/v3 >> >> And you can read the core draft here: >> >> https://datatracker.ietf.org/doc/draft-rosenbergjennings-dispatch-ript/?include_text=1 >> >> >> We'll be holding a BoF at IETF107 in Vancouver with the aim of chartering >> a working group. >> >> It would be great to get participation and support from the experts in >> the quic community. >> >> Thx, >> Jonathan R. >> >> -- >> Jonathan Rosenberg, Ph.D. >> jdrosen@jdrosen.net >> http://www.jdrosen.net >> > --000000000000af5c52059f544c1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Eric,=C2=A0

I'= m not Jonathan, or any of the proponents, but ...=C2=A0

On Sat, Feb 22= , 2020 at 4:00 PM Eric Rescorla <ekr@rtf= m.com> wrote:
Jonathan,

Thanks for sending this.

Whil= e I think it's interesting to explore the question of how
to reinven= t the real-time comms infrastructure using modern
Web-style technologies= . I have a number of concerns with
the design and assumptions embodied i= n this draft.


WEB ARCHITECTURE
This document talks multiple t= imes about how it's designed to work
with existing HTTP infrastructu= re and there are a number of features
of this design that seem to be dic= tated by that. However, it seems to
me that you are making a number of s= urprising (and perhaps incorrect)
assumptions about architecture and in = general this seems misguided.

- Transport Connections and HTTP Reque= sts Need Not Fate Share There
seems to be an implicit assumption in this= design that HTTP LBs have
semi-persistent routing, such that if request= 1 and request 2 go to
different servers this is a "migration"= event (S 8.9). This may be the
case in some architectures but it's = not by any means guaranteed. The
LB is free to send every request to a d= ifferent server, and Web
applications need to be designed to accommodate= this..
(see, for instance: https= ://www.oreilly.com/library/view/programming-google-app/9781491900246/ch01.h= tml.
section The Runtime Environment).

While this might in pr= inciple be compatible with RIPT as designed, it seems
unlikely to work w= ell if each byway goes to a different server.

- Use Datagrams, not R= aw H3
Relatedly, trying to simulate an unreliable channel by round-robin= ing
a reliable set of streams is clumsy at best. For instance, in cases<= br>where you are transmitting too quickly, you now build up a backlog
of= HTTP requests which must still be (re)transmitted even though they
out = of date -- and they may even be transmitted before the timely
ones.
<= br>We already have a technology designed to provide unreliable messagingfor QUIC (https://datatracker.ietf.org/doc/draft-pauly-quic= -datagram/).
As far as I can tell, the only reason not to use it is = that you
are trying to avoid making any new requirements on the server,<= br>but I think that is a mistake because (1) as noted above, you
already= are making non-standard assumptions and (2) the future
is bigger than t= he past, especially given the state of QUIC deployment.

I asked about this, too, in a different thread. The = two things that came up were=C2=A0
  • They really do want to= fate-share everything over HTTP (although you've added concerns about = why that might not be a good thing), and=C2=A0
  • QUIC's recharter= to include datagram support was only approved last Thursday, so there was = a race condition between QUIC being chartered to do datagrams and other pro= posed charters that might make use of QUIC datagrams.
I am ho= ping for continued discussion about the media story on list before the BOF,= because I'd expect having this discussion during the BOF would be &quo= t;more robust than we would hope". :-)

= Best,

Spencer
=C2=A0
- H3 Is Not Guaranteed=
Conversely, you can't assume that H3 will be available. A significa= nt
fraction of networks already do not pass QUIC, so if you want a
vi= able system it has to gracefully fall back to H2. I would deal with
this= and the previous point by just pointing at WebTransport, which
already = is expected to provide both unreliable service and fallback.


CAL= LING MODEL
Assuming I am understanding this draft correctly, it does not=
meaingfully support incoming calls to end-user devices because you
h= ave to run a server (which end-user devices will not and generally
canno= t). I see you have some notion of having an extension for this,
but that= should be provided from the first. This seems like an odd
omission to s= ay the least.


LACK OF E2E SECURITY
Your charter specifies e2e= security, but AFAICT, this is not
provided by this specification, nor i= s it obvious how to enhance
it to provide it. Indeed, it seems like ther= e's not any support
for a disjoint media path. You may recall that I= made similar
comments at the DISPATCH session in SIN, and I had underst= ood
that it was your intention to accommodate these cases, but
I don&= #39;t see anything here, which is somewhat disappointing.

I see that= the charter says

"The protocol uses HTTP techniques for authen= tication and authorization
(notably OAuth), and requires hop by hop encr= yption (i.e., https). The
protocol will also allow for e2e media encrypt= ion, although keying is
out of scope, and is expected to be handled by o= ther protocols such as
MLS."

I can't agree with this. If= you're going to have STIR, then
you have what you need to provide f= or E2E media encryption,
and it's a regression from WebRTC not to pr= ovide it.




DETAILED COMMENTS
I also noted some more de= tailed issues, as noted below.

S 3.
=C2=A0 =C2=A0REQ4: The soluti= on should hide the number of servers behind the load
=C2=A0 =C2=A0balanc= er, allow the addition or removal of servers from the cluster
=C2=A0 =C2= =A0at will, and not expose any of this information to the peer

This = seems like an odd requirement. I'm not sure how one would even
analy= ze this. What about timing side channels, host-ids in cookies, etc.?

S 6.
=C2=A0 =C2=A0To ensure authenticated caller ID everywhere, the= TG specifies the
=C2=A0 =C2=A0set of allowed caller IDs through an [RFC= 8226] certificate.=C2=A0 This not
=C2=A0 =C2=A0only informs the client a= bout what numbers it can originate with, it
=C2=A0 =C2=A0also proves to = the client that it is capable of vouching for those
=C2=A0 =C2=A0numbers= .

In what way does it prove to the client that it is capable of vouc= hing?
Certificates are public information. Is this tied to the TLS conne= ction
in some way?


S 8.4.
=C2=A0 =C2=A0The customer TG URI= has to be reachable by the server in order for
=C2=A0 =C2=A0the it to r= eceive calls, and for security purposes it must also
=C2=A0 =C2=A0suppor= t TLS and present a valid domain certificate using the same
=C2=A0 =C2= =A0trust chains configured into browsers.

1. There is no real IETF n= ormative definition for the trust anchors
for browsers. This is a local = (And browser-specific matter)

2. It's worth noting that in this = design it's not clear that you
would need to have a WebPKI valid cer= itifcae.


S 8.5.
I'm really not a fan of the handler synta= x, which seems not
very finished and kind of unspecified. For instance:<= br>
=C2=A0 =C2=A0"clientDirectives": "1 to 1: opus;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02 to 2: =C2=A0H264,max-width= =3D1280,max-height=3D720",

Why are you using JSON and then requ= iring me to parse a string?


S 9.7.
Why are you inventing your= own cert enrollment protocol as opposed
to using ACME? Now we have to a= nalyze this protocol too.





On Tue, Feb 18, 2020 at 7:46 A= M Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
There is a new work effort under= way to standardize an application protocol on top of httpbis for real-time = voice and video, basically replacing SIP, RTP and SDP. This takes advantage= of the usage of QUIC and UDP-based transport, that makes httpbis more amen= able to real-time. The current draft also makes use of webtransport.=C2=A0<= div>
We've got a mailer set up:

And you = can read the core draft here:

We'll be hold= ing a BoF at IETF107 in Vancouver with the aim of chartering a working grou= p.=C2=A0

It would be great to get participation an= d support from the experts in the quic community.=C2=A0

Thx,
Jonathan R.=C2=A0=C2=A0

--
--000000000000af5c52059f544c1f-- From nobody Mon Feb 24 09:33:40 2020 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 CF76F3A0F3F; Mon, 24 Feb 2020 09:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 gxpKuXyiKDT7; Mon, 24 Feb 2020 09:33:37 -0800 (PST) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (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 6BA893A0F32; Mon, 24 Feb 2020 09:33:37 -0800 (PST) Received: by mail-oi1-f181.google.com with SMTP id q81so9745357oig.0; Mon, 24 Feb 2020 09:33:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cld1PV0ZDuBuHHbci9qz97Vc8bmgaXaPe7vSuCS8Zd8=; b=LGIIJcRsPgAOrCe0D4XEDlBWgKgDQdQKpsY4HClsJPB7hOA9FYQ1cH00XY+pM+0y6u SXx7d+aOM9rKpa2HcDMr+JaeNJ80CEt4ML/cJ1+4rzRELC8AtPJNJA8mn1SSPWcWMCq1 F4RjgzcoDsgeNhbpRQ3Bj7Fiygp7xJsPemqpYs5uMZyIecjZgamPrU0VtIQBCyNPGT73 KmupiTG2/wt2DIyDBZyRwnxwFKWX/UKBn6TFjqrvbtO3HpFf2wpf2tWPNUZZCYUMGcvs /zGaYZRue2QIG3u7md2ACf4Qzhb5J0OTXrQpmK097Y2B9rDaFkTL4V8bgs5pA2nGfdbk DGow== X-Gm-Message-State: APjAAAW6SzBLOtaDLesyUMjeF/B+PeMiK4fCtS2BmjpNOPLWHrIoR11g Y3gyT8IDLsCtcpdDgzPvjpTsRtcp2/VUI1TgHsw= X-Google-Smtp-Source: APXvYqzSvrN5BeqM1uFTKKnnup8IPsV0bDeUSNkpbtw5+FXLqlvly4ivNPu78TicGh1xbiiOMLtafyyAiulH1MTlYTM= X-Received: by 2002:aca:4106:: with SMTP id o6mr105082oia.173.1582565616536; Mon, 24 Feb 2020 09:33:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 24 Feb 2020 12:33:25 -0500 Message-ID: Subject: Re: New mailer and IETF107 BoF on RIPT - voice over httpbis/quic To: Spencer Dawkins at IETF Cc: Eric Rescorla , Jonathan Rosenberg , IETF QUIC WG , v3@ietf.org Content-Type: multipart/alternative; boundary="00000000000068528e059f55c5d2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 17:33:39 -0000 --00000000000068528e059f55c5d2 Content-Type: text/plain; charset="UTF-8" Stepping back a bit, I think one of the reasons for the focus on HTTP is to be found in the current state of Voice/Video codecs on at the platform level. Apple, Microsoft and Google have different models which makes supporting a voice or video app on multiple platforms 'challenging' to say the least. And so if you search for information on how to code such an app, you get back a dozen hits for middleware libraries that promise to provide multi-platform support. The cause of the Iowa caucus meltdown in the US was an app provider used one of the middleware layers to build the app. The free level proved sufficient for testing but couldn't support demand on the day. IETF doesn't do APIs of course. Only that is exactly what a Web service interface is just passing parameters over wires instead of via the stack. If there is successful IETF activity in this space supported by the major platform providers, there will be a dialectic interaction with the platform APIs resulting in the emergence of a common intersection. The difference between the Web Service approach and QUIC datagram approach is the first is a reliable transport, the second is not. And that is very important when the data in a packet is time sensitive. No point in resending a lost audio packet after the listener has heard that bit. If we know the transport is lossy, we may design our compression system differently. So while I see great value in pursuing both approaches, it is clear that we want to do the lossy datagram model in the near future and that it is the harder case. Given that the real payoff here is the constraints on the APIs, I think we need to make the QUIC approach the lead. The problem here is that we are talking about 'protocol' but our negotiations are actually causing a chain of interactions with the CODEC and API people at the end of them. I think we owe it to the people at the other end of that communication to tell them the full set of what we want up front rather than in two separate stages. > --00000000000068528e059f55c5d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stepping back a bit, I think one of the reasons for the focus= on HTTP is to be found in the current state of Voice/Video codecs on at th= e platform level.=C2=A0

A= pple, Microsoft and Google have different models which=C2=A0makes supportin= g a voice or video app on multiple platforms 'challenging' to say t= he least. And so if you search for information on how to code such an app, = you get back a dozen hits for middleware libraries that promise to provide = multi-platform support.

T= he cause of the Iowa caucus meltdown in the US was an app provider used one= of the middleware layers to build the app. The free level proved sufficien= t for testing but couldn't support demand on the day.

IETF doesn't do APIs of course. Only= that is exactly what a Web service interface is just passing parameters ov= er wires instead of via the stack.

If there is successful IETF activity in this space supported by = the major platform providers, there will be a dialectic interaction with th= e platform APIs resulting in the emergence of a common intersection.
<= div class=3D"gmail_default" style=3D"font-size:small">
The difference between the Web= Service approach and QUIC datagram approach is the first is a reliable tra= nsport, the second is not. And that is very important when the data in a pa= cket is time sensitive. No point in resending a lost audio packet after the= listener has heard that bit. If we know the transport is lossy, we may des= ign our compression system differently.

So while I see great value in pursuing both approaches, it i= s clear that we want to do the lossy datagram model in the near future and = that it is the harder case. Given that the real payoff here is the constrai= nts on the APIs, I think we need to make the QUIC approach the lead.
<= div class=3D"gmail_default" style=3D"font-size:small">
The problem here is that we ar= e talking about 'protocol' but our negotiations are actually causin= g a chain of interactions with the CODEC and API people at the end of them.= I think we owe it to the people at the other end of that communication to = tell them the full set of what we want up front rather than in two separate= stages.
--00000000000068528e059f55c5d2-- From nobody Mon Feb 24 10:11:02 2020 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 9754E3A106D for ; Mon, 24 Feb 2020 10:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 JoKlVbS6MDQd for ; Mon, 24 Feb 2020 10:10:59 -0800 (PST) Received: from vs22.mail.saunalahti.fi (vs22.mail.saunalahti.fi [193.64.193.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4202F3A1065 for ; Mon, 24 Feb 2020 10:10:59 -0800 (PST) Received: from vs22.mail.saunalahti.fi (localhost [127.0.0.1]) by vs22.mail.saunalahti.fi (Postfix) with ESMTP id A5A2020320 for ; Mon, 24 Feb 2020 20:10:56 +0200 (EET) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by vs22.mail.saunalahti.fi (Postfix) with ESMTP id 9A1C0202CE for ; Mon, 24 Feb 2020 20:10:56 +0200 (EET) Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw02.mail.saunalahti.fi (Postfix) with ESMTPSA id 94DAC40004 for ; Mon, 24 Feb 2020 20:10:55 +0200 (EET) Received: from [172.20.6.81] (unknown [12.229.247.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 4F8DE681732 for ; Mon, 24 Feb 2020 20:10:51 +0200 (EET) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_A4E4CCFF-315E-4293-B413-5A9CBEFB2D90"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Doodle poll for -27 virtual interop Message-Id: <6AFDD290-2F70-4377-BB8C-691258008CE7@eggert.org> Date: Mon, 24 Feb 2020 10:10:48 -0800 To: IETF QUIC WG X-MailScanner-ID: 4F8DE681732.A65FA X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 18:11:01 -0000 --Apple-Mail=_A4E4CCFF-315E-4293-B413-5A9CBEFB2D90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, if you have a stack to test, please fill out the Doodle: = https://doodle.com/poll/9k2fpmh3r63eeiib Thanks, Lars --Apple-Mail=_A4E4CCFF-315E-4293-B413-5A9CBEFB2D90 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl5UEagACgkQVLXDCb9w wVfvQxAAmwFQTxc23xgnJxSTvlold8051w3wlrn7mwwbOKpGzgkv5Gdwz9pEZeA5 Ct6xKE9hfS6hKTFhS8979+TtyFF/p5b2Fuv/zGC2YZi+lPC+dYSQnwnA0Wv14xGT Ah6GLXwsL4PNHVOvrOTuqDDRoNteNrHho19uVVOHVGm35ljX0ssogJHXinb1S2EU Jx1hc/ACoqJt0iL+4OKrD2HKb2yVn4qAdRjXtPJ2DGz9earp9RkyOI0BLK+JysO5 gqDRILTeGBdXSBbwc52dOLryhltYiJZn92AbYXoNz8cIgySqGSlyKc/Rsz+ZZNPm HSb1zomR/mcjJzu/qU6K7qB8En0vcST9poCrB5nKE8roCMa8J17utBtbqaZPhLo/ dpiKl65OdigBoirSONbEEZGLL8Giery0quDycCeLUfgsWClEr1uRs2mQz9OIETHQ k5T00HreP6Y3QA3M8NPngaz6FHP0Mo+6ONnNwFB/czt5KaoF6G7m6rpB8utJlMnF 1yTokmL53xf4IO1gikzCFga8/QD64vBF3vj8PkiEAwYyIW/iVEm37WCi/ZosRC8V DUVBelyumz2Oqa7KPU6e5QnQMKjs7MmTXvNbQG8SE3dJ5eBzUvLKVDzTc9B9y1BA +UhMWKJfA6fUAA09jv7311ek0wDNFemBUpvQUrc6pHsJNo/XWNI= =EQdt -----END PGP SIGNATURE----- --Apple-Mail=_A4E4CCFF-315E-4293-B413-5A9CBEFB2D90-- From nobody Mon Feb 24 22:05:53 2020 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 BAA3F3A0AB5 for ; Mon, 24 Feb 2020 22:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lQ49NrHRTo_P for ; Mon, 24 Feb 2020 22:05:50 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 3869D3A0AB4 for ; Mon, 24 Feb 2020 22:05:49 -0800 (PST) Received: from xse220.mail2web.com ([66.113.196.220] helo=xse.mail2web.com) by mx128.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1j6TLj-000kcK-7X for quic@ietf.org; Tue, 25 Feb 2020 07:05:46 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 48RT1w5CB6z2XNH for ; Mon, 24 Feb 2020 22:05:40 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j6TLg-0006SC-JL for quic@ietf.org; Mon, 24 Feb 2020 22:05:40 -0800 Received: (qmail 25101 invoked from network); 25 Feb 2020 06:05:40 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.46.215]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Feb 2020 06:05:40 -0000 Subject: Draft time stamps for Quic References: <158261032173.24275.11527026977274904601.idtracker@ietfa.amsl.com> To: IETF QUIC WG From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= X-Forwarded-Message-Id: <158261032173.24275.11527026977274904601.idtracker@ietfa.amsl.com> Message-ID: <450bf28f-04a0-9bb4-e01e-471767b02e75@huitema.net> Date: Mon, 24 Feb 2020 22:05:44 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <158261032173.24275.11527026977274904601.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------BD664BD078ABB67BD9120A1B" Content-Language: en-US X-Originating-IP: 66.113.196.220 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.220/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.220/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.12) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0eYBE/I2+wvb5IJ3WTuccampSDasLI4SayDByyq9LIhVQhSODiIF8jOW i6KyGg/wnUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fuLdO8kH6z4RymlGdz7suOxU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/+iU2d2HKPwiXQ4BZ4N2yebyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilUN7TTX3qb0a 8RNcOLCOSd4jWNjicid92+JsmBTBq789MA+0pdgjwotAVkgO9+Pkz3LKYF30Y/QQcPdAd2XLfKMM 7OYFXYdC3tRq275m/U3Vxr3zVadtBino6uAg913LAbdCp3Zd9clP8wSiJZWbJCj+xRrjVmRxpGtS cvUmgj1LDNHna5NtTPfdrdVke06PXV2jZAOanSBpz6Rja2u/0jJkgauYlj7eLog+QjIOhYHVttbO qMJ/jkIfxjVNUFPEEvysta6u1iHEyuS7GD1uvcrA6Gqv4ilzFI2ibsfM/wOvJOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 06:05:52 -0000 This is a multi-part message in MIME format. --------------BD664BD078ABB67BD9120A1B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit After I submitted draft-huitema-quic-1wd-00, we started a discussion on the possibility to compose extensions. The obvious way to do that is to define a "time stamp" frame instead of modifying the ACK frame. As long as both are in the same packet, we get the same measurements. The added benefit is that time stamps could be composed with other frames too -- such as for example path responses, to measure one way delays when evaluating multiple migration options. -- Christian Huitema -------- Forwarded Message -------- Subject: New Version Notification for draft-huitema-quic-ts-00.txt Date: Mon, 24 Feb 2020 21:58:41 -0800 From: internet-drafts@ietf.org To: Christian Huitema A new version of I-D, draft-huitema-quic-ts-00.txt has been successfully submitted by Christian Huitema and posted to the IETF repository. Name: draft-huitema-quic-ts Revision: 00 Title: Quic Timestamps For Measuring One-Way Delays Document date: 2020-02-24 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-ts-00.txt Status: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/ Htmlized: https://tools.ietf.org/html/draft-huitema-quic-ts-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts Abstract: The TimeStamp frame can be added to Quic packets when one way delay measurements is useful. The timestamp is set to the number of microseconds from the beginning of the connection to the time at which the packet is sent. The draft defines the "enable_time_stamp" transport parameter for negotiating the use of this extension frame, and a new frame types for the time_stamped frame. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------BD664BD078ABB67BD9120A1B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

After I submitted draft-huitema-quic-1wd-00, we started a discussion on the possibility to compose extensions. The obvious way to do that is to define a "time stamp" frame instead of modifying the ACK frame. As long as both are in the same packet, we get the same measurements. The added benefit is that time stamps could be composed with other frames too -- such as for example path responses, to measure one way delays when evaluating multiple migration options.

-- Christian Huitema



-------- Forwarded Message --------
Subject: New Version Notification for draft-huitema-quic-ts-00.txt
Date: Mon, 24 Feb 2020 21:58:41 -0800
From: internet-drafts@ietf.org
To: Christian Huitema <huitema@huitema.net>



A new version of I-D, draft-huitema-quic-ts-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name: draft-huitema-quic-ts
Revision: 00
Title: Quic Timestamps For Measuring One-Way Delays
Document date: 2020-02-24
Group: Individual Submission
Pages: 6
URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-ts-00.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/
Htmlized: https://tools.ietf.org/html/draft-huitema-quic-ts-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts


Abstract:
The TimeStamp frame can be added to Quic packets when one way delay
measurements is useful. The timestamp is set to the number of
microseconds from the beginning of the connection to the time at
which the packet is sent. The draft defines the "enable_time_stamp"
transport parameter for negotiating the use of this extension frame,
and a new frame types for the time_stamped frame.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------BD664BD078ABB67BD9120A1B-- From nobody Tue Feb 25 05:30:19 2020 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 23FBC3A0CA5 for ; Tue, 25 Feb 2020 05:30:18 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-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 DnaqFlFgRW9G for ; Tue, 25 Feb 2020 05:30:16 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 587023A0CA8 for ; Tue, 25 Feb 2020 05:30:16 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id m9so6646666qke.4 for ; Tue, 25 Feb 2020 05:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=x3cgTOZ930YmoorZsiTRSmdjp1XL+KxBWj75/JPbbqQ=; b=YeZRiwsMH4oQfe5tkDRncj4c6/5i+UgxqaZJXJzLF+enjx+pLa//GiWGhJ1WBZhxLA 03HPAWnXUEEu0H2NG25CuWIGAaI9+eBaoKaRdOmKvQ4BQZlPsx6cPOZQTkhfjhN473be DsxQ5ODwPL0seGT8j2Wr/T7fME/wSzivOR1hXHqTQkziWI29Q7YqTCOj0t2A12bzGzsc xXkXsb8Zn+UJsQ0N6Pcx5eJr2OamG3mRpzidH5FtPlqYjbrCpcDTOnUDe5uL0XUjk/qg E14Yk+XIgB4POHrxS8JGGpz1ikz/7cIm8OXrwyNVebwwY9doBP5wLUGiRlof4qyoiIdm bmLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=x3cgTOZ930YmoorZsiTRSmdjp1XL+KxBWj75/JPbbqQ=; b=JMpUAUFY0yUwfNl12/xmCsM6DHv8hPOI07rxgYpkadh2w55SWQAU0W0xrSb8vT7SOV TOzTuQc5fxmq5o7zO0XzGSrjH/sH/zA4lZ5yu3pjmI2+JEALYlKNu2lPllwGP3xD6iia JAVZXKFCJoO1TauodkDqYltqIbgdrZvEyr7XIo7D85rSjzCF3Ugi5m7URVdJqvcIa8Ro wlkFzG/x1gl5ZWWcPm65WwID4yze1gnNv90Hrb/k/L/B+CUc7uRVZRxX34i1MQ6REb3B 5350qB4My1GcBCtmxgBuaIABHNIDC/zZe3hhLJzn5dlCJOC26VmD1IWehhrXhceoypUz Rrtw== X-Gm-Message-State: APjAAAWB9X93F/AGmjXVOchCKCwZfvTL6DOiyI0NPwMDTOmz0XG9bV1S 2xvOvpwq1/8QSGX692fVuLpt8s2eq6o= X-Google-Smtp-Source: APXvYqxCNwYfvbuhMjDCPKymMyZ4HPNS4MLH8wuritqOklii1kz1cVieoCSBPe8o3Y24wpyhxMmAOQ== X-Received: by 2002:ae9:dc82:: with SMTP id q124mr56159340qkf.20.1582637415248; Tue, 25 Feb 2020 05:30:15 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id w53sm7568648qtb.91.2020.02.25.05.30.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 05:30:14 -0800 (PST) Date: Tue, 25 Feb 2020 08:30:09 -0500 From: Dmitri Tikhonov To: Christian Huitema Cc: IETF QUIC WG Subject: Re: Draft time stamps for Quic Message-ID: <20200225133008.GA6299@ubuntu-dmitri> Mail-Followup-To: Christian Huitema , IETF QUIC WG References: <158261032173.24275.11527026977274904601.idtracker@ietfa.amsl.com> <450bf28f-04a0-9bb4-e01e-471767b02e75@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450bf28f-04a0-9bb4-e01e-471767b02e75@huitema.net> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 13:30:18 -0000 Great, this is a much lower barrier to entry than modifying the ACK frame! How is "the beginning of the connection" defined? Is it as follows: - for the client, the time when the first Initial packet is sent; - for the server, the time when the first Initial packet is received. - Dmitri. On Mon, Feb 24, 2020 at 10:05:44PM -0800, Christian Huitema wrote: > After I submitted draft-huitema-quic-1wd-00, we started a discussion on > the possibility to compose extensions. The obvious way to do that is to > define a "time stamp" frame instead of modifying the ACK frame. As long > as both are in the same packet, we get the same measurements. The added > benefit is that time stamps could be composed with other frames too -- > such as for example path responses, to measure one way delays when > evaluating multiple migration options. > > -- Christian Huitema > > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-huitema-quic-ts-00.txt > Date: Mon, 24 Feb 2020 21:58:41 -0800 > From: internet-drafts@ietf.org > To: Christian Huitema > > > > > A new version of I-D, draft-huitema-quic-ts-00.txt > has been successfully submitted by Christian Huitema and posted to the > IETF repository. > > Name: draft-huitema-quic-ts > Revision: 00 > Title: Quic Timestamps For Measuring One-Way Delays > Document date: 2020-02-24 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-ts-00.txt > Status: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/ > Htmlized: https://tools.ietf.org/html/draft-huitema-quic-ts-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts > > > Abstract: > The TimeStamp frame can be added to Quic packets when one way delay > measurements is useful. The timestamp is set to the number of > microseconds from the beginning of the connection to the time at > which the packet is sent. The draft defines the "enable_time_stamp" > transport parameter for negotiating the use of this extension frame, > and a new frame types for the time_stamped frame. > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > From nobody Tue Feb 25 20:47:44 2020 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 49EC53A0CCE for ; Tue, 25 Feb 2020 20:47:42 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cCWJtryM3yKO for ; Tue, 25 Feb 2020 20:47:40 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 C58813A0CCD for ; Tue, 25 Feb 2020 20:47:40 -0800 (PST) Received: from xse60.mail2web.com ([66.113.196.60] helo=xse.mail2web.com) by mx171.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1j6obf-000MQ9-Ri for quic@ietf.org; Wed, 26 Feb 2020 05:47:39 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 48S3FJ59fPz2WM2 for ; Tue, 25 Feb 2020 20:47:32 -0800 (PST) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j6obc-0008E1-JD for quic@ietf.org; Tue, 25 Feb 2020 20:47:32 -0800 Received: (qmail 21167 invoked from network); 26 Feb 2020 04:47:32 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.46.215]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Feb 2020 04:47:32 -0000 Subject: Re: Draft time stamps for Quic To: IETF QUIC WG References: <158261032173.24275.11527026977274904601.idtracker@ietfa.amsl.com> <450bf28f-04a0-9bb4-e01e-471767b02e75@huitema.net> <20200225133008.GA6299@ubuntu-dmitri> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <578be67e-ea78-d877-0095-efacbe74b24c@huitema.net> Date: Tue, 25 Feb 2020 20:47:37 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200225133008.GA6299@ubuntu-dmitri> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.196.60 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.60/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.60/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.07) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0eYBE/I2+wvb5IJ3WTuccampSDasLI4SayDByyq9LIhVM/+H01u2KbPH ceZeNtdAPkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fsI24wRQH6FdHXy2CShsJwNU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/LHHzVgerlcwIzWVlPFsIHryme9ldZJ7uNXfg/GfS8fXOC4kn OJkMS8NGDKsP9r3Khy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8aLQTd0uGdLjEYAAeLKuG0y4nuZrRf7bMi0WRR6pZ+nWYd6p15IU/vXOVtWU/LyOG8z 7Vu2PZFHkJEE/wqpNG6e4Kd7ATHraBGtSYFadRmJAWkvZ+pWP1s35neRYWMQUWZErSs0X3oyoTc8 j/o7qulxwq3HhwaWtFl+kb7VyiAW2VACVO3tx78u0bG7If2TCVT6knv7l4qVbpyeEewmOMtRM66Q jdMiupezl+THVvV68FffncYFDRVcOLM39ai6q8s8w89zus4lM6F2bKyAeNaHJOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 04:47:43 -0000 On 2/25/2020 5:30 AM, Dmitri Tikhonov wrote: > Great, this is a much lower barrier to entry than modifying the ACK > frame! I am still a bit saddened by the increased overhead, but if that's the price of interop... > > How is "the beginning of the connection" defined? Is it as follows: > > - for the client, the time when the first Initial packet > is sent; > - for the server, the time when the first Initial packet > is received. Yes. Will add that text in the next revision. -- Christian Huitema > On Mon, Feb 24, 2020 at 10:05:44PM -0800, Christian Huitema wrote: >> After I submitted draft-huitema-quic-1wd-00, we started a discussion on >> the possibility to compose extensions. The obvious way to do that is to >> define a "time stamp" frame instead of modifying the ACK frame. As long >> as both are in the same packet, we get the same measurements. The added >> benefit is that time stamps could be composed with other frames too -- >> such as for example path responses, to measure one way delays when >> evaluating multiple migration options. >> >> -- Christian Huitema >> >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-huitema-quic-ts-00.txt >> Date: Mon, 24 Feb 2020 21:58:41 -0800 >> From: internet-drafts@ietf.org >> To: Christian Huitema >> >> >> >> >> A new version of I-D, draft-huitema-quic-ts-00.txt >> has been successfully submitted by Christian Huitema and posted to the >> IETF repository. >> >> Name: draft-huitema-quic-ts >> Revision: 00 >> Title: Quic Timestamps For Measuring One-Way Delays >> Document date: 2020-02-24 >> Group: Individual Submission >> Pages: 6 >> URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-ts-00.txt >> Status: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/ >> Htmlized: https://tools.ietf.org/html/draft-huitema-quic-ts-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts >> >> >> Abstract: >> The TimeStamp frame can be added to Quic packets when one way delay >> measurements is useful. The timestamp is set to the number of >> microseconds from the beginning of the connection to the time at >> which the packet is sent. The draft defines the "enable_time_stamp" >> transport parameter for negotiating the use of this extension frame, >> and a new frame types for the time_stamped frame. >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> From nobody Tue Feb 25 21:19:21 2020 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 BB9C93A0D7D for ; Tue, 25 Feb 2020 21:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 SGv6vJZ3TCJd for ; Tue, 25 Feb 2020 21:19:19 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 8ED003A0D77 for ; Tue, 25 Feb 2020 21:19:19 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id c23so960361lfi.7 for ; Tue, 25 Feb 2020 21:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Boo9G6pNxq5RUwYdrpDNF9FkiwM861ti/d5RUK1jVsQ=; b=s/+gzU1srMTNbTGWPTq6hGKCPUqtdIbixH4TCSasEnM6LPpwjOl2V/5Uk5o4PRDuz1 n7AjwDM6v1GXXfK3hwD9o88yuYJPlqUSU0jz63o1QI4ydxqBVrGAGelTHuNtJI7/RuR7 xxXLJq5eWHRyk3wEfQ0w0nFpWdV/hyn3u0Crg3MJIY6u/EpmMLaoE8uBD8U6IqUnR4qm 4h7b6Z+A8B8/2GJaguL5r+g9wTLaLzrxnkCevSLFtETiYywRtmwp8foXtrOFjjmoKzX9 HIw0bKAlYIrlfUiKAiWeYUtdZ3ojg2r3q8tkDrWQ8dMwcqZyfJWyabxSzD5qbHho5qAW 5TfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Boo9G6pNxq5RUwYdrpDNF9FkiwM861ti/d5RUK1jVsQ=; b=YDryR4Rwb+ZXhF/b+T3WE1ZX/V1Y6tM3kA1ztntono6FOD5nb9Nhauu3zktjGEQk+h 8tj0KRf4V7xVS6P6ICLe9R7OgrNzUgVX9xEE9Tz8GqzP5ph2cBhCWl+vblmawzMnylVH kTqtQO/930OYsNV7VprlKZ9fTl+vLzQOuYw/BJvApYSOC59HhbvOeMvU1+wDgItNj+8v QLFGfDYq3ae0ZJiMiurZOZgEgFaTxkE5gtyjN/ZdAHOg3/yD2rpaMOyGFsV9BV4ZMJGu glhzCpiLvffvVBHa/c6wEJg4ZLw0sEqbgxmA+xwM4+WMwqRIF+l5NseXiXV64KoNBqra pFcw== X-Gm-Message-State: APjAAAX+SCxst/PPZSOjiNQ9OqjYVQu0W2An0e19/0S0YXCK9dq5q/7J gjj1ONXJJau+awMzcHC23F/KVlELhRajdIaFBbuHxZU2 X-Google-Smtp-Source: APXvYqwrDtcl1PVHD93R+OdvllCE2n9KWXluLheSzvdJgCqtLLUul6UOUBIYVH2xnZWWJGzu84CUtlLXRUOcBuyz1eQ= X-Received: by 2002:a05:6512:6c7:: with SMTP id u7mr1388854lff.176.1582694357448; Tue, 25 Feb 2020 21:19:17 -0800 (PST) MIME-Version: 1.0 References: <158261032173.24275.11527026977274904601.idtracker@ietfa.amsl.com> <450bf28f-04a0-9bb4-e01e-471767b02e75@huitema.net> In-Reply-To: <450bf28f-04a0-9bb4-e01e-471767b02e75@huitema.net> From: Watson Ladd Date: Tue, 25 Feb 2020 21:19:06 -0800 Message-ID: Subject: Re: Draft time stamps for Quic To: Christian Huitema Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 05:19:21 -0000 So I was under the impression that one cannot determine whether asymmetric delay or clock skew is the problem between two machines. There are as many variables as unknowns. At best you can determine if the one way delay is changing on a leg. Having spent a good part of the last month on a project that would be much simpler if that wasn't case I'd be happy to know I was wrong. Sincerely, Watson From nobody Tue Feb 25 22:58:15 2020 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 CDE213A0F1F for ; Tue, 25 Feb 2020 22:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 t_09p369sIeQ for ; Tue, 25 Feb 2020 22:58:12 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 4DC553A0F1E for ; Tue, 25 Feb 2020 22:58:12 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id e8so1556743wrm.5 for ; Tue, 25 Feb 2020 22:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=69Y1FFr/6jCMPuwwFnzTguJoQjUWx8bo5QpJcZbz+1E=; b=UvOhAxSOOiYPikldqNMHojLRlcBxM2ICcxR430t5Y+BDpiiF/gg5SalidW2EQwky9n DfwdNu1CbCpQ1nGblepKyean8LnZ1/OkIgrHyic7Y49iqULdHAsbLXTzNDEk7v9eQfko 01fpPZJuxNNtP7GaoUQcw5MM5mTB6oY/IDnq5YGOKQjBRpJ2o+m+EOkYCzi9YAg48p+C eQtMtzCtxYXOYasACtzAnY5VrdVznT6NVqckL+U5XCmrtnvVpuEYgHZGLCY0OHD3c3cf Hb/UuyGelZ7cqfTZr33YO3Cr7gqUTQoOUQkqz4mzL0duKwW3J+iacS68Ia3hlOlGHzkz curw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=69Y1FFr/6jCMPuwwFnzTguJoQjUWx8bo5QpJcZbz+1E=; b=Rt4dEcYHDQK9AN9qpGjTyb7sgfah2OZclptbGpBw6n/JiifCl/KvBmg9mxiz+imZya RYwT2Jb16bk4gjDFMfEPvHJ2YZPp8LDn0hLGJmkn0O4uVnFo0N1bLNju7NXqwMMzQmme 4WkBEJS7NNWfCFG4RS9u98/3kb9KdRo26uweXbGbPWQYDE0agRD2uHET0haAHQZhenvF lSnlXSz7sjbs+0dhwTvKWudCa9UsVKylCP1KVnJlfAymor5X6/W4Z//6i1f88XAfw4r3 YhdENaH+wqheMQW45wQhyrCVTfNlQEQGsjnfGbdV/ks/YGFR+XHP8lSCiwMOjg+K11FU khVw== X-Gm-Message-State: APjAAAWbbBbfz9Cne1+gOYh+AK9zYKowLZXqSWVF/UZ/l94EAycpZII9 nA3cyX0gXyq4nV9Wbbjkluho3IO5HI6y5SFLo/cjDSeYP1c= X-Google-Smtp-Source: APXvYqw9XetPpIrA0t9wnmdB1WbPULsRuonYS3GygwVtph/yXTyLCZy1onogWJDRR3SKQU+hVQOeNTAsIdj7mqSu4N0= X-Received: by 2002:adf:f588:: with SMTP id f8mr3718916wro.188.1582700290745; Tue, 25 Feb 2020 22:58:10 -0800 (PST) MIME-Version: 1.0 References: <158261032173.24275.11527026977274904601.idtracker@ietfa.amsl.com> <450bf28f-04a0-9bb4-e01e-471767b02e75@huitema.net> In-Reply-To: From: Tal Mizrahi Date: Wed, 26 Feb 2020 08:57:59 +0200 Message-ID: Subject: Re: Draft time stamps for Quic To: Christian Huitema Cc: IETF QUIC WG , Watson Ladd Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 06:58:14 -0000 Hi Christian, Thanks for putting this draft together. Two aspects that may be worth a bit more consideration: - One-way-delay measurement requires the endpoints to be synchronized. Since the epoch that was chosen in this draft is the beginning of the connection, endpoints need to be synchronized about the beginning time of the connection. The draft suggests to synchronize the beginning of the connection by measuring the "phase_shift" value. Using "latest_rtt/2" for the phase_shift calculation seems to assume that the delay is symmetric. I agree with Watson's comment about symmetry - if the path is asymmetric all the measurements will be biased. - "We understand that clocks may drift over time, and that simply estimating a phase shift at the beginning of a connection may be too simplistic" - this is an important issue. It is not uncommon for PC clocks to drift by 1 millisecond (or more) per minute. Accurate measurement will probably require a more accurate synchronization mechanism. Cheers, Tal. On Wed, Feb 26, 2020 at 7:19 AM Watson Ladd wrote: > > So I was under the impression that one cannot determine whether > asymmetric delay or clock skew is the problem between two machines. > There are as many variables as unknowns. At best you can determine if > the one way delay is changing on a leg. Having spent a good part of > the last month on a project that would be much simpler if that wasn't > case I'd be happy to know I was wrong. > > Sincerely, > Watson > From nobody Wed Feb 26 10:30:44 2020 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 EB7863A0FF1 for ; Wed, 26 Feb 2020 10:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.1 X-Spam-Level: *** X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 6cEoJY7NCcmI for ; Wed, 26 Feb 2020 10:30:40 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 9EF633A0FE0 for ; Wed, 26 Feb 2020 10:30:40 -0800 (PST) Received: from xse337.mail2web.com ([66.113.197.83] helo=xse.mail2web.com) by mx170.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1j71S8-000gLE-FZ for quic@ietf.org; Wed, 26 Feb 2020 19:30:39 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 48SPVz1JmFz3F7n for ; Wed, 26 Feb 2020 10:30:35 -0800 (PST) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j71S7-0006TD-1f for quic@ietf.org; Wed, 26 Feb 2020 10:30:35 -0800 Received: (qmail 29830 invoked from network); 26 Feb 2020 18:30:34 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.46.215]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Feb 2020 18:30:34 -0000 To: Tal Mizrahi Cc: Watson Ladd , IETF QUIC WG References: <158261032173.24275.11527026977274904601.idtracker@ietfa.amsl.com> <450bf28f-04a0-9bb4-e01e-471767b02e75@huitema.net> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Subject: Re: Draft time stamps for Quic Message-ID: <8098e44e-9da5-a06f-5a5a-700c93c39b07@huitema.net> Date: Wed, 26 Feb 2020 10:30:40 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.197.83 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.57) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0eYBE/I2+wvb5IJ3WTuccampSDasLI4SayDByyq9LIhV89k5nzH8k0ZD vqAVugDlF0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fuRHWr7A+EynNCnG2HBRcvEU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/0w0RB5vhZeNQMVT8ptSkfLyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilQ8EW2aDkYIa 2M5pALviQranAWRfft7O67lvSj/BJ2SQyO1CVdwacjPFtr9P+qIQ+xdQrxFKHkFWyhG/+tBAXf8x iMxSpkvqIEtRL3s4ePxvne6Agjui5gKB/Byw/yqfyPKY2AXNZGS5G93aGyH8MqMlOQRMVMd0HCeT skOZ5TL8IEl/jIHf70OsXiZH3JXNEjXg724gFzhHYUe+7aKm0vWbXNgyPQiGIDHzweHL3K7xTi+J 2sBvM/O0p+zizleC4lU8fDj1CnRx+r4b/1Q/PZ+ENDYrOiHaCOrRDMD3bFikvOnCUbNPgcPcQwzM gKHyQxUo+ql2ySTkvEFH/23XMww2BnTTFGX5/yI4Ky+1ZJcbGqc5H4PEZHeoI/d6LWFf332z7LMw LGdoi9FMQ5j9dQUvMi1YKAun15JQSJLyCT5k+MTObVKxHy/dols381l9r9ft9daDonlwd6LnuX+J u10= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 18:30:42 -0000 Tal, you and Watson are making good points. The draft is probably missing a section discussing the issues of time synchronization. Here is something I could write: There is a two known issues with deducing one way delays from RTT measurements: clock drift and undefined phase difference. The phase difference problem is easy to understand. We start from a list of measurements associating the send time of packet number x (s[x]), the receive time of the acknowledgement of packet (a[x]), and the time stamp indicating when packet x was received by the peer (p[x]). The peer's time stamp are expressed in the peer's clock.=C2=A0 Suppose that we model the peer's clock as local time plus phase difference f, and that we model the rtt as the sum of two one way delays, up (u[x]) and down (d[x]). We get: =C2=A0=C2=A0=C2=A0 u[x] =3D p[x] + f - s[x] =C2=A0=C2=A0=C2=A0 d[x] =3D a[x] - p[x] - f Just looking at the equation shows that the value of f cannot be determined from the a series of measurement (s[x], a[x], p[x]). You can just add constraints that all u[x] and d[x] are positive numbers, which gives a range of plausible values for f:=C2=A0=C2=A0 max(s[x] - p[x]) < f= < min(a[x]-p[x]). In case you wonder, you get similar formulations in a multipath scenario. The plausible range may narrow to the min rtt of the shortest path, but no further. The phase difference uncertainty is not a big issue in practice, because control algorithms are much more interested in the variations of the delays than by their absolute values. Suppose we want to compare one way delays at measurement (x) and (y). we get: =C2=A0=C2=A0=C2=A0 u[x] =3D p[x] + f - s[x] =C2=A0=C2=A0=C2=A0 u[y] =3D p[y] + f - s[y] =C2=A0=C2=A0=C2=A0 u[x] - u[y] =3D p[x] - p[y] - s[x] + s[y] The phase difference does not affect the measurement of deltas. The clock drift is another matter. All the equations above assume that the local clock and the remote clock have the same frequency. This is an approximation. Clocks drift over time. Instead of just considering a stable phase difference, one should consider the sum of a phase difference and a time-varying drift component. Estimating drift is a complex problem. This was studied in detail in the development of the network time protocol (NTP) (RFC 5905). In theory, implementations of Quic could copy the algorithms of NTP to build a model of the clocks used by the local node and the peer. That would be very complex. Hopefully, implementations of Quic no not need to implement something as complex as NTP. Most time based algorithms are only interested in variations of delays over a short horizon. Clock drift happens at a slow pace, maybe 1 millisecond per minute. Algorithms like BBR or LEDBAT already have to cope with the potential drift of the minimum RTT due to changing network conditions. They do that by periodically restarting the measurement of the minimum RTT after some delay, typically less than a minute. A simple implementation of one way delay measurements could follow the same approach, for example resetting the phase difference very 30 seconds or so. On 2/25/2020 10:57 PM, Tal Mizrahi wrote: > Hi Christian, > > Thanks for putting this draft together. > > Two aspects that may be worth a bit more consideration: > - One-way-delay measurement requires the endpoints to be synchronized. > Since the epoch that was chosen in this draft is the beginning of the > connection, endpoints need to be synchronized about the beginning time > of the connection. The draft suggests to synchronize the beginning of > the connection by measuring the "phase_shift" value. Using > "latest_rtt/2" for the phase_shift calculation seems to assume that > the delay is symmetric. I agree with Watson's comment about symmetry - > if the path is asymmetric all the measurements will be biased. > - "We understand that clocks may drift over time, and that simply > estimating a phase shift at the beginning of a connection may be too > simplistic" - this is an important issue. It is not uncommon for PC > clocks to drift by 1 millisecond (or more) per minute. Accurate > measurement will probably require a more accurate synchronization > mechanism. > > Cheers, > Tal. > > On Wed, Feb 26, 2020 at 7:19 AM Watson Ladd wro= te: >> So I was under the impression that one cannot determine whether >> asymmetric delay or clock skew is the problem between two machines. >> There are as many variables as unknowns. At best you can determine if >> the one way delay is changing on a leg. Having spent a good part of >> the last month on a project that would be much simpler if that wasn't >> case I'd be happy to know I was wrong. >> >> Sincerely, >> Watson >> From nobody Wed Feb 26 11:41:26 2020 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 29ED83A11DE for ; Wed, 26 Feb 2020 11:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHDpkURdJk8g for ; Wed, 26 Feb 2020 11:41:20 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 4ABF23A115C for ; Wed, 26 Feb 2020 11:41:20 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id w12so239443wrt.2 for ; Wed, 26 Feb 2020 11:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TkD8ijwLvomdatUaLQdr/Dcapg5JplOA8FEBvvEu4Tc=; b=ghB8sjcGkD2DJ2YPp8MSE5d1DyUrmQ8JojJKW2xOP0UhIJ5O2w+vebJeF/DIkiDV5h kbk6qr2OfjHaBzcyxF8av6atVnKnHgzEfJp1aYUJ29+NN4DxoyJlL/u+y2/HHiY8qazr imNOF7PjQKEqXDA65m45HDr4+KJA7PpFgPC9t71+dgBgBdVbmkL8AK81FKl2pWcPTulj CBdSy0AVmOx87GSMYePHjkosqU8HJu8Yffc3Acjj75y6RQstgU3Fi58wxLbX8D51ABpU 7Igtumc2Ph7mKvNXAT9xLjG7IGuXFPs00J5adiVtK2dILMTKcBGZ9Af36LznMibUf3L9 aMGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TkD8ijwLvomdatUaLQdr/Dcapg5JplOA8FEBvvEu4Tc=; b=jZ4Bh70L60vhQWZ/nJDN0w2o6r/cbTVcDep4ZbfZHk+cQWBBDqbvwf2hvOETMDawe2 o9e2UD4r9zbdT/twFh1kDThtsnB6Q/63BpaKIaBUz9EmasPkfgPKYtBdy52/5xJsQ6lX 8L+4SShLgsOpNO3nDW0cXIz/QpJQiPoGrdEmIV4NjSH61dhPxiv75CceJnkCyLg6Jkej 1xzDvKMkM+bYyfhRGwxHJ0VxfQJ2SzHgpAwlldfaS9opc9ZFg1K/uJ1Eg8HidCsn7daG oe5ryD2MSTZK5SLDUBzNHZm+3l2R7jHs/FoznzLS7ABhWHfw8FkI/j3i2jmqMJUA/kZ2 kROg== X-Gm-Message-State: APjAAAXPj5cy5/ts7O2Emn0Hggkyv2nxfkv1lpd3KRD21d5jFMA1amlw Ldwns2jU3ptGD2fovVE4gXDa+6VDCtBoeQb7RQ8= X-Google-Smtp-Source: APXvYqz7GWS1+/HCy20fSBtsjYNI3fmEfBM+d9TNALYbXzzQS43PBeCpI5C4fFxkMomN722V7drPTrjXZDerwDQvAC8= X-Received: by 2002:adf:f3cc:: with SMTP id g12mr247925wrp.236.1582746078644; Wed, 26 Feb 2020 11:41:18 -0800 (PST) MIME-Version: 1.0 References: <20200107143114.GC14229@ubuntu-dmitri> In-Reply-To: From: Lucas Pardue Date: Wed, 26 Feb 2020 19:41:07 +0000 Message-ID: Subject: Re: Add extension work to Interop matrix To: Lars Eggert Cc: Dmitri Tikhonov , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000c98da8059f7fc941" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 19:41:22 -0000 --000000000000c98da8059f7fc941 Content-Type: text/plain; charset="UTF-8" To close the loop on this thread. We had some more discussion during the Zurich interim meeting and I took an action to set up a separate extensions interop matrix. I've added a wiki page for QUIC extension, this is open to adopted and non-adopted extensions: https://github.com/quicwg/base-drafts/wiki/QUIC-Extensions-Interop. The page contains a table of letters to be used to record interop results in the extensions matrix. Letters can be reserved on a first-come, first-served basis but please do consider your neighbours. The extensions interop matrix lives in a new Google docs spreadsheet that uses purple conditional formatting - https://docs.google.com/spreadsheets/d/1Ygbit9UySHLMBT8FNgIIqRt2PVo1J9HLJ-yIpfjE374 Cheers Lucas On Wed, Jan 8, 2020 at 12:28 PM Lars Eggert wrote: > Hi, > > On 2020-1-7, at 16:31, Dmitri Tikhonov > wrote: > > There are now a few extensions that have been proposed and implemented. > > We should add them to the next Interop matrix. > > maybe we should add a fourth row for extensions? > > I'm with Lucas on that I'd like to keep the sheet focused on protocol > features (and now possibly extensions) that have seen WG adoption. The > rough idea is that unless we believe that the majority of implementations > are going to implement something, it's probably not worthwhile adding it to > the sheet. > > Lars > --000000000000c98da8059f7fc941 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To close the loop on this thread. We had some more di= scussion during the Zurich interim meeting and I took an action to set up a= separate extensions interop matrix.=C2=A0

I've added a wiki page for QUIC extension, this is open= to adopted and non-adopted extensions:=C2=A0 https://github.com/quicwg/base-drafts/wiki/QUIC-Extensions-Interop.= The page contains a table of letters to be used to record interop results = in the extensions matrix. Letters can be reserved on a first-come, first-se= rved basis but please do consider your neighbours.=C2=A0
The extensions interop matrix lives in a new Google docs spreads= heet that uses purple conditional formatting - https:/= /docs.google.com/spreadsheets/d/1Ygbit9UySHLMBT8FNgIIqRt2PVo1J9HLJ-yIpfjE37= 4

Cheers
Lucas
On Wed, = Jan 8, 2020 at 12:28 PM Lars Eggert <= lars@eggert.org> wrote:
Hi,

On 2020-1-7, at 16:31, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:=
> There are now a few extensions that have been proposed and implemented= .
> We should add them to the next Interop matrix.

maybe we should add a fourth row for extensions?

I'm with Lucas on that I'd like to keep the sheet focused on protoc= ol features (and now possibly extensions) that have seen WG adoption. The r= ough idea is that unless we believe that the majority of implementations ar= e going to implement something, it's probably not worthwhile adding it = to the sheet.

Lars
--000000000000c98da8059f7fc941-- From nobody Wed Feb 26 12:14:37 2020 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 7FA663A134E for ; Wed, 26 Feb 2020 12:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tRysTZ6SSWqr for ; Wed, 26 Feb 2020 12:14:33 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 915403A1346 for ; Wed, 26 Feb 2020 12:14:33 -0800 (PST) Received: from xse455.mail2web.com ([66.113.197.201] helo=xse.mail2web.com) by mx148.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1j734c-0014rI-73 for quic@ietf.org; Wed, 26 Feb 2020 21:14:28 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 48SRpl5q85z2BMM for ; Wed, 26 Feb 2020 12:14:23 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j734Z-0007qq-MA for quic@ietf.org; Wed, 26 Feb 2020 12:14:23 -0800 Received: (qmail 10379 invoked from network); 26 Feb 2020 20:14:23 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.43.103]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Feb 2020 20:14:22 -0000 Subject: Re: Add extension work to Interop matrix To: Lucas Pardue , Lars Eggert Cc: IETF QUIC WG , Dmitri Tikhonov References: <20200107143114.GC14229@ubuntu-dmitri> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <5242d630-d923-311e-35c9-94f854b0c929@huitema.net> Date: Wed, 26 Feb 2020 12:14:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E50D5D5BCEC3AA3D94E53513" Content-Language: en-US X-Originating-IP: 66.113.197.201 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0eYBE/I2+wvb5IJ3WTuccampSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59ftlW9ESyC8Pm3DB9nlTVZGvU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/ixIHpNwYH6dG/jiqllt/T7yme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ileOfMnQTuxRu w7b3K/aRb5giOkRUjEC1NmIIFZ+le16ml1Fm8daViNS7T6cFptmPfhzjQgYg+T/hOwQ/MRaS6Sl8 g2fGU86cSswil+kDetUfttbLHdNhiUq2jBEvMVLlZ4GThCScvU0cCIiHSQbmcVIihC4jb+HDhBqY /RXkNv1jY4NhlpOo+XFzBzK20cyXxrdZfQmBPxzn/NeU33EfPBf5JFvSW1NuqJeLuzmLfBnLXPWl FdaGOH191uXjgjQN/RTaYTLUj/RFhcnr3Qktcdi4JMs0yemlR/l6Uv8YKaym1vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 20:14:36 -0000 This is a multi-part message in MIME format. --------------E50D5D5BCEC3AA3D94E53513 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Two suggestions: 1) Move from draft-25 to draft-27 2) Add "d" for datagram, specify siduck as test tool. On 2/26/2020 11:41 AM, Lucas Pardue wrote: > To close the loop on this thread. We had some more discussion during > the Zurich interim meeting and I took an action to set up a separate > extensions interop matrix.  > > I've added a wiki page for QUIC extension, this is open to adopted and > non-adopted extensions:  > https://github.com/quicwg/base-drafts/wiki/QUIC-Extensions-Interop. > The page contains a table of letters to be used to record interop > results in the extensions matrix. Letters can be reserved on a > first-come, first-served basis but please do consider your neighbours.  > > The extensions interop matrix lives in a new Google docs spreadsheet > that uses purple conditional formatting - > https://docs.google.com/spreadsheets/d/1Ygbit9UySHLMBT8FNgIIqRt2PVo1J9HLJ-yIpfjE374 > > Cheers > Lucas > > On Wed, Jan 8, 2020 at 12:28 PM Lars Eggert > wrote: > > Hi, > > On 2020-1-7, at 16:31, Dmitri Tikhonov > > > wrote: > > There are now a few extensions that have been proposed and > implemented.. > > We should add them to the next Interop matrix. > > maybe we should add a fourth row for extensions? > > I'm with Lucas on that I'd like to keep the sheet focused on > protocol features (and now possibly extensions) that have seen WG > adoption. The rough idea is that unless we believe that the > majority of implementations are going to implement something, it's > probably not worthwhile adding it to the sheet. > > Lars > --------------E50D5D5BCEC3AA3D94E53513 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Two suggestions:

1) Move from draft-25 to draft-27

2) Add "d" for datagram, specify siduck as test tool.


On 2/26/2020 11:41 AM, Lucas Pardue wrote:
To close the loop on this thread. We had some more discussion during the Zurich interim meeting and I took an action to set up a separate extensions interop matrix. 

I've added a wiki page for QUIC extension, this is open to adopted and non-adopted extensions:  https://github.com/quicwg/base-drafts/wiki/QUIC-Extensions-Interop. The page contains a table of letters to be used to record interop results in the extensions matrix. Letters can be reserved on a first-come, first-served basis but please do consider your neighbours. 

The extensions interop matrix lives in a new Google docs spreadsheet that uses purple conditional formatting - https://docs.google.com/spreadsheets/d/1Ygbit9UySHLMBT8FNgIIqRt2PVo1J9HLJ-yIpfjE374

Cheers
Lucas

On Wed, Jan 8, 2020 at 12:28 PM Lars Eggert <lars@eggert.org> wrote:
Hi,

On 2020-1-7, at 16:31, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
> There are now a few extensions that have been proposed and implemented..
> We should add them to the next Interop matrix.

maybe we should add a fourth row for extensions?

I'm with Lucas on that I'd like to keep the sheet focused on protocol features (and now possibly extensions) that have seen WG adoption. The rough idea is that unless we believe that the majority of implementations are going to implement something, it's probably not worthwhile adding it to the sheet.

Lars
--------------E50D5D5BCEC3AA3D94E53513-- From nobody Wed Feb 26 12:27:23 2020 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 888E53A13EE for ; Wed, 26 Feb 2020 12:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsCOritqJ6-w for ; Wed, 26 Feb 2020 12:27:12 -0800 (PST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 5E4F13A13A8 for ; Wed, 26 Feb 2020 12:27:12 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id m3so750704wmi.0 for ; Wed, 26 Feb 2020 12:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7mTpA7k+orqqvSTD968kV3lneGzYZnBf4SVsP7UKOZY=; b=EyHt1wcwTYYdioVgrR8rG/UTSVHUOqQe9l9vTICuThS2UY3k7Z0qVdWc/cqGBEOj4a dhJbCNTUK3TKPMFyA/Lfp8JndBLxDU/n9qikS1M0FoJa+MgHARZ+oxFnW5UeTuAwz3Y1 coF/GR+Japw7jtIVv1WQBMoDf+6IP8rANcRxXLZCwmnxERMwL4S24H9wuuCKbQReTQJ3 r1x6OYyg7i41sV8Zs74QktL8Lad2jTxR4EFPe+bEMGnIvjHbnrUtl6SRJkCHuKdHjHBf S4lWdUgupGkKDFpToiF+mnEJoCemogGl47NNPutUka4qQEY18PXZ6KOb9xPXtGTPTkbq jCqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7mTpA7k+orqqvSTD968kV3lneGzYZnBf4SVsP7UKOZY=; b=fHU8Zs6prQnGOszrOLFUjaXKvKS/st5kZ81ot/cnozY5I75of0vwi6Sn/ZzPApU3zE x5W+A6lWze+N9fQJtlPr7RYy4RVRgmvNtbeykrEQ1mCm9/mZNtF3OmaQ7JgqW60zTgPZ AHwC24JMzo7nU1Om5CeGEg+Vz+WdCeFcztSLKyDpt2h0MjvpqJ3gq7Iv5+z3PdCHFvBs radCnNAbm2fb6D+Kp+YwndhXaGXDsxpgttSoR/hssZVRgXOBlVpkyd6ZZTe4aJPVfP2h RPVZ8hHXGEHJGXa2T1K2wgDpYaDyGqdKCvO6tRLgasv26Li0L0Rkhu52WPcRcAnuSW9t CaSQ== X-Gm-Message-State: APjAAAXCaHryjQ7EwYIhJpFP/1Tkq2o0YzH4JREo4LyN574043XEHgKa Lc17KAxUJwVAmMPSpiZBu4R6rNbfpqS2PRONxcA= X-Google-Smtp-Source: APXvYqxXv/wOEWAR4JIrjRTRi961XRTFeZKqQGQzlLS+FeqIe2QssnBavlV8d7qDqqFcpjqoP0BNgAzBLQ/8rasf+E0= X-Received: by 2002:a7b:ce8b:: with SMTP id q11mr674996wmj.100.1582748830688; Wed, 26 Feb 2020 12:27:10 -0800 (PST) MIME-Version: 1.0 References: <20200107143114.GC14229@ubuntu-dmitri> <5242d630-d923-311e-35c9-94f854b0c929@huitema.net> In-Reply-To: <5242d630-d923-311e-35c9-94f854b0c929@huitema.net> From: Lucas Pardue Date: Wed, 26 Feb 2020 20:27:03 +0000 Message-ID: Subject: Re: Add extension work to Interop matrix To: Christian Huitema Cc: Lars Eggert , IETF QUIC WG , Dmitri Tikhonov Content-Type: multipart/alternative; boundary="000000000000d26936059f806da3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 20:27:22 -0000 --000000000000d26936059f806da3 Content-Type: text/plain; charset="UTF-8" Hey Christian, Although I set up the page and matrix resources, my goal is for the community to self-organise their use. Unlike the core QUIC documents and their "Implementation draft" interops, extensions don't necessarily need to follow the same cadence or coordinate closely between each other. That said, I have some stake in the DATAGRAM tests. d for DATAGRAM sounds good to me. Lucas On Wed, 26 Feb 2020, 20:14 Christian Huitema, wrote: > Two suggestions: > > 1) Move from draft-25 to draft-27 > > 2) Add "d" for datagram, specify siduck as test tool. > > > On 2/26/2020 11:41 AM, Lucas Pardue wrote: > > To close the loop on this thread. We had some more discussion during the > Zurich interim meeting and I took an action to set up a separate extensions > interop matrix. > > I've added a wiki page for QUIC extension, this is open to adopted and > non-adopted extensions: > https://github.com/quicwg/base-drafts/wiki/QUIC-Extensions-Interop. The > page contains a table of letters to be used to record interop results in > the extensions matrix. Letters can be reserved on a first-come, > first-served basis but please do consider your neighbours. > > The extensions interop matrix lives in a new Google docs spreadsheet that > uses purple conditional formatting - > https://docs.google.com/spreadsheets/d/1Ygbit9UySHLMBT8FNgIIqRt2PVo1J9HLJ-yIpfjE374 > > Cheers > Lucas > > On Wed, Jan 8, 2020 at 12:28 PM Lars Eggert wrote: > >> Hi, >> >> On 2020-1-7, at 16:31, Dmitri Tikhonov >> wrote: >> > There are now a few extensions that have been proposed and implemented.. >> > We should add them to the next Interop matrix. >> >> maybe we should add a fourth row for extensions? >> >> I'm with Lucas on that I'd like to keep the sheet focused on protocol >> features (and now possibly extensions) that have seen WG adoption. The >> rough idea is that unless we believe that the majority of implementations >> are going to implement something, it's probably not worthwhile adding it to >> the sheet. >> >> Lars >> > --000000000000d26936059f806da3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Christian,

Although I set up the page and matrix resources, my goal is for t= he community to self-organise their use.=C2=A0

<= /div>
Unlike the core QUIC documents and their "Imple= mentation draft" interops, extensions don't necessarily need to fo= llow the same cadence or coordinate closely between each other.

That said, I have some stake in the= DATAGRAM tests. d for DATAGRAM sounds good to me.
<= br>
Lucas




On Wed, 26 Feb 2020, 20:14 Christian Huitema, <huitema@huitema.net> wrote:
=20 =20 =20

Two suggestions:

1) Move from draft-25 to draft-27

2) Add "d" for datagram, specify siduck as test tool.


On 2/26/2020 11:41 AM, Lucas Pardue wrote:
=20
To close the loop on this thread. We had some more discussion during the Zurich interim meeting and I took an action to set up a separate extensions interop matrix.=C2=A0

I've added a wiki page for QUIC extension, this is open to adopted and non-adopted extensions:=C2=A0 https://github.com/qui= cwg/base-drafts/wiki/QUIC-Extensions-Interop. The page contains a table of letters to be used to record interop results in the extensions matrix. Letters can be reserved on a first-come, first-served basis but please do consider your neighbours.=C2=A0

The extensions interop matrix lives in a new Google docs spreadsheet that uses purple conditional formatting - https://docs.google.com/spre= adsheets/d/1Ygbit9UySHLMBT8FNgIIqRt2PVo1J9HLJ-yIpfjE374

Cheers
Lucas

On Wed, Jan 8, 2020 at 12:28 PM Lars Eggert <lars@eggert.org> wrote:
Hi,

On 2020-1-7, at 16:31, Dmitri Tikhonov <dtikhonov@lit= espeedtech.com> wrote:
> There are now a few extensions that have been proposed and implemented..
> We should add them to the next Interop matrix.

maybe we should add a fourth row for extensions?

I'm with Lucas on that I'd like to keep the sheet focused= on protocol features (and now possibly extensions) that have seen WG adoption. The rough idea is that unless we believe that the majority of implementations are going to implement something, it's probably not worthwhile adding it to the sheet.

Lars
--000000000000d26936059f806da3-- From nobody Wed Feb 26 12:50:24 2020 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 53FA13A1459 for ; Wed, 26 Feb 2020 12:50:19 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=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=litespeedtech-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 Gxe-otcvjdT0 for ; Wed, 26 Feb 2020 12:50:18 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 E585E3A142C for ; Wed, 26 Feb 2020 12:50:17 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id e16so945518qkl.6 for ; Wed, 26 Feb 2020 12:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/8Z24kA7HAywWfSUdJUmsSmTH6kP08NNk3wYzpsyR4E=; b=nY/gUanswOhgobVZh+0w2m5fn7dQS22JfgzBpuzVBD9JqGA/QMhMkr15AW1GJ8PFOl 35hwUkv+ylPdJBM0Nl7hnMqvIvbcs3dxsDgBGwj4j599NCqWsuF09pKs91mj2I+ZEaSq 9slKvloOuQxkLntd1Q1aDyMl0bnnK84VdyrdarkBzuBlZcae3m+6s2jEvOjo3z0ZorBM tJoXU/QmtkVbL0slqMv47zvQdwcgF1EE5Ep7faBaWmsJyAUpJ7I0pn+Z5wcFBE2EBE3Y bz94CbmHyf5l5JPuDrQVWUUPywmpyPClgC3BT56H6e8g+ziD+i66SqcVD7rZp9HvxwRY 6RNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=/8Z24kA7HAywWfSUdJUmsSmTH6kP08NNk3wYzpsyR4E=; b=WJJDafgfzk5DOwT5j00cVqOK6r5zEtty3kMiX7i3ZeIH+lYEeAdFWczt/62tv8Ggd3 79sRL0amgNZ1RV4u0FqXZNxByhhMw/t6ZZo7o/hFX6T6ib+gDz8SShvRKNLAXrJD6T6m 6RH0wTr3+ssh9tLDrYDIg9vuKSion7dRal3XdVPNrOcDzEbGHthVyN6Yb1Y7+qBjc164 PfrwNbmnA2iywP3mWDvca/krtjrGIXGh3fcrpv1qaXFTFUV2E5KDPgVGETUFDvhLhEc1 hWwLiC9PU4wXNLWOR+5nvGDwXAFM/+9BKFgn+usuTszynzWdeVBfB5ExfWRLQOBOzXc1 xk+g== X-Gm-Message-State: APjAAAVtsylHf3BYgZ7IkJ3afWOr+/k3l0LF9l+74GM2cGGM6XUaBpGh OY6tt6rq9ZmCbJ45XG19h0KQJg== X-Google-Smtp-Source: APXvYqyu8aK1kpAL3ZLCxUCZ+PBTDexzzsAfxGm3wBitX98QP001XlVPexLbzFH6renr/VNVSM78Nw== X-Received: by 2002:a05:620a:21d5:: with SMTP id h21mr1302112qka.2.1582750216973; Wed, 26 Feb 2020 12:50:16 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id 64sm1769736qkd.78.2020.02.26.12.50.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 12:50:16 -0800 (PST) Date: Wed, 26 Feb 2020 15:50:12 -0500 From: Dmitri Tikhonov To: Lucas Pardue Cc: Christian Huitema , Lars Eggert , IETF QUIC WG Subject: Re: Add extension work to Interop matrix Message-ID: <20200226205011.GA17953@ubuntu-dmitri> Mail-Followup-To: Lucas Pardue , Christian Huitema , Lars Eggert , IETF QUIC WG References: <20200107143114.GC14229@ubuntu-dmitri> <5242d630-d923-311e-35c9-94f854b0c929@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 20:50:23 -0000 On Wed, Feb 26, 2020 at 08:27:03PM +0000, Lucas Pardue wrote: > That said, I have some stake in the DATAGRAM tests. d for DATAGRAM sounds > good to me. I proposed 'g' earlier in this thread. This way, the letters from the two interop matrices have no conflicts ('d' is for QPACK dynamic table). Of course, true to my creed, I won't die on this hill (or any other hill). - Dmitri. From nobody Wed Feb 26 14:11:08 2020 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 2A8D23A08D8 for ; Wed, 26 Feb 2020 14:11:07 -0800 (PST) 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, SPF_HELO_NONE=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 GNgimSUr5l8G for ; Wed, 26 Feb 2020 14:11:05 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 2C6B43A08C9 for ; Wed, 26 Feb 2020 14:11:05 -0800 (PST) Received: from xse154.mail2web.com ([66.113.196.154] helo=xse.mail2web.com) by mx171.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1j74tO-000Pkw-Pn for quic@ietf.org; Wed, 26 Feb 2020 23:11:01 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 48SVPF2gl7z1df5 for ; Wed, 26 Feb 2020 14:10:57 -0800 (PST) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j74tN-0003Ta-89 for quic@ietf.org; Wed, 26 Feb 2020 14:10:57 -0800 Received: (qmail 15485 invoked from network); 26 Feb 2020 22:10:56 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.43.103]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Feb 2020 22:10:56 -0000 Subject: Re: Add extension work to Interop matrix To: Lucas Pardue , Lars Eggert , IETF QUIC WG References: <20200107143114.GC14229@ubuntu-dmitri> <5242d630-d923-311e-35c9-94f854b0c929@huitema.net> <20200226205011.GA17953@ubuntu-dmitri> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <56f169bd-1176-d791-35d4-0c927bbc819b@huitema.net> Date: Wed, 26 Feb 2020 14:11:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200226205011.GA17953@ubuntu-dmitri> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.196.154 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.154/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.154/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.10) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0eYBE/I2+wvb5IJ3WTuccampSDasLI4SayDByyq9LIhVtV8xR/JbUj43 2RAgzV+HK0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fux9MrCVSWhbqOudeTABZzYU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/LHHzVgerlcwIzWVlPFsIHryme9ldZJ7uNXfg/GfS8fXOC4kn OJkMS8NGDKsP9r3Khy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8aLQTd0uGdLjEYAAeLKuG0y4nuZrRf7bMi0WRR6pZ+nWUiPhoSDyDWrPYk8K/+LJq55 EbGi0w/5bGI17oWaj1Az/oXqnpgMXHsf4y9IfVMtYEXw8BMIsfBCWTvqwtHGsGbsxBoFbdIyTZwD 0tTyhMSsFAr5Nxn1PlNMu/t1QTaZxIaPmF/7MAKyW1Kb4FKGpjSFCr4j6Iy6UW+bEIpBno2GTX2n omYyB9CIvOia1rQRbQ2MtuoXMRfSG2WhEZRm53sbo0e74XDBL4vGUyZkE5n3647lNwN4qOsSZg+f YhVZG3Fpf9P2WwOdPRT3EWlMd754CMBw7+ErSKQN7lw8ITGaNmGHCZF9ZXtfSxIkZLsbHZnckpWa LvahyBjmQxBKOzsmHW0N+NPiHPgn+dyxhvT1Z5EPOIlpyGKEA1x50oTQDUtseoetsROuM82YMzIj 8EU= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 22:11:07 -0000 On 2/26/2020 12:50 PM, Dmitri Tikhonov wrote: > On Wed, Feb 26, 2020 at 08:27:03PM +0000, Lucas Pardue wrote: >> That said, I have some stake in the DATAGRAM tests. d for DATAGRAM sounds >> good to me. > I proposed 'g' earlier in this thread. This way, the letters from > the two interop matrices have no conflicts ('d' is for QPACK dynamic > table). > > Of course, true to my creed, I won't die on this hill (or any other > hill). Nobody wants that. And I certainly don't to want abuse military metaphors. "g" it is. -- Christian Huitema From nobody Wed Feb 26 16:42:12 2020 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 01D6C3A0D2B; Wed, 26 Feb 2020 16:42:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-version-negotiation-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <158276412786.3004.2972487785381190137@ietfa.amsl.com> Date: Wed, 26 Feb 2020 16:42:08 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 00:42:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Compatible Version Negotiation for QUIC Authors : David Schinazi Eric Rescorla Filename : draft-ietf-quic-version-negotiation-00.txt Pages : 8 Date : 2020-02-26 Abstract: QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client offered is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the original and negotiated version share a compatible Initial format, the negotiation can take place without incurring an extra round trip. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub repository which contains the draft: https://github.com/quicwg/ version-negotiation/ (https://github.com/quicwg/version- negotiation/). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-version-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-version-negotiation-00 https://datatracker.ietf.org/doc/html/draft-ietf-quic-version-negotiation-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 26 17:38:40 2020 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 2E4433A0E15; Wed, 26 Feb 2020 17:38:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-datagram-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <158276751111.3004.11169866148293735380@ietfa.amsl.com> Date: Wed, 26 Feb 2020 17:38:31 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 01:38:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : An Unreliable Datagram Extension to QUIC Authors : Tommy Pauly Eric Kinnear David Schinazi Filename : draft-ietf-quic-datagram-00.txt Pages : 9 Date : 2020-02-26 Abstract: This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub repository which contains the draft: https://github.com/quicwg/ datagram (https://github.com/quicwg/datagram). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-datagram-00 https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 26 18:28:31 2020 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 7CC523A0E99 for ; Wed, 26 Feb 2020 18:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 O5lKHnVyrfGk for ; Wed, 26 Feb 2020 18:28:26 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 4D9063A0EA3 for ; Wed, 26 Feb 2020 18:28:26 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id c84so1629976wme.4 for ; Wed, 26 Feb 2020 18:28:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Ey/gXE4N2BNMpQnEnoEltLZR+lWdDYvfrP3vagaqAHA=; b=UksKPL77pssca095ewFzZVRy3Ha58IOb6diBV0K4jQZgFTRZ6mbjJxm4o3Sd/OHpt2 CZi8uxrunQ/gnBzTdzdSlElkC2sFvkfQztOXG2g3501E1KTgcsbaKKZQWzcXjRLxDGai VvggjWUT/TrIkActcjxQUbs1/tDIn2rtLgdE8xWIVqATnwW/5S+KU0neydyywcpN8b8Q HzgK1Pv/CTmpXa4GNIgBg3CBEotcMXIdDDB7K7YuaGlzjXXO1O8gxoQkYfqVzLareuIh 2Wxg2/Q8UdR9c+xdHr8Qvkvs0CNeYTSpJGNIF6eRILSCjU2p1UX2353riwp8lPncBsx5 lA5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ey/gXE4N2BNMpQnEnoEltLZR+lWdDYvfrP3vagaqAHA=; b=YpXgREua9QJUiD7tFLTHKuNfdHcvPuBrchZ93Ld9NuEX8N64OrAwCLDLj13Iq8ylHn ND3llp2fJzKPUMGzMaY3Mue+Mwwnt0uh6PZ2T2Rmknk/dvQF9peZ/7nRzoSYkFgO5ZUl exryp6My0FjUXPm126mgD8YmSTHfsgMhqfYdXwq0Sw4I1XCl5yJH9iiWe9id9n9WeSEl Psq1xynuGDDz45zHFZAHWE/U6nBtCTSLUf7NJy3O5o1JMyX9vDGbXuw92pUpqKIEntOj rzRPzJLKXmWz6pFvLtQLrv12PoD/iS+4FOzfLfwR1+fgtwDODfCl+P5WXjPZEG/KgVJ2 qPwQ== X-Gm-Message-State: APjAAAXfKfpugn3vWQuai3lAxQTD6Ct3JzPEFGqbJrM1JiDNuqhtN3jX zOwi9lmL7Kw1EGvlqZM70ZmGyc2afGsjCyhpc4wolzd9 X-Google-Smtp-Source: APXvYqxzqd3pkbV5JNjJENyVX63Q2mUT2hcN5O/yvnMd5a1D8rdB1c1VON7EVpiH1sPQAtmGX8xKzwCHhK/Muwo36Mo= X-Received: by 2002:a1c:7215:: with SMTP id n21mr2242533wmc.154.1582770504607; Wed, 26 Feb 2020 18:28:24 -0800 (PST) MIME-Version: 1.0 From: Martin Duke Date: Wed, 26 Feb 2020 18:28:12 -0800 Message-ID: Subject: load-balancers repository is live To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b02be2059f8579a8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 02:28:30 -0000 --000000000000b02be2059f8579a8 Content-Type: text/plain; charset="UTF-8" https://github.com/quicwg/load-balancers There are a few minor issues still sitting in the personal repo , most of which I plan to address with PRs in the WG repo over the next few days. (3 are already up). If you would like to provide input on these tweaks please do it this week. The draft has lots of value judgments, of course, but I'm reasonably comfortable with the ones the design team made and will wait for people to file issues about them rather than assume that they're all controversial. To be clear, please file all issues and PRs at the WG site. Thanks Martin --000000000000b02be2059f8579a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https= ://github.com/quicwg/load-balancers=C2=A0

There are = a few minor issues still sitting in the personal repo, most of which I pl= an to address with PRs in the WG repo over the next few days. (3 are alread= y up). If you would like to provide input on these tweaks please do it this= week.

The draft has lots of value judgments, = of course, but I'm reasonably comfortable with the ones the design team= made and will wait for people to file issues about them rather than assume= that they're all controversial.

To be clear, = please file all issues and PRs at the WG site.

Tha= nks
Martin
--000000000000b02be2059f8579a8-- From nobody Thu Feb 27 07:45:51 2020 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 65C123A0B67 for ; Thu, 27 Feb 2020 07:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 GGFgzhmacweF for ; Thu, 27 Feb 2020 07:45:45 -0800 (PST) Received: from vs20.mail.saunalahti.fi (vs20.mail.saunalahti.fi [62.142.117.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBB13A0B6A for ; Thu, 27 Feb 2020 07:45:44 -0800 (PST) Received: from vs20.mail.saunalahti.fi (localhost [127.0.0.1]) by vs20.mail.saunalahti.fi (Postfix) with ESMTP id 7380E204FC for ; Thu, 27 Feb 2020 17:45:42 +0200 (EET) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs20.mail.saunalahti.fi (Postfix) with ESMTP id 669B120426 for ; Thu, 27 Feb 2020 17:45:42 +0200 (EET) Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw01.mail.saunalahti.fi (Postfix) with ESMTPSA id 5DC8D40002 for ; Thu, 27 Feb 2020 17:45:41 +0200 (EET) Received: from [172.20.6.81] (unknown [12.229.247.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id C2F0A680CD6 for ; Thu, 27 Feb 2020 17:45:34 +0200 (EET) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_8F5C6362-948F-4593-BB77-74F266C54F7A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Fwd: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12) Message-Id: References: <3c7f9e3c-d4f6-b002-5e16-6611d654c8eb@erg.abdn.ac.uk> To: IETF QUIC WG Date: Thu, 27 Feb 2020 07:45:32 -0800 X-MailScanner-ID: C2F0A680CD6.A642D X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 15:45:50 -0000 --Apple-Mail=_8F5C6362-948F-4593-BB77-74F266C54F7A Content-Type: multipart/alternative; boundary="Apple-Mail=_F8A53221-8CA3-466F-9367-EB40AE4CDA23" --Apple-Mail=_F8A53221-8CA3-466F-9367-EB40AE4CDA23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii QUIC folks might want to review this one. Lars Begin forwarded message: >=20 > From: Gorry Fairhurst > Subject: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt = (12) > Date: February 27, 2020 at 1:08:53 PST > To: "tsvwg@ietf.org" >=20 > The editors have just uploaded a new revision of = draft-ietf-tsvwg-transport-encrypt following review comments. We are not = aware of further review comments and now think that this new version is = now ready to proceed. >=20 > Best wishes, >=20 > Gorry and Colin >=20 > --- > A new version of I-D, draft-ietf-tsvwg-transport-encrypt-12.txt > has been successfully submitted by Godred Fairhurst and posted to the > IETF repository. >=20 > Name: draft-ietf-tsvwg-transport-encrypt > Revision: 12 > Title: Considerations around Transport Header Confidentiality, Network = Operations, and the Evolution of Internet Transport Protocols > Document date: 2020-02-26 > Group: tsvwg > Pages: 48 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-transport-encrypt-12= .txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-12 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-transport-encrypt-12 >=20 > Abstract: > To protect user data and privacy, Internet transport protocols have > supported payload encryption and authentication for some time. Such > encryption and authentication is now also starting to be applied to > the transport protocol headers. This helps avoid transport protocol > ossification by middleboxes, while also protecting metadata about the > communication. Current operational practice in some networks inspect > transport header information within the network, but this is no > longer possible when those transport headers are encrypted. This > document discusses the possible impact when network traffic uses a > protocol with an encrypted transport header. It suggests issues to > consider when designing new transport protocols, to account for > network operations, prevent network ossification, enable transport > evolution, and respect user privacy. >=20 --Apple-Mail=_F8A53221-8CA3-466F-9367-EB40AE4CDA23 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii QUIC = folks might want to review this one.

Lars

Begin forwarded message:

From: = Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: = [tsvwg] New = Version of draft-ietf-tsvwg-transport-encrypt (12)
Date: = February 27, 2020 at 1:08:53 = PST
To: = "tsvwg@ietf.org" <tsvwg@ietf.org>

The= editors have just uploaded a new revision of = draft-ietf-tsvwg-transport-encrypt following review comments. We are not = aware of further review comments and now think that this new version is = now ready to proceed.

Best wishes,

Gorry and Colin

---
A new version of I-D, = draft-ietf-tsvwg-transport-encrypt-12.txt
has been = successfully submitted by Godred Fairhurst and posted to the
IETF repository.

Name: = draft-ietf-tsvwg-transport-encrypt
Revision: 12
Title: Considerations around Transport Header = Confidentiality, Network Operations, and the Evolution of Internet = Transport Protocols
Document date: 2020-02-26
Group: tsvwg
Pages: 48
URL: https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-transport= -encrypt-12.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-enc= rypt/
Htmlized: https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-= 12
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transpor= t-encrypt
Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-transport-= encrypt-12

Abstract:
To = protect user data and privacy, Internet transport protocols have
supported payload encryption and authentication for some = time. Such
encryption and authentication is now also = starting to be applied to
the transport protocol headers. = This helps avoid transport protocol
ossification by = middleboxes, while also protecting metadata about the
communication. Current operational practice in some networks = inspect
transport header information within the network, = but this is no
longer possible when those transport = headers are encrypted. This
document discusses the = possible impact when network traffic uses a
protocol with = an encrypted transport header. It suggests issues to
consider when designing new transport protocols, to account = for
network operations, prevent network ossification, = enable transport
evolution, and respect user privacy.


= --Apple-Mail=_F8A53221-8CA3-466F-9367-EB40AE4CDA23-- --Apple-Mail=_8F5C6362-948F-4593-BB77-74F266C54F7A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl5X5BwACgkQVLXDCb9w wVf0fhAAziJWxY6OpCR/iei1AxrkGSr1t8X0akAzKITU3pQzZcuUgozECWR7l4i6 ak5fdPUe4gQ5V3LnR1bkAp7vH16mdBSVSVu1aqY92h2SP8u+qvb8wTNnHq/tPNWJ 14xzTDw85YTFYqeTIIgNiJrE20o+Wtz9drukJxwnfDdGz6uQTzEZbBCBKz5e/y0F g/6x4/JrQu63dvbDPMVcHlvE2fNMWcQlM65Y24oRte0F/z4/yLfe2+pQwn2ZzQo8 J/wEItIJ8fDQnTEc23uCzgy3+DlG5j7XFUY/yqPw/EBvooJ/woY+ZorPuLrG9Kf9 0UBB9uqTk8l21oi1C435Z+5sz26Zs9ez7Vh+2uUI8XQc+G+/cA//wWWlmPp5s/uR lj8Hi0uIQt1OpkrGVOTab7Kx7ySX/S60urMFnC9NbBwDhPrqRqDNh9fwROUQLZGt hpzvAF730TqFLpHKRbBTjJwit1n4fs2dkz6DviVOAHSSUdHksAMHXQkkHKo8Lnev erLOGHkAVpUe4O8OSRV/kxBB4pkxWuaRH3XEOiONB+YBxSomg/AsxVcaxzEIrpqo CupmPUDLGpkHix3mx8SxmhCfERcAoWmZR430fUSG8ulm3RXOkIfnGzmcJc8vOYq+ e7QYZugOXa0B3dItIxxKkAl0HIUp0RyPdG1/EInld2g47MuFpeo= =OhfY -----END PGP SIGNATURE----- --Apple-Mail=_8F5C6362-948F-4593-BB77-74F266C54F7A-- From nobody Thu Feb 27 16:03:06 2020 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 2F1343A0914 for ; Thu, 27 Feb 2020 16:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ia5Hpa-YT1dg for ; Thu, 27 Feb 2020 16:03:02 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 ABCBA3A090D for ; Thu, 27 Feb 2020 16:03:02 -0800 (PST) Received: from xse165.mail2web.com ([66.113.196.165] helo=xse.mail2web.com) by mx114.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1j7T7F-0008Y8-R4 for quic@ietf.org; Fri, 28 Feb 2020 01:03:02 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 48T8qt3ykwz5dnp for ; Thu, 27 Feb 2020 16:02:50 -0800 (PST) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j7T7C-00045d-DN for quic@ietf.org; Thu, 27 Feb 2020 16:02:50 -0800 Received: (qmail 28642 invoked from network); 28 Feb 2020 00:02:50 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.43.103]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Feb 2020 00:02:50 -0000 Subject: Fwd: New Version Notification for draft-huitema-quic-ts-01.txt References: <158284593592.2158.11411469379123684866.idtracker@ietfa.amsl.com> To: IETF QUIC WG From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= X-Forwarded-Message-Id: <158284593592.2158.11411469379123684866.idtracker@ietfa.amsl.com> Message-ID: Date: Thu, 27 Feb 2020 16:02:48 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <158284593592.2158.11411469379123684866.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------2FE6A4EE846ED5A3FCE80240" Content-Language: en-US X-Originating-IP: 66.113.196.165 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.165/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.165/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.02) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0eYBE/I2+wvb5IJ3WTuccampSDasLI4SayDByyq9LIhVTTltYpxCMiOx sASADLQIVETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fvjafdR3JRI35Ri1x/ZmTTBU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/d/hBjqsxautjlVXfyJaQKbyme9ldZJ7uNXfg/GfS8fXOC4kn OJkMS8NGDKsP9r3Khy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8aHAjc56T3GRXf4QLCwDHpCCMUz4pTtZ/1Pd40qvLRCAOqdzHgG/vWRpRVa3Sb/Lk5X dU571qBU/d2sq9m7FB7HYyMHj8yFRCDTNrRQvfiZnmkvZ+pWP1s35neRYWMQUWZErSs0X3oyoTc8 j/o7qulxQ2V3DyFKMg9oBb/32l/UWmre/hsBBxzR0ZxLcHZ9dOgG+xKX6c7I/p9OdGlnX/8w7zUw SQMUUmntcQuu2pExcQEH5tktsnhMr4gG+2qXrJ3tzkUQ3NdYqqLdH2fQ065Y9R/2gMGq0KWAzmMf +ibVDpdplkxcBm4XM6d7s4Bx3w1WbaUe4g0kgaInvdEp64qlVpe//bVkg87Xe61e30HXuSERbInM iTBIUBbQ/Dy6Ip4D1rnEhdYtY/lMQX5s39oH5ijcGdSK77ViXbmzTYWgl82XucjoLWQ7++7jcUS/ T5w= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 00:03:05 -0000 This is a multi-part message in MIME format. --------------2FE6A4EE846ED5A3FCE80240 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Time stamp draft updated per discussions on the list. -- Christian Huitema -------- Forwarded Message -------- Subject: New Version Notification for draft-huitema-quic-ts-01.txt Date: Thu, 27 Feb 2020 15:25:35 -0800 From: internet-drafts@ietf.org To: Christian Huitema A new version of I-D, draft-huitema-quic-ts-01.txt has been successfully submitted by Christian Huitema and posted to the IETF repository. Name: draft-huitema-quic-ts Revision: 01 Title: Quic Timestamps For Measuring One-Way Delays Document date: 2020-02-27 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-ts-01.txt Status: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/ Htmlized: https://tools.ietf.org/html/draft-huitema-quic-ts-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts Diff: https://www.ietf.org/rfcdiff?url2=draft-huitema-quic-ts-01 Abstract: The TIME-STAMP frame can be added to Quic packets when one way delay measurements is useful. The timestamp is set to the number of microseconds from the beginning of the connection to the time at which the packet is sent. The draft defines the "enable_time_stamp" transport parameter for negotiating the use of this extension frame, and a new frame types for the time_stamped frame. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------2FE6A4EE846ED5A3FCE80240 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Time stamp draft updated per discussions on the list.

-- Christian Huitema



-------- Forwarded Message --------
Subject: New Version Notification for draft-huitema-quic-ts-01.txt
Date: Thu, 27 Feb 2020 15:25:35 -0800
From: internet-drafts@ietf.org
To: Christian Huitema <huitema@huitema.net>



A new version of I-D, draft-huitema-quic-ts-01.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name: draft-huitema-quic-ts
Revision: 01
Title: Quic Timestamps For Measuring One-Way Delays
Document date: 2020-02-27
Group: Individual Submission
Pages: 8
URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-ts-01.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/
Htmlized: https://tools.ietf.org/html/draft-huitema-quic-ts-01
Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts
Diff: https://www.ietf.org/rfcdiff?url2=draft-huitema-quic-ts-01

Abstract:
The TIME-STAMP frame can be added to Quic packets when one way delay
measurements is useful. The timestamp is set to the number of
microseconds from the beginning of the connection to the time at
which the packet is sent. The draft defines the "enable_time_stamp"
transport parameter for negotiating the use of this extension frame,
and a new frame types for the time_stamped frame.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------2FE6A4EE846ED5A3FCE80240-- From nobody Thu Feb 27 20:15:11 2020 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 723943A0EF0 for ; Thu, 27 Feb 2020 20:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 jXNPPtURvZT5 for ; Thu, 27 Feb 2020 20:15:08 -0800 (PST) Received: from vs23.mail.saunalahti.fi (vs23.mail.saunalahti.fi [193.64.193.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2AFB3A0EEF for ; Thu, 27 Feb 2020 20:15:07 -0800 (PST) Received: from vs23.mail.saunalahti.fi (localhost [127.0.0.1]) by vs23.mail.saunalahti.fi (Postfix) with ESMTP id B8D922047C for ; Fri, 28 Feb 2020 06:15:05 +0200 (EET) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs23.mail.saunalahti.fi (Postfix) with ESMTP id ADE0920404 for ; Fri, 28 Feb 2020 06:15:05 +0200 (EET) Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw03.mail.saunalahti.fi (Postfix) with ESMTPSA id A53CA20003 for ; Fri, 28 Feb 2020 06:15:04 +0200 (EET) Received: from [172.26.37.107] (unknown [76.14.1.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id BA72668116D for ; Fri, 28 Feb 2020 06:14:59 +0200 (EET) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_716B5C98-A7D5-4013-8289-A59AA46E927C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: Doodle poll for -27 virtual interop Date: Thu, 27 Feb 2020 20:14:56 -0800 References: <6AFDD290-2F70-4377-BB8C-691258008CE7@eggert.org> To: IETF QUIC WG In-Reply-To: <6AFDD290-2F70-4377-BB8C-691258008CE7@eggert.org> Message-Id: X-MailScanner-ID: BA72668116D.A256E X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 04:15:10 -0000 --Apple-Mail=_716B5C98-A7D5-4013-8289-A59AA46E927C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, thanks, everyone who participated in this poll. I picked two consecutive days again: March 10-11, 2020. Lars > On 2020-2-24, at 10:10, Lars Eggert wrote: >=20 > Hi, >=20 > if you have a stack to test, please fill out the Doodle: = https://doodle.com/poll/9k2fpmh3r63eeiib >=20 > Thanks, > Lars --Apple-Mail=_716B5C98-A7D5-4013-8289-A59AA46E927C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl5Yk8AACgkQVLXDCb9w wVeDGQ/7BVNiLcns1E5AYojTPeWQR2wBy3W8jdrGB2hLPgj9u/IvGcfYVIPh4wiD HnjxspFiHCCOtvM5wm72OZ5GWCRgqumn5+ScGNSCxQE56+pvKlawa2TwWRrf4sCc 8H8kRBJVZa/7W8c07LBrC0BDxQxt1c50gr4flMx8npxqiA+T1uATidPBFTq5Rveg OonxDU7oDYWuMhAWW7fD7S8q+H4YeCFTyvAn1P8PTR8gIWIoQQc7XrklfdQaqCfi hRKd1c9u7c0rvzcTuGquNnCjCgHbIloRpZMqOkcSOQZN5FYWwo99SRwoBmxXH/cj VY7NT2PKMb5fPGis8ptCHxQoapu5jj2nDLZqAip0CWiOTPN0Uw2HLkxCiAfOkiy4 VdGCgVPIxTIUdBb46r3QVC9oOCKh8BrkAvxdcGf9GcbgImn4vPhOgmAOGElNzBAc PqFVDv6bnHQR3mLaMz/UCCSuI2HaT1cvYDqqrSzrDP6KkcksU4bvfepqyMecfjyt mf6U1CqpFZiJmAOa0Zv1AmaRP2BUKSkEcsUJuNbQuwB0NpUpyAEv//D385+9XMZh rE8op1+xbEietUghW9fQRgdzLz/B1ot9zRu8+jAU9e/GSiP+17UbDSYiS8nWl3Ms OR24GMtMjRRSgFFbYsGjfYpLQwYOiWFdXlmQmnkrsF8Jh5f6Wnc= =o98j -----END PGP SIGNATURE----- --Apple-Mail=_716B5C98-A7D5-4013-8289-A59AA46E927C-- From nobody Fri Feb 28 14:36:16 2020 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 DEB9C3A1F7D; Fri, 28 Feb 2020 14:35:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: quic@ietf.org, magnus.westerlund@ericsson.com Subject: quic - Requested sessions have been scheduled for IETF 107 X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292930288.19931.7841831685902650595@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:02 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:10 -0000 Dear Lars Eggert, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. quic Session 1 (2:00 requested) Tuesday, 24 March 2020, Morning Session I 1000-1200 Room Name: Plaza B/C size: 300 --------------------------------------------- quic Session 2 (1:00 requested) Tuesday, 24 March 2020, Afternoon Session III 1740-1840 Room Name: Plaza B/C size: 300 --------------------------------------------- quic Session 3 (2:00 requested) Wednesday, 25 March 2020, Morning Session I 1000-1200 Room Name: Plaza B/C size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/quic.ics Request Information: --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Lars Eggert Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours, 1 Hour Number of Attendees: 200 Conflicts to Avoid: Chair Conflict: httpbis Technology Overlap: mptcp tls iccrg tcpm tsvwg tsvarea saag Key Participant Conflict: doh capport abcd People who must be present: Sean Turner Mark Nottingham Magnus Westerlund Jana Iyengar Martin Thomson Brian Trammell Mirja Kuehlewind Lars Eggert Mike Bishop Ian Swett Lucas Pardue Alan Frindell Resources Requested: Special Requests: Two consecutive days early in the week. Avoid colliding with all BOFs and area meetings. 3rd session is for planning of future work. Please check with ADs how this 3rd meeting should be scheduled. --------------------------------------------------------- From nobody Sat Feb 29 23:32:24 2020 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 2E37F3A094C for ; Sat, 29 Feb 2020 23:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=mKZl3ldx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3l0SxEOL 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 6patDfEAfl6J for ; Sat, 29 Feb 2020 23:32:20 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542803A095C for ; Sat, 29 Feb 2020 23:32:20 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E6090550 for ; Sun, 1 Mar 2020 02:32:16 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 01 Mar 2020 02:32:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=2ZRfVXGOQ1TkK8KcLFrzdcsZjdP3nH3BiwLPH7qbBhk=; b=mKZl3ldx TK6Bebcbu9fnXlA8T+FO6N8HEOmc4fPMcvH9lo0PAvzq7QYRszrXYo0GA5Mx9VzT A3oTJ3NVmTGnbH9OIbhVsd9hQ4rvuemQouf7ZWoCTNmzcsEIR8DaeTF4QTrFs6o7 1Q64bJ1juoEF68KZtW3jYzAjeBBXPBsKA7B3N8zoLj6zyidHMx+Le9pP5HwtYwNy SMHjfJ6ZVVpbRNZ0fAoS1dWMsU/EBvhmBSx8Ab8qgCaMRl/nvLJ0R3GE5ZecVWlW WtWvgBPhN6l637M1JN3vjL8LFKNF45AqsfcUyahCRZh61/hW+4U3LyMv2ZzbSiru jN18S8Gtp3noEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=2ZRfVXGOQ1TkK8KcLFrzdcsZjdP3n H3BiwLPH7qbBhk=; b=3l0SxEOLg4ynSFKOvViwcZtlnT3DD+ysAqINJmN3pinAn AVNhYJYyjkeDXaGBcBzXl+IAyYi/q2VJ0rs/VoZc5qIJCPqJdSt8fH4/JXEEp00D IjnIZQbUCCELqMOO4d+GB25gcRh91Yi6EDBMge6X/D4BxKHEdoJYq3/hBhp66uEw 6X6EzMTvfRfGsumt77tF5RUXRP45tP381wNEpatMVKNdyDeJm152hjt1U3JIXeqd PJgDWTc5/U2DIb5FJrx2Ay5OW/ssBrqQB10ckIx0Ww6QTZkxSf4yHKh2wMo2zi9v SAgXtMR8mcPj5Cl5yu7VTtEQB9NGF0EmjZN5OhwwQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtuddguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmnecukfhppeehvddrudejledrudefvddrudegvdenucevlhhu shhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprh gvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [52.179.132.142]) by mail.messagingengine.com (Postfix) with ESMTPA id 0BD633280059 for ; Sun, 1 Mar 2020 02:32:16 -0500 (EST) Content-Type: multipart/alternative; boundary="===============2507059839783964197==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: quic@ietf.org Subject: Weekly github digest (QUIC Activity Summary) Message-Id: <20200301073216.0BD633280059@mailuser.nyi.internal> Date: Sun, 1 Mar 2020 02:32:16 -0500 (EST) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2020 07:32:23 -0000 --===============2507059839783964197== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+1/-3/=F0=9F=92=AC8) 1 issues created: - Clarify that Connection IDs are connection specific (by mikkelfj) https://github.com/quicwg/base-drafts/issues/3484=20 5 issues received 8 new comments: - #3477 Encrypting token in Retry packet (3 by ianswett, martinthomson, n= qv) https://github.com/quicwg/base-drafts/issues/3477 [-transport]=20 - #3451 Should we allow ACK-only packets to be declared lost? (1 by iansw= ett) https://github.com/quicwg/base-drafts/issues/3451 [-recovery] [design] = - #3423 active_connection_id_limit is unknown for 0-RTT (1 by ianswett) https://github.com/quicwg/base-drafts/issues/3423 [-transport] [design]= =20 - #2125 Document what needs to be checked for address validation (2 by LP= ardue, martinthomson) https://github.com/quicwg/base-drafts/issues/2125 [-transport] [design]= [has-consensus]=20 - #253 HTTP/QUIC without Alt-Svc? (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/253 [-http] [design]=20 3 issues closed: - Clarify that Connection IDs are connection specific https://github.com/= quicwg/base-drafts/issues/3484=20 - A fixed transport parameter profile is legitimate https://github.com/qu= icwg/base-drafts/issues/3429 [-transport]=20 - Encrypting token in Retry packet https://github.com/quicwg/base-drafts/= issues/3477 [-transport] [invalid]=20 * quicwg/datagram (+3/-0/=F0=9F=92=AC5) 3 issues created: - Specify Max Payload Size instead of Max Frame Size (by DavidSchinazi) https://github.com/quicwg/datagram/issues/3=20 - Consider retransmission bit leakage (by DavidSchinazi) https://github.com/quicwg/datagram/issues/2=20 - remind implementors of the "fun" parts of no flow control (by DavidSchi= nazi) https://github.com/quicwg/datagram/issues/1=20 2 issues received 5 new comments: - #3 Specify Max Payload Size instead of Max Frame Size (3 by DavidSchina= zi, Ralith) https://github.com/quicwg/datagram/issues/3=20 - #2 Consider retransmission bit leakage (2 by DavidSchinazi, chris-wood) https://github.com/quicwg/datagram/issues/2=20 * quicwg/version-negotiation (+6/-0/=F0=9F=92=AC4) 6 issues created: - Should "Compatible Version" mention 0-RTT? (by DavidSchinazi) https://github.com/quicwg/version-negotiation/issues/6=20 - The client is unable to detect downgrade attacks (by DavidSchinazi) https://github.com/quicwg/version-negotiation/issues/5=20 - Change framing to improve clarity (by DavidSchinazi) https://github.com/quicwg/version-negotiation/issues/4=20 - Comments from Mike Bishop (by DavidSchinazi) https://github.com/quicwg/version-negotiation/issues/3=20 - Do servers need to understand compatibility? (by DavidSchinazi) https://github.com/quicwg/version-negotiation/issues/2=20 - In-line or routing promises vs compatibility (by DavidSchinazi) https://github.com/quicwg/version-negotiation/issues/1=20 2 issues received 4 new comments: - #6 Should "Compatible Version" mention 0-RTT? (2 by DavidSchinazi) https://github.com/quicwg/version-negotiation/issues/6=20 - #2 Do servers need to understand compatibility? (2 by DavidSchinazi, Mi= keBishop) https://github.com/quicwg/version-negotiation/issues/2=20 Pull requests ------------- * quicwg/base-drafts (+4/-1/=F0=9F=92=AC5) 4 pull requests submitted: - Make Required Insert Count mismatch error pharagraph less "obtuse". (by= bencebeky) https://github.com/quicwg/base-drafts/pull/3487=20 - HTTP/3: Add RFC8446 reference for TLS 1.3. (by loganaden) https://github.com/quicwg/base-drafts/pull/3483=20 - Fix typo in HTTP draft (by dtikhonov) https://github.com/quicwg/base-drafts/pull/3482=20 - Fix typo in transport draft changelog (by dtikhonov) https://github.com/quicwg/base-drafts/pull/3481=20 5 pull requests received 5 new comments: - #3487 Make Required Insert Count mismatch error pharagraph less "obtuse= ". (1 by bencebeky) https://github.com/quicwg/base-drafts/pull/3487=20 - #3474 Remove timing guidance (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/3474 [-transport] [design]=20 - #3473 renamed max_packet_size to max_udp_size (1 by martinduke) https://github.com/quicwg/base-drafts/pull/3473 [-transport] [design]=20 - #3425 Remember active_connection_id_limit for 0-RTT (1 by ianswett) https://github.com/quicwg/base-drafts/pull/3425 [-transport] [design]=20 - #3415 Reset PTO and loss detection timer when discarding keys (1 by ian= swett) https://github.com/quicwg/base-drafts/pull/3415 [-recovery] [-transport= ] [design]=20 1 pull requests merged: - Improve language on evictable entries. https://github.com/quicwg/base-drafts/pull/3131 [-qpack]=20 * quicwg/load-balancers (+5/-2/=F0=9F=92=AC1) 5 pull requests submitted: - Conform README and CONTRIBUTING to WG standard (by martinduke) https://github.com/quicwg/load-balancers/pull/5=20 - Update readme title (by nibanks) https://github.com/quicwg/load-balancers/pull/4=20 - Explain how load balancer chains might work (by martinduke) https://github.com/quicwg/load-balancers/pull/3=20 - Light edit of Retry Services section (by martinduke) https://github.com/quicwg/load-balancers/pull/2=20 - Deleted leftover reference to config method (by martinduke) https://github.com/quicwg/load-balancers/pull/1=20 1 pull requests received 1 new comments: - #4 Update readme title (1 by martinduke) https://github.com/quicwg/load-balancers/pull/4=20 2 pull requests merged: - Explain how load balancer chains might work https://github.com/quicwg/load-balancers/pull/3=20 - Deleted leftover reference to config method https://github.com/quicwg/load-balancers/pull/1=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts * https://github.com/quicwg/ops-drafts * https://github.com/quicwg/datagram * https://github.com/quicwg/load-balancers * https://github.com/quicwg/version-negotiation --===============2507059839783964197== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Activity Summary)

Sunday March 01, 2020

Events without label "editorial"

Issues

quicwg/base-drafts (+1/-3/=F0=9F=92=AC8)

1 issues created:

5 issues received 8 new comments:

3 issues closed:

quicwg/datagram (+3/-0/=F0=9F=92=AC5)

3 issues created:

2 issues received 5 new comments:

quicwg/version-negotiation (+6/-0/=F0=9F=92=AC4)

6 issues created:

2 issues received 4 new comments:

Pull requests

quicwg/base-drafts (+4/-1/=F0=9F=92=AC5)

4 pull requests submitted:

5 pull requests received 5 new comments:

1 pull requests merged:

quicwg/load-balancers (+5/-2/=F0=9F=92=AC1)

5 pull requests submitted:

1 pull requests received 1 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============2507059839783964197==--