From nobody Tue Oct 1 13:51:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70037120089 for ; Tue, 1 Oct 2019 13:51:05 -0700 (PDT) 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 TQBbtMlQORBN for ; Tue, 1 Oct 2019 13:51:03 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 ED13F12006F for ; Tue, 1 Oct 2019 13:51:02 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id t8so10935763lfc.13 for ; Tue, 01 Oct 2019 13:51:02 -0700 (PDT) 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=jHHFmeo/gqHAA9thnDWNZ5Oc7FmaUY6Re9k99cpH4d4=; b=JgJJ257LC6Au5TjkoPDOd4YjOnzXPbK6d5zA0ghMUXdEWGFmaHe/AutxZXEbsaFWVs 9GjgNwGJ3f1chtyjCmuvl1OJZpMQtX2aouEvUnmc2KQsryvThu1yniHKanndDzDS/KMo L2HVWNqwndQXvmCM7O6xS3UqwibxSds5prUzihYs7q1JL6kicYJ6BFVZmfDA/dV5WCvz dQcxnrO0yc9D4QEgMcgWUOaqPT0oBcM8ljcajG5pdtXe0yPAFmXyAxbp0sqpYS0eutRJ VU3vP5w7cu1c/NYpR+n7xfz4WHr6lvHz6rR9BGQpdzqqe65h63S+4aqAZ0Z4OuNSfQfY vKmw== 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=jHHFmeo/gqHAA9thnDWNZ5Oc7FmaUY6Re9k99cpH4d4=; b=MJ2ZcJoJvVSe8LuEOWXVbc0PawK2o6Cuo43gYqxD03YXwnKKaUVaD+JSy+TKWtQkLg dr3fEHFSws2MDQp6XGpPty/CZJCaFoz0VIbufc2u0S1gkAY5YFpoRPZFeUT6TAMrjpFi slLDsanwoKTO9dOkeLxiPfzeDDrekWeNclqYP862ETTWlDpQiH6g6d00T4i3HsU34lxX 7Z6fH17gL3UmP1kFwTd5FnVwyiH6nUVyh0Nh0Cax8bB/MJzq5WDyRjwZIOkTQkQEu8Id Duh78+v6BTrB6w9MGnuMYx0wzGt4MlYnFJm1zOaC5BUi51ozJz2d6JHb+h+kNjw0hw2d BZSQ== X-Gm-Message-State: APjAAAWrn/HGaJgPTThxq3CxUIBMr56GLhdzesYuSHDXYIMHJ0TCvNBR B+Ium1gXWR8AK92+0R7JAV1pX69/OJicsGoT1xIfbQ== X-Google-Smtp-Source: APXvYqxd6wLhFNfNmmYQzCa9Y0mMDU5T+RNTAXzHVpD07r9now2N0lIzCx4rn9tLsdkgmuWKQcBMEtjXiKra1G+KlOg= X-Received: by 2002:ac2:5a19:: with SMTP id q25mr16098798lfn.178.1569963060995; Tue, 01 Oct 2019 13:51:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 1 Oct 2019 13:50:24 -0700 Message-ID: Subject: Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS To: Ted Hardie Cc: Nick Harper , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000008fc0490593df8261" 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, 01 Oct 2019 20:51:05 -0000 --0000000000008fc0490593df8261 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Does this need to be a 1.0 feature? On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie wrote: > Hi Nick, > > Two points in addition to the privacy issue already raised make me concur > with Roberto that this should be v2 or later. The first is this: > > "Negotiating or advertising features is something multiple > applicationswill need to do and is not a feature specific to H3." > > Absolutely true, but there is also a fairly large variability in how > applications do this. If we design something now that works for H3, it m= ay > very well be sub-optimal or useless for later application targets. Getti= ng > something general enough to handle DNS, WEBRTC, SMTP, plus the various > flavors of IoT protocols I've heard as targets hoping to move to QUIC is > going to take time and care, and it will block completion of v1. > > The second is this: > > *The other downside is that if too much data is put in application > parameters, it could cause the number of packets for a client or server= =E2=80=99s > flight to go from N to N+1, which would increase the chance of head of li= ne > blocking. > > Depending on what counts as application parameters, this could be more > than N+1. Someone running NETCONF over QUIC, for example, would be using= a > fairly verbose syntax in which each parameter is a full URN. > > regards, > > Ted Hardie > > > On Thu, Sep 26, 2019 at 5:52 PM Nick Harper 40google.com@dmarc.ietf.org> wrote: > >> I propose introducing application parameters to the QUIC handshake and >> using this new mechanism for H3 SETTINGS instead of sending them as >> the first thing in the control stream. Application parameters would >> allow applications using QUIC to advertise or negotiate >> application-specific parameters during the cryptographic and transport >> handshake. It would guarantee that the client and server have >> exchanged their application parameters once the handshake is complete. >> >> Specifically, I=E2=80=99m proposing a new =E2=80=9Capplication_layer_par= ameters=E2=80=9D >> transport parameter, which when sent by the client is a series of ALPN >> identifiers with an opaque blob of application parameters per >> identifier, and when sent by the server is a single opaque blob of >> application parameters for the application identified in the ALPN >> extension. >> >> Negotiating or advertising features is something multiple applications >> will need to do and is not a feature specific to H3. Whatever we do in >> H3 will likely be copied by other applications using QUIC. By >> providing a general mechanism in QUIC transport, we provide >> applications with a consistent way of achieving this goal. QUIC has a >> design pattern of collapsing multiple layers into one to save on round >> trips (e.g. combining crypto and transport handshake); this fits in >> with that pattern. >> >> Using application parameters for H3 SETTINGS clears up some issues. H3 >> doesn=E2=80=99t need to specify that an endpoint shouldn=E2=80=99t wait = for its peer=E2=80=99s >> SETTINGS since they=E2=80=99ve already arrived. Likewise, there is no >> confusion about whether SETTINGS arriving after session tickets are >> bound to the session tickets; SETTINGS arrives before the tickets and >> the client doesn=E2=80=99t need to wait for the receipt of SETTINGS to b= ind >> them to the ticket. It also simplifies the server binding SETTINGS to >> the ticket since that is done as part of binding transport parameters >> to the ticket. >> >> This also provides opportunities for future features. Since the >> exchange of SETTINGS occurs before application data, a new feature >> doesn=E2=80=99t need to be specified in a way to provide an upgrade path= from >> =E2=80=9Cvanilla=E2=80=9D H3 to something including this feature, and in= stead be >> guaranteed that the new feature can be used for the entire connection. >> >> Without application parameters, each application that needs to >> advertise or negotiate application settings needs its own mechanism to >> do so. This would result in multiple transport parameters or >> extensions leading to duplication of work and layering violations. >> Applications could instead exchange these settings in application >> data, meaning that each application needs to define the semantics of >> application data received before and after the settings have been >> exchanged, as H3 currently does. >> >> There is already a demonstrated need for an application parameters >> mechanism in the QUIC handshake. One example is >> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 which is >> currently using a =E2=80=9Cweb_accepted_origins=E2=80=9D transport param= eter but could >> easily use an application parameters mechanism instead. >> >> I see two downsides to this proposal. The first is that the client=E2=80= =99s >> application parameters are sent in the clear. Application designers >> will need to make a decision of how much they want to use this >> functionality (they could limit what is sent by the client or only use >> application parameters in the server direction). For H3, there are >> only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, QPACK_BLOCKED_STREAMS, >> and MAX_HEADER_LIST_SIZE, which do not reveal any information about >> the user or the server they are connecting to and are likely constant >> per H3 implementation. >> >> The other downside is that if too much data is put in application >> parameters, it could cause the number of packets for a client or >> server=E2=80=99s flight to go from N to N+1, which would increase the ch= ance >> of head of line blocking. >> >> Related issues: >> https://github.com/quicwg/base-drafts/issues/2790: Binding settings >> into session tickets >> https://github.com/quicwg/base-drafts/issues/2945: When to send the >> SETTINGS frame >> https://github.com/quicwg/base-drafts/issues/2783: Consider making >> SETTINGS part of the control stream header >> https://github.com/quicwg/base-drafts/issues/436: Move SETTINGS into >> TLS Handshake >> >> --0000000000008fc0490593df8261 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does this need to be a 1.0 feature?

On Fri, Sep 27, 201= 9 at 12:13 PM Ted Hardie <ted.ietf= @gmail.com> wrote:
Hi Nick,

Two points in addition to the privacy issue already raised make me= concur with Roberto that this should be v2 or later.=C2=A0 The first is th= is:

"Negotiating or advertising features is s= omething multiple applicationswill need to do and is not a feature specific= to H3."

Absolutely true, but there is also a= fairly large variability in how applications do this.=C2=A0 If we design s= omething now that works for H3, it may very well be sub-optimal or useless = for later application targets.=C2=A0 Getting something general enough to ha= ndle DNS, WEBRTC,=C2=A0 SMTP, plus the various flavors of IoT protocols I&#= 39;ve heard as targets hoping to move to QUIC is going to take time and car= e, and it will block completion of v1.

The se= cond is this:

*The other downside is that if too m= uch data is put in application parameters, it could cause the number of pac= kets for a client or server=E2=80=99s flight to go from N to N+1, which wou= ld increase the chance of head of line blocking.

=
Depending on what counts as application parameters, this could be more= than N+1.=C2=A0 Someone running NETCONF over QUIC, for example, would be u= sing a fairly verbose syntax in which each parameter is a full URN.=C2=A0 <= br>

regards,

Ted Hardie


On Thu, Sep 26, 2019 at 5:52 PM Nick Harper <nha= rper=3D40g= oogle.com@dmarc.ietf.org> wrote:
I propose introducing application parameters to the= QUIC handshake and
using this new mechanism for H3 SETTINGS instead of sending them as
the first thing in the control stream. Application parameters would
allow applications using QUIC to advertise or negotiate
application-specific parameters during the cryptographic and transport
handshake. It would guarantee that the client and server have
exchanged their application parameters once the handshake is complete.

Specifically, I=E2=80=99m proposing a new =E2=80=9Capplication_layer_parame= ters=E2=80=9D
transport parameter, which when sent by the client is a series of ALPN
identifiers with an opaque blob of application parameters per
identifier, and when sent by the server is a single opaque blob of
application parameters for the application identified in the ALPN
extension.

Negotiating or advertising features is something multiple applications
will need to do and is not a feature specific to H3. Whatever we do in
H3 will likely be copied by other applications using QUIC. By
providing a general mechanism in QUIC transport, we provide
applications with a consistent way of achieving this goal. QUIC has a
design pattern of collapsing multiple layers into one to save on round
trips (e.g. combining crypto and transport handshake); this fits in
with that pattern.

Using application parameters for H3 SETTINGS clears up some issues. H3
doesn=E2=80=99t need to specify that an endpoint shouldn=E2=80=99t wait for= its peer=E2=80=99s
SETTINGS since they=E2=80=99ve already arrived. Likewise, there is no
confusion about whether SETTINGS arriving after session tickets are
bound to the session tickets; SETTINGS arrives before the tickets and
the client doesn=E2=80=99t need to wait for the receipt of SETTINGS to bind=
them to the ticket. It also simplifies the server binding SETTINGS to
the ticket since that is done as part of binding transport parameters
to the ticket.

This also provides opportunities for future features. Since the
exchange of SETTINGS occurs before application data, a new feature
doesn=E2=80=99t need to be specified in a way to provide an upgrade path fr= om
=E2=80=9Cvanilla=E2=80=9D H3 to something including this feature, and inste= ad be
guaranteed that the new feature can be used for the entire connection.

Without application parameters, each application that needs to
advertise or negotiate application settings needs its own mechanism to
do so. This would result in multiple transport parameters or
extensions leading to duplication of work and layering violations.
Applications could instead exchange these settings in application
data, meaning that each application needs to define the semantics of
application data received before and after the settings have been
exchanged, as H3 currently does.

There is already a demonstrated need for an application parameters
mechanism in the QUIC handshake. One example is
https://tools.ietf.org/html/draft-vvv-web= transport-quic-00 which is
currently using a =E2=80=9Cweb_accepted_origins=E2=80=9D transport paramete= r but could
easily use an application parameters mechanism instead.

I see two downsides to this proposal. The first is that the client=E2=80=99= s
application parameters are sent in the clear. Application designers
will need to make a decision of how much they want to use this
functionality (they could limit what is sent by the client or only use
application parameters in the server direction). For H3, there are
only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, QPACK_BLOCKED_STREAMS,
and MAX_HEADER_LIST_SIZE, which do not reveal any information about
the user or the server they are connecting to and are likely constant
per H3 implementation.

The other downside is that if too much data is put in application
parameters, it could cause the number of packets for a client or
server=E2=80=99s flight to go from N to N+1, which would increase the chanc= e
of head of line blocking.

Related issues:
https://github.com/quicwg/base-drafts/issues/2790: Binding settings
into session tickets
https://github.com/quicwg/base-drafts/issues/2945: When to send the
SETTINGS frame
https://github.com/quicwg/base-drafts/issues/2783: Consider making
SETTINGS part of the control stream header
https://github.com/quicwg/base-drafts/issues/436= : Move SETTINGS into
TLS Handshake

--0000000000008fc0490593df8261-- From nobody Tue Oct 1 16:41:53 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25171202A0 for ; Tue, 1 Oct 2019 16:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 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, 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 nkIaHru2lxRM for ; Tue, 1 Oct 2019 16:41:49 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210F8120132 for ; Tue, 1 Oct 2019 16:41:49 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id k20so16101972oih.3 for ; Tue, 01 Oct 2019 16:41:49 -0700 (PDT) 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:content-transfer-encoding; bh=9iBQ4TLWLupQGeGpmwarrtpqr8cwca6L3T8tVrD64Lc=; b=LkwWXhuu0BNN4cp32In3uJ/StbIP1KV/HlKjxPnWLV/4O7fEBl8vC5UNYfBJApF0/9 X3Q18I3em4efMconYSdTPHJozd0zT3HEJtDA3RuBtAb532IDHvJ0jBuSe9ieiB8tZmW0 VExzpUTSSke1ezvhBjwUCxkcJ7B9rNjfrp9hk+V+hSB9oKDqtvrlcX4ImZ6ALoQTqeBv BH5XvVGXzFbWMY/yXDCZfbMaqsgHoCIrIPI+vrR133z4SieDgqGi6CI8xHNJvgqHDO59 qVM9I84LDB8OWrBCmmAHlzmdRji6i951wdeYEObIvk9z1of7Ekpya7yWt8iJSy9srB0e jisQ== 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:content-transfer-encoding; bh=9iBQ4TLWLupQGeGpmwarrtpqr8cwca6L3T8tVrD64Lc=; b=gt/0w+U88MV00tEdO9i3xI/c3kqzqfIAdDiaxqVvjyIkz3Mc9X51HVx5Mem2WPDz7A GsNcZYErylD6H1Nibq/4fz4cpQsxyUZQmGB6lwdYkD2eKGdhBVCTbZFZqOOsFyCFtGpf RvHGEk+7ddUmjFiS+SEZ2uv3En7KQvmtfaCVonmAZNQH/GuzzIsK13zWo+eOMeJiM56H gGXrp7BBT9Fn6T223YPCrYLg73sOIQ6oZO5JfkB9m95RjnBxM7sJlirpHYsp93rsdJiT afNCBvNZzPyVH2N4x/0MESwpZ9SZQWStX5l9mN+U8S39JxlXWAeqoK0ijv26VVC6lfyc 5n9g== X-Gm-Message-State: APjAAAWadtllc/BJ21zb2bslq+VbQ+CxbSbQBF1HKVbOHXK23qtwxLM1 HcQGNfF74Kj05k74c7AQRA9nB7Wv9d2/b7xZCLemsA== X-Google-Smtp-Source: APXvYqyQVsePF8VU85Id4NkKzWFI0tXH7coPI8fU23VOd9Bdld06JxzvPwB3CXB/NH6DzcG4nMPAL6F9vCBhtqfFRIk= X-Received: by 2002:aca:eb09:: with SMTP id j9mr496259oih.105.1569973307995; Tue, 01 Oct 2019 16:41:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Harper Date: Tue, 1 Oct 2019 16:41:36 -0700 Message-ID: Subject: Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS To: Eric Rescorla Cc: Ted Hardie , IETF QUIC WG 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: Tue, 01 Oct 2019 23:41:52 -0000 I think it loses most of its utility if it's not a v1 feature. The main motivation for the feature is to simplify application protocols. At the time that v2 is introduced and application protocols are being specified to use it, existing application protocols will already have an application-specific way to negotiate params, so they will continue to use that instead of using both the existing application-specific mechanism (for v1) and v2-only application parameters feature (for v2+). (I'm assuming that as applications switch from using QUIC v1 to QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS 1.3, instead of like upgrading H2 to H3.) On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla wrote: > > Does this need to be a 1.0 feature? > > On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie wrote: >> >> Hi Nick, >> >> Two points in addition to the privacy issue already raised make me concu= r with Roberto that this should be v2 or later. The first is this: >> >> "Negotiating or advertising features is something multiple applicationsw= ill need to do and is not a feature specific to H3." >> >> Absolutely true, but there is also a fairly large variability in how app= lications do this. If we design something now that works for H3, it may ve= ry well be sub-optimal or useless for later application targets. Getting s= omething general enough to handle DNS, WEBRTC, SMTP, plus the various flav= ors of IoT protocols I've heard as targets hoping to move to QUIC is going = to take time and care, and it will block completion of v1. >> >> The second is this: >> >> *The other downside is that if too much data is put in application param= eters, it could cause the number of packets for a client or server=E2=80=99= s flight to go from N to N+1, which would increase the chance of head of li= ne blocking. >> >> Depending on what counts as application parameters, this could be more t= han N+1. Someone running NETCONF over QUIC, for example, would be using a = fairly verbose syntax in which each parameter is a full URN. >> >> regards, >> >> Ted Hardie >> >> >> On Thu, Sep 26, 2019 at 5:52 PM Nick Harper wrote: >>> >>> I propose introducing application parameters to the QUIC handshake and >>> using this new mechanism for H3 SETTINGS instead of sending them as >>> the first thing in the control stream. Application parameters would >>> allow applications using QUIC to advertise or negotiate >>> application-specific parameters during the cryptographic and transport >>> handshake. It would guarantee that the client and server have >>> exchanged their application parameters once the handshake is complete. >>> >>> Specifically, I=E2=80=99m proposing a new =E2=80=9Capplication_layer_pa= rameters=E2=80=9D >>> transport parameter, which when sent by the client is a series of ALPN >>> identifiers with an opaque blob of application parameters per >>> identifier, and when sent by the server is a single opaque blob of >>> application parameters for the application identified in the ALPN >>> extension. >>> >>> Negotiating or advertising features is something multiple applications >>> will need to do and is not a feature specific to H3. Whatever we do in >>> H3 will likely be copied by other applications using QUIC. By >>> providing a general mechanism in QUIC transport, we provide >>> applications with a consistent way of achieving this goal. QUIC has a >>> design pattern of collapsing multiple layers into one to save on round >>> trips (e.g. combining crypto and transport handshake); this fits in >>> with that pattern. >>> >>> Using application parameters for H3 SETTINGS clears up some issues. H3 >>> doesn=E2=80=99t need to specify that an endpoint shouldn=E2=80=99t wait= for its peer=E2=80=99s >>> SETTINGS since they=E2=80=99ve already arrived. Likewise, there is no >>> confusion about whether SETTINGS arriving after session tickets are >>> bound to the session tickets; SETTINGS arrives before the tickets and >>> the client doesn=E2=80=99t need to wait for the receipt of SETTINGS to = bind >>> them to the ticket. It also simplifies the server binding SETTINGS to >>> the ticket since that is done as part of binding transport parameters >>> to the ticket. >>> >>> This also provides opportunities for future features. Since the >>> exchange of SETTINGS occurs before application data, a new feature >>> doesn=E2=80=99t need to be specified in a way to provide an upgrade pat= h from >>> =E2=80=9Cvanilla=E2=80=9D H3 to something including this feature, and i= nstead be >>> guaranteed that the new feature can be used for the entire connection. >>> >>> Without application parameters, each application that needs to >>> advertise or negotiate application settings needs its own mechanism to >>> do so. This would result in multiple transport parameters or >>> extensions leading to duplication of work and layering violations. >>> Applications could instead exchange these settings in application >>> data, meaning that each application needs to define the semantics of >>> application data received before and after the settings have been >>> exchanged, as H3 currently does. >>> >>> There is already a demonstrated need for an application parameters >>> mechanism in the QUIC handshake. One example is >>> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 which is >>> currently using a =E2=80=9Cweb_accepted_origins=E2=80=9D transport para= meter but could >>> easily use an application parameters mechanism instead. >>> >>> I see two downsides to this proposal. The first is that the client=E2= =80=99s >>> application parameters are sent in the clear. Application designers >>> will need to make a decision of how much they want to use this >>> functionality (they could limit what is sent by the client or only use >>> application parameters in the server direction). For H3, there are >>> only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, QPACK_BLOCKED_STREAMS, >>> and MAX_HEADER_LIST_SIZE, which do not reveal any information about >>> the user or the server they are connecting to and are likely constant >>> per H3 implementation. >>> >>> The other downside is that if too much data is put in application >>> parameters, it could cause the number of packets for a client or >>> server=E2=80=99s flight to go from N to N+1, which would increase the c= hance >>> of head of line blocking. >>> >>> Related issues: >>> https://github.com/quicwg/base-drafts/issues/2790: Binding settings >>> into session tickets >>> https://github.com/quicwg/base-drafts/issues/2945: When to send the >>> SETTINGS frame >>> https://github.com/quicwg/base-drafts/issues/2783: Consider making >>> SETTINGS part of the control stream header >>> https://github.com/quicwg/base-drafts/issues/436: Move SETTINGS into >>> TLS Handshake >>> From nobody Tue Oct 1 17:21:06 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7E312011E for ; Tue, 1 Oct 2019 17:21:04 -0700 (PDT) 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=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 L_zo1RE6VIvO for ; Tue, 1 Oct 2019 17:21:01 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450: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 F08AF12009E for ; Tue, 1 Oct 2019 17:21:00 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id 7so15247676ljw.7 for ; Tue, 01 Oct 2019 17:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wj6wFhZ3IK1ov5ZrfJP/FmqaFNP6RBIi0wZJ0L548c4=; b=B9MIOJ1Cw8LyJKWZbRWm7ITFDPLYXjiVRHM8bf2/xQK8tz4vSNTebRWw6A6BGGjWfx Xa+pCqE+m3qcANjcJuKZ6TckUmuMZUz3oXcGkdvQeKHQ4BPXT/u+KEZq2vsZW+NnGbsl P1tHDwvJlA7CWoKMuc3NLl713IFTj5sCVhHu8bTMqsl6qwG83JYu7ewMklCg6Y0+ViYT dkvMozHVlJDebHxz96DllZuyuOhvWX2zEVTk+CoGnobpzjvXUuqnnX3oPgFcPJklFrrY Lk/wL6pZu2/xHDX9bFSTkTGL3zDCE1dvZzbvViwqxak/oUs1+tyaFdIZ0t1Ynt70cq6a TntA== 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=Wj6wFhZ3IK1ov5ZrfJP/FmqaFNP6RBIi0wZJ0L548c4=; b=bg3vJYToJr8Zmlr1MoVQpBHDFmATSbYASVwt7QfJLQpKjTkLECs4Kkq6qoKKj1ddG9 WtloK/ws39GMkMIje78oIC1C97fGQq3cqGsw/hCl6+ImHpLw0MGE1N+NQVQPuXb+LRQR PC8W+wU8oIoE+ZMgC03W3XRf7VdnbsNgFhkv1yhBxBEEJgKYPGVJrXWe42DfriuSiI6B gYcV+imfOo34vY2jkvZ3juTRCcrOBZSfo5mIkLMWCkIujnXMIMJnUSwFL+H5EmPEdUW4 iNGjrBtOruq5qesbLxXrxydrjFAGeM8qvanTS9b03D/aqUm2JEl2Ech90uzg2IZxY6vC Y37g== X-Gm-Message-State: APjAAAW5FQ5xjVh0HuWiizUGSZ97q+rjjxscAZH0/skgwIkf0cK9Uu83 elLOXLS49Y7xcU19NTI3jDasPy6BSzDNZh70F3g= X-Google-Smtp-Source: APXvYqzVNVwlcUhPYvjAmBZ0uHiEzYD2MW6gpVXxtQCeIS7NxTca8u6sCwtuZ99OfryjjBo/QNllxQYUCN3PEZeslss= X-Received: by 2002:a2e:9702:: with SMTP id r2mr346201lji.190.1569975659108; Tue, 01 Oct 2019 17:20:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Tue, 1 Oct 2019 17:20:48 -0700 Message-ID: Subject: Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS To: Nick Harper Cc: Eric Rescorla , Ted Hardie , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000779b660593e271e0" 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, 02 Oct 2019 00:21:05 -0000 --000000000000779b660593e271e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Additionally, the current status quo makes it hard to have SETTINGS play nicely with 0-RTT. Fixing this is important to deploying IETF QUIC. We're chartered to produce a protocol with fast connection establishment, and if we fail to negotiate options and extensions nicely with that, we'll harm extensibility long-term and cause deployment of damaging workarounds. David On Tue, Oct 1, 2019 at 4:41 PM Nick Harper wrote: > I think it loses most of its utility if it's not a v1 feature. The > main motivation for the feature is to simplify application protocols. > At the time that v2 is introduced and application protocols are being > specified to use it, existing application protocols will already have > an application-specific way to negotiate params, so they will continue > to use that instead of using both the existing application-specific > mechanism (for v1) and v2-only application parameters feature (for > v2+). (I'm assuming that as applications switch from using QUIC v1 to > QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS 1.3, instead > of like upgrading H2 to H3.) > > On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla wrote: > > > > Does this need to be a 1.0 feature? > > > > On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie wrote: > >> > >> Hi Nick, > >> > >> Two points in addition to the privacy issue already raised make me > concur with Roberto that this should be v2 or later. The first is this: > >> > >> "Negotiating or advertising features is something multiple > applicationswill need to do and is not a feature specific to H3." > >> > >> Absolutely true, but there is also a fairly large variability in how > applications do this. If we design something now that works for H3, it m= ay > very well be sub-optimal or useless for later application targets. Getti= ng > something general enough to handle DNS, WEBRTC, SMTP, plus the various > flavors of IoT protocols I've heard as targets hoping to move to QUIC is > going to take time and care, and it will block completion of v1. > >> > >> The second is this: > >> > >> *The other downside is that if too much data is put in application > parameters, it could cause the number of packets for a client or server= =E2=80=99s > flight to go from N to N+1, which would increase the chance of head of li= ne > blocking. > >> > >> Depending on what counts as application parameters, this could be more > than N+1. Someone running NETCONF over QUIC, for example, would be using= a > fairly verbose syntax in which each parameter is a full URN. > >> > >> regards, > >> > >> Ted Hardie > >> > >> > >> On Thu, Sep 26, 2019 at 5:52 PM Nick Harper 40google.com@dmarc.ietf.org> wrote: > >>> > >>> I propose introducing application parameters to the QUIC handshake an= d > >>> using this new mechanism for H3 SETTINGS instead of sending them as > >>> the first thing in the control stream. Application parameters would > >>> allow applications using QUIC to advertise or negotiate > >>> application-specific parameters during the cryptographic and transpor= t > >>> handshake. It would guarantee that the client and server have > >>> exchanged their application parameters once the handshake is complete= . > >>> > >>> Specifically, I=E2=80=99m proposing a new =E2=80=9Capplication_layer_= parameters=E2=80=9D > >>> transport parameter, which when sent by the client is a series of ALP= N > >>> identifiers with an opaque blob of application parameters per > >>> identifier, and when sent by the server is a single opaque blob of > >>> application parameters for the application identified in the ALPN > >>> extension. > >>> > >>> Negotiating or advertising features is something multiple application= s > >>> will need to do and is not a feature specific to H3. Whatever we do i= n > >>> H3 will likely be copied by other applications using QUIC. By > >>> providing a general mechanism in QUIC transport, we provide > >>> applications with a consistent way of achieving this goal. QUIC has a > >>> design pattern of collapsing multiple layers into one to save on roun= d > >>> trips (e.g. combining crypto and transport handshake); this fits in > >>> with that pattern. > >>> > >>> Using application parameters for H3 SETTINGS clears up some issues. H= 3 > >>> doesn=E2=80=99t need to specify that an endpoint shouldn=E2=80=99t wa= it for its peer=E2=80=99s > >>> SETTINGS since they=E2=80=99ve already arrived. Likewise, there is no > >>> confusion about whether SETTINGS arriving after session tickets are > >>> bound to the session tickets; SETTINGS arrives before the tickets and > >>> the client doesn=E2=80=99t need to wait for the receipt of SETTINGS t= o bind > >>> them to the ticket. It also simplifies the server binding SETTINGS to > >>> the ticket since that is done as part of binding transport parameters > >>> to the ticket. > >>> > >>> This also provides opportunities for future features. Since the > >>> exchange of SETTINGS occurs before application data, a new feature > >>> doesn=E2=80=99t need to be specified in a way to provide an upgrade p= ath from > >>> =E2=80=9Cvanilla=E2=80=9D H3 to something including this feature, and= instead be > >>> guaranteed that the new feature can be used for the entire connection= . > >>> > >>> Without application parameters, each application that needs to > >>> advertise or negotiate application settings needs its own mechanism t= o > >>> do so. This would result in multiple transport parameters or > >>> extensions leading to duplication of work and layering violations. > >>> Applications could instead exchange these settings in application > >>> data, meaning that each application needs to define the semantics of > >>> application data received before and after the settings have been > >>> exchanged, as H3 currently does. > >>> > >>> There is already a demonstrated need for an application parameters > >>> mechanism in the QUIC handshake. One example is > >>> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 which is > >>> currently using a =E2=80=9Cweb_accepted_origins=E2=80=9D transport pa= rameter but could > >>> easily use an application parameters mechanism instead. > >>> > >>> I see two downsides to this proposal. The first is that the client=E2= =80=99s > >>> application parameters are sent in the clear. Application designers > >>> will need to make a decision of how much they want to use this > >>> functionality (they could limit what is sent by the client or only us= e > >>> application parameters in the server direction). For H3, there are > >>> only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, QPACK_BLOCKED_STREAMS, > >>> and MAX_HEADER_LIST_SIZE, which do not reveal any information about > >>> the user or the server they are connecting to and are likely constant > >>> per H3 implementation. > >>> > >>> The other downside is that if too much data is put in application > >>> parameters, it could cause the number of packets for a client or > >>> server=E2=80=99s flight to go from N to N+1, which would increase the= chance > >>> of head of line blocking. > >>> > >>> Related issues: > >>> https://github.com/quicwg/base-drafts/issues/2790: Binding settings > >>> into session tickets > >>> https://github.com/quicwg/base-drafts/issues/2945: When to send the > >>> SETTINGS frame > >>> https://github.com/quicwg/base-drafts/issues/2783: Consider making > >>> SETTINGS part of the control stream header > >>> https://github.com/quicwg/base-drafts/issues/436: Move SETTINGS into > >>> TLS Handshake > >>> > > --000000000000779b660593e271e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Additionally, the current status quo makes it hard to have= SETTINGS
play nicely with 0-RTT. Fixing this is important to deploying= IETF QUIC.
We're chartered to produce a protocol with fast connect= ion establishment,
and if we fail to negotiate options and extens= ions nicely with that, we'll
harm extensibility long-term and= cause deployment of damaging workarounds.

D= avid

On Tue, Oct 1, 2019 at 4:41 PM Nick Harper <nharper=3D40google.com@dmarc.ietf.org>= wrote:
I think = it loses most of its utility if it's not a v1 feature. The
main motivation for the feature is to simplify application protocols.
At the time that v2 is introduced and application protocols are being
specified to use it, existing application protocols will already have
an application-specific way to negotiate params, so they will continue
to use that instead of using both the existing application-specific
mechanism (for v1) and v2-only application parameters feature (for
v2+). (I'm assuming that as applications switch from using QUIC v1 to QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS 1.3, instead
of like upgrading H2 to H3.)

On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
> Does this need to be a 1.0 feature?
>
> On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie <ted.ietf@gmail.com> wrote:
>>
>> Hi Nick,
>>
>> Two points in addition to the privacy issue already raised make me= concur with Roberto that this should be v2 or later.=C2=A0 The first is th= is:
>>
>> "Negotiating or advertising features is something multiple ap= plicationswill need to do and is not a feature specific to H3."
>>
>> Absolutely true, but there is also a fairly large variability in h= ow applications do this.=C2=A0 If we design something now that works for H3= , it may very well be sub-optimal or useless for later application targets.= =C2=A0 Getting something general enough to handle DNS, WEBRTC,=C2=A0 SMTP, = plus the various flavors of IoT protocols I've heard as targets hoping = to move to QUIC is going to take time and care, and it will block completio= n of v1.
>>
>> The second is this:
>>
>> *The other downside is that if too much data is put in application= parameters, it could cause the number of packets for a client or server=E2= =80=99s flight to go from N to N+1, which would increase the chance of head= of line blocking.
>>
>> Depending on what counts as application parameters, this could be = more than N+1.=C2=A0 Someone running NETCONF over QUIC, for example, would = be using a fairly verbose syntax in which each parameter is a full URN.
>>
>> regards,
>>
>> Ted Hardie
>>
>>
>> On Thu, Sep 26, 2019 at 5:52 PM Nick Harper <nharper=3D40google.com@dmar= c.ietf.org> wrote:
>>>
>>> I propose introducing application parameters to the QUIC hands= hake and
>>> using this new mechanism for H3 SETTINGS instead of sending th= em as
>>> the first thing in the control stream. Application parameters = would
>>> allow applications using QUIC to advertise or negotiate
>>> application-specific parameters during the cryptographic and t= ransport
>>> handshake. It would guarantee that the client and server have<= br> >>> exchanged their application parameters once the handshake is c= omplete.
>>>
>>> Specifically, I=E2=80=99m proposing a new =E2=80=9Capplication= _layer_parameters=E2=80=9D
>>> transport parameter, which when sent by the client is a series= of ALPN
>>> identifiers with an opaque blob of application parameters per<= br> >>> identifier, and when sent by the server is a single opaque blo= b of
>>> application parameters for the application identified in the A= LPN
>>> extension.
>>>
>>> Negotiating or advertising features is something multiple appl= ications
>>> will need to do and is not a feature specific to H3. Whatever = we do in
>>> H3 will likely be copied by other applications using QUIC. By<= br> >>> providing a general mechanism in QUIC transport, we provide >>> applications with a consistent way of achieving this goal. QUI= C has a
>>> design pattern of collapsing multiple layers into one to save = on round
>>> trips (e.g. combining crypto and transport handshake); this fi= ts in
>>> with that pattern.
>>>
>>> Using application parameters for H3 SETTINGS clears up some is= sues. H3
>>> doesn=E2=80=99t need to specify that an endpoint shouldn=E2=80= =99t wait for its peer=E2=80=99s
>>> SETTINGS since they=E2=80=99ve already arrived. Likewise, ther= e is no
>>> confusion about whether SETTINGS arriving after session ticket= s are
>>> bound to the session tickets; SETTINGS arrives before the tick= ets and
>>> the client doesn=E2=80=99t need to wait for the receipt of SET= TINGS to bind
>>> them to the ticket. It also simplifies the server binding SETT= INGS to
>>> the ticket since that is done as part of binding transport par= ameters
>>> to the ticket.
>>>
>>> This also provides opportunities for future features. Since th= e
>>> exchange of SETTINGS occurs before application data, a new fea= ture
>>> doesn=E2=80=99t need to be specified in a way to provide an up= grade path from
>>> =E2=80=9Cvanilla=E2=80=9D H3 to something including this featu= re, and instead be
>>> guaranteed that the new feature can be used for the entire con= nection.
>>>
>>> Without application parameters, each application that needs to=
>>> advertise or negotiate application settings needs its own mech= anism to
>>> do so. This would result in multiple transport parameters or >>> extensions leading to duplication of work and layering violati= ons.
>>> Applications could instead exchange these settings in applicat= ion
>>> data, meaning that each application needs to define the semant= ics of
>>> application data received before and after the settings have b= een
>>> exchanged, as H3 currently does.
>>>
>>> There is already a demonstrated need for an application parame= ters
>>> mechanism in the QUIC handshake. One example is
>>> https://tools.ietf.org/html/d= raft-vvv-webtransport-quic-00 which is
>>> currently using a =E2=80=9Cweb_accepted_origins=E2=80=9D trans= port parameter but could
>>> easily use an application parameters mechanism instead.
>>>
>>> I see two downsides to this proposal. The first is that the cl= ient=E2=80=99s
>>> application parameters are sent in the clear. Application desi= gners
>>> will need to make a decision of how much they want to use this=
>>> functionality (they could limit what is sent by the client or = only use
>>> application parameters in the server direction). For H3, there= are
>>> only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, QPACK_BLOCKED_S= TREAMS,
>>> and MAX_HEADER_LIST_SIZE, which do not reveal any information = about
>>> the user or the server they are connecting to and are likely c= onstant
>>> per H3 implementation.
>>>
>>> The other downside is that if too much data is put in applicat= ion
>>> parameters, it could cause the number of packets for a client = or
>>> server=E2=80=99s flight to go from N to N+1, which would incre= ase the chance
>>> of head of line blocking.
>>>
>>> Related issues:
>>> https://github.com/quicwg/base-drafts/= issues/2790: Binding settings
>>> into session tickets
>>> https://github.com/quicwg/base-drafts/= issues/2945: When to send the
>>> SETTINGS frame
>>> https://github.com/quicwg/base-drafts/= issues/2783: Consider making
>>> SETTINGS part of the control stream header
>>> https://github.com/quicwg/base-drafts/i= ssues/436: Move SETTINGS into
>>> TLS Handshake
>>>

--000000000000779b660593e271e0-- From nobody Tue Oct 1 17:55:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3E012009E for ; Tue, 1 Oct 2019 17:55:31 -0700 (PDT) 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 94IjNueB-7r0 for ; Tue, 1 Oct 2019 17:55:29 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 D9B6212008B for ; Tue, 1 Oct 2019 17:55:28 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id n197so52893077iod.9 for ; Tue, 01 Oct 2019 17:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CcRsMlrwcCDc+8ZLQHFaB8G/KSqvEB8B0k1RyOP+uT0=; b=u45wYxsTurb1yfgLfplV7t9ApdtRO24iy+TUHokEDLpS2eSrHTOD+h5OgX/Q1OkIZr s4DN7mDoozfcYi+73m7SeuSOF/TahHnTQ5wW9r0mrpGZcI3CvC0WYh2nSWrPSj0/ZDgK a8tJJuQKocIpthe4JzMYlcQCs3M388NwAcBkyyUCHrdZ/pJ4FqWpc11EkRVralZAZ60L eeQ0HS+pZIn9K2XsNay/rXmcQ7Idu7Lt37K3gv5v6EEfqTTNSgll1c0IzWOB7A+Ec57Q NQ+hbvPzpZ1B/nSexjHViRZe0GiPk55NtNB//1xAJkUUT+P29ZWd+MixMaC1noy3Gynk PnxQ== 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=CcRsMlrwcCDc+8ZLQHFaB8G/KSqvEB8B0k1RyOP+uT0=; b=kO5fNsQ4zfrwkQWoQNm5+OOkrE9ixBCW54JI4yf9tzwsfsqEMbIWY1qVmhWc/pQYUb KEmH+KTIjiUu8zAVGH89tJpRU0ixTl1h0yfnuslLucVhEoZ9ACkamHYtTCZXWwYoS+qB mWoiNYWHXBVXOtFktbLgemhCT8kmyXW3uj7fCwryXQk9ABS6xcXKI/d/w7MPZj2ansJZ 7uiqJOWGR9sR6g2BLUXtB7LdUB8vWo27exArNuVVQGCRclA7RvKLgaI4RZWZ0qELV0KF 836OWsJwpbw+9td4CmEvXCvC0Hkt++ZgrWT0sJBKMnXuxe1En3jrn23nWLXK5YqT4Yba tMlw== X-Gm-Message-State: APjAAAVPP7FMCq2OcQ+muD0g40FkQWrYvssssa71WI6UxPxosASiLYJv 6bSwZtuIAJXyK0oXCsJNCB84/gcToSXWRByafgGxXqyw X-Google-Smtp-Source: APXvYqwC8pBobq5CiOcb5lc4K5esyeam2UBpD63oui9VCwrYddfhOAEn0wdbgdkJ+eLh/iceU48Mrj3zt3zqmyt/C5U= X-Received: by 2002:a92:4915:: with SMTP id w21mr1099504ila.121.1569977727935; Tue, 01 Oct 2019 17:55:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Tue, 1 Oct 2019 17:55:05 -0700 Message-ID: Subject: Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS To: Nick Harper Cc: Eric Rescorla , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000c76cd80593e2ec8b" 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, 02 Oct 2019 00:55:32 -0000 --000000000000c76cd80593e2ec8b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nick, On Tue, Oct 1, 2019 at 4:41 PM Nick Harper wrote: > I think it loses most of its utility if it's not a v1 feature. The > main motivation for the feature is to simplify application protocols. > At the time that v2 is introduced and application protocols are being > specified to use it, existing application protocols will already have > an application-specific way to negotiate params, so they will continue > to use that instead of using both the existing application-specific > mechanism (for v1) and v2-only application parameters feature (for > v2+). (I'm assuming that as applications switch from using QUIC v1 to > QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS 1.3, instead > of like upgrading H2 to H3.) > > There is no doubt there is a tension here, but if you look at our origina= l milestones (https://datatracker.ietf.org/wg/quic/history/) we are more than somewhat late. Having just sent one "Late, great WG name" message, I'm probably a bit more sensitive to this than most, but I strongly believe that getting QUIC v1 out there and getting field experience now is the best choice for the moment. This is a major design issue, and it is coming late when we are trying to raise the bar on change. If we didn't have a workable solution at all, this would be something that was clearly needed. But the current approach does work and has understood privacy properties. As I said, other applications may need substantially different things than H2 and getting something of sufficient generality will take time. The other option, specifying so its suits only H2 well is the other side of the risk you have above, and I believe it is a serious risk. Architectural purity is on your side, so I don't think you're wrong to want this. But I think it may be a want, not a need, at this point. And that is why my answer sides with Roberto. Just my personal opinion, Ted > On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla wrote: > > > > Does this need to be a 1.0 feature? > > > > On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie wrote: > >> > >> Hi Nick, > >> > >> Two points in addition to the privacy issue already raised make me > concur with Roberto that this should be v2 or later. The first is this: > >> > >> "Negotiating or advertising features is something multiple > applicationswill need to do and is not a feature specific to H3." > >> > >> Absolutely true, but there is also a fairly large variability in how > applications do this. If we design something now that works for H3, it m= ay > very well be sub-optimal or useless for later application targets. Getti= ng > something general enough to handle DNS, WEBRTC, SMTP, plus the various > flavors of IoT protocols I've heard as targets hoping to move to QUIC is > going to take time and care, and it will block completion of v1. > >> > >> The second is this: > >> > >> *The other downside is that if too much data is put in application > parameters, it could cause the number of packets for a client or server= =E2=80=99s > flight to go from N to N+1, which would increase the chance of head of li= ne > blocking. > >> > >> Depending on what counts as application parameters, this could be more > than N+1. Someone running NETCONF over QUIC, for example, would be using= a > fairly verbose syntax in which each parameter is a full URN. > >> > >> regards, > >> > >> Ted Hardie > >> > >> > >> On Thu, Sep 26, 2019 at 5:52 PM Nick Harper 40google.com@dmarc.ietf.org> wrote: > >>> > >>> I propose introducing application parameters to the QUIC handshake an= d > >>> using this new mechanism for H3 SETTINGS instead of sending them as > >>> the first thing in the control stream. Application parameters would > >>> allow applications using QUIC to advertise or negotiate > >>> application-specific parameters during the cryptographic and transpor= t > >>> handshake. It would guarantee that the client and server have > >>> exchanged their application parameters once the handshake is complete= . > >>> > >>> Specifically, I=E2=80=99m proposing a new =E2=80=9Capplication_layer_= parameters=E2=80=9D > >>> transport parameter, which when sent by the client is a series of ALP= N > >>> identifiers with an opaque blob of application parameters per > >>> identifier, and when sent by the server is a single opaque blob of > >>> application parameters for the application identified in the ALPN > >>> extension. > >>> > >>> Negotiating or advertising features is something multiple application= s > >>> will need to do and is not a feature specific to H3. Whatever we do i= n > >>> H3 will likely be copied by other applications using QUIC. By > >>> providing a general mechanism in QUIC transport, we provide > >>> applications with a consistent way of achieving this goal. QUIC has a > >>> design pattern of collapsing multiple layers into one to save on roun= d > >>> trips (e.g. combining crypto and transport handshake); this fits in > >>> with that pattern. > >>> > >>> Using application parameters for H3 SETTINGS clears up some issues. H= 3 > >>> doesn=E2=80=99t need to specify that an endpoint shouldn=E2=80=99t wa= it for its peer=E2=80=99s > >>> SETTINGS since they=E2=80=99ve already arrived. Likewise, there is no > >>> confusion about whether SETTINGS arriving after session tickets are > >>> bound to the session tickets; SETTINGS arrives before the tickets and > >>> the client doesn=E2=80=99t need to wait for the receipt of SETTINGS t= o bind > >>> them to the ticket. It also simplifies the server binding SETTINGS to > >>> the ticket since that is done as part of binding transport parameters > >>> to the ticket. > >>> > >>> This also provides opportunities for future features. Since the > >>> exchange of SETTINGS occurs before application data, a new feature > >>> doesn=E2=80=99t need to be specified in a way to provide an upgrade p= ath from > >>> =E2=80=9Cvanilla=E2=80=9D H3 to something including this feature, and= instead be > >>> guaranteed that the new feature can be used for the entire connection= . > >>> > >>> Without application parameters, each application that needs to > >>> advertise or negotiate application settings needs its own mechanism t= o > >>> do so. This would result in multiple transport parameters or > >>> extensions leading to duplication of work and layering violations. > >>> Applications could instead exchange these settings in application > >>> data, meaning that each application needs to define the semantics of > >>> application data received before and after the settings have been > >>> exchanged, as H3 currently does. > >>> > >>> There is already a demonstrated need for an application parameters > >>> mechanism in the QUIC handshake. One example is > >>> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 which is > >>> currently using a =E2=80=9Cweb_accepted_origins=E2=80=9D transport pa= rameter but could > >>> easily use an application parameters mechanism instead. > >>> > >>> I see two downsides to this proposal. The first is that the client=E2= =80=99s > >>> application parameters are sent in the clear. Application designers > >>> will need to make a decision of how much they want to use this > >>> functionality (they could limit what is sent by the client or only us= e > >>> application parameters in the server direction). For H3, there are > >>> only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, QPACK_BLOCKED_STREAMS, > >>> and MAX_HEADER_LIST_SIZE, which do not reveal any information about > >>> the user or the server they are connecting to and are likely constant > >>> per H3 implementation. > >>> > >>> The other downside is that if too much data is put in application > >>> parameters, it could cause the number of packets for a client or > >>> server=E2=80=99s flight to go from N to N+1, which would increase the= chance > >>> of head of line blocking. > >>> > >>> Related issues: > >>> https://github.com/quicwg/base-drafts/issues/2790: Binding settings > >>> into session tickets > >>> https://github.com/quicwg/base-drafts/issues/2945: When to send the > >>> SETTINGS frame > >>> https://github.com/quicwg/base-drafts/issues/2783: Consider making > >>> SETTINGS part of the control stream header > >>> https://github.com/quicwg/base-drafts/issues/436: Move SETTINGS into > >>> TLS Handshake > >>> > --000000000000c76cd80593e2ec8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nick,

On Tue, Oct 1, 2019 at 4:41 PM Nick Harpe= r <nharper@google.com> wrot= e:
I think it lo= ses most of its utility if it's not a v1 feature. The
main motivation for the feature is to simplify application protocols.
At the time that v2 is introduced and application protocols are being
specified to use it, existing application protocols will already have
an application-specific way to negotiate params, so they will continue
to use that instead of using both the existing application-specific
mechanism (for v1) and v2-only application parameters feature (for
v2+). (I'm assuming that as applications switch from using QUIC v1 to QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS 1.3, instead
of like upgrading H2 to H3.)

There is no doubt there is a tension here, but if you= look at our original milestones (https://datatracker.ietf.org/wg/quic/history/) we are = more than somewhat late.=C2=A0 Having just sent one "Late, great WG na= me" message, I'm probably a bit more sensitive to this than most, = but I strongly believe that getting QUIC v1 out there and getting field exp= erience now is the best choice for the moment.=C2=A0=C2=A0=C2=A0 This is a = major design issue, and it is coming late when we are trying to raise the b= ar on change.=C2=A0

If we didn't have a w= orkable solution at all, this would be something that was clearly needed.= =C2=A0 But the current approach does work and has understood privacy proper= ties. As I said, other applications may need substantially different things= than H2 and getting something of sufficient generality will take time.=C2= =A0 The other option, specifying so its suits only H2 well is the other sid= e of the risk you have above, and I believe it is a serious risk.=C2=A0

Architectural purity is on your side, so I don&#= 39;t think you're wrong to want this.=C2=A0 But I think it may be a wan= t, not a need, at this point.=C2=A0 And that is why my answer sides with Ro= berto.

Just my personal opinion,

Ted
=C2=A0
On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
> Does this need to be a 1.0 feature?
>
> On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie <ted.ietf@gmail.com> wrote:
>>
>> Hi Nick,
>>
>> Two points in addition to the privacy issue already raised make me= concur with Roberto that this should be v2 or later.=C2=A0 The first is th= is:
>>
>> "Negotiating or advertising features is something multiple ap= plicationswill need to do and is not a feature specific to H3."
>>
>> Absolutely true, but there is also a fairly large variability in h= ow applications do this.=C2=A0 If we design something now that works for H3= , it may very well be sub-optimal or useless for later application targets.= =C2=A0 Getting something general enough to handle DNS, WEBRTC,=C2=A0 SMTP, = plus the various flavors of IoT protocols I've heard as targets hoping = to move to QUIC is going to take time and care, and it will block completio= n of v1.
>>
>> The second is this:
>>
>> *The other downside is that if too much data is put in application= parameters, it could cause the number of packets for a client or server=E2= =80=99s flight to go from N to N+1, which would increase the chance of head= of line blocking.
>>
>> Depending on what counts as application parameters, this could be = more than N+1.=C2=A0 Someone running NETCONF over QUIC, for example, would = be using a fairly verbose syntax in which each parameter is a full URN.
>>
>> regards,
>>
>> Ted Hardie
>>
>>
>> On Thu, Sep 26, 2019 at 5:52 PM Nick Harper <nharper=3D40google.com@dmar= c.ietf.org> wrote:
>>>
>>> I propose introducing application parameters to the QUIC hands= hake and
>>> using this new mechanism for H3 SETTINGS instead of sending th= em as
>>> the first thing in the control stream. Application parameters = would
>>> allow applications using QUIC to advertise or negotiate
>>> application-specific parameters during the cryptographic and t= ransport
>>> handshake. It would guarantee that the client and server have<= br> >>> exchanged their application parameters once the handshake is c= omplete.
>>>
>>> Specifically, I=E2=80=99m proposing a new =E2=80=9Capplication= _layer_parameters=E2=80=9D
>>> transport parameter, which when sent by the client is a series= of ALPN
>>> identifiers with an opaque blob of application parameters per<= br> >>> identifier, and when sent by the server is a single opaque blo= b of
>>> application parameters for the application identified in the A= LPN
>>> extension.
>>>
>>> Negotiating or advertising features is something multiple appl= ications
>>> will need to do and is not a feature specific to H3. Whatever = we do in
>>> H3 will likely be copied by other applications using QUIC. By<= br> >>> providing a general mechanism in QUIC transport, we provide >>> applications with a consistent way of achieving this goal. QUI= C has a
>>> design pattern of collapsing multiple layers into one to save = on round
>>> trips (e.g. combining crypto and transport handshake); this fi= ts in
>>> with that pattern.
>>>
>>> Using application parameters for H3 SETTINGS clears up some is= sues. H3
>>> doesn=E2=80=99t need to specify that an endpoint shouldn=E2=80= =99t wait for its peer=E2=80=99s
>>> SETTINGS since they=E2=80=99ve already arrived. Likewise, ther= e is no
>>> confusion about whether SETTINGS arriving after session ticket= s are
>>> bound to the session tickets; SETTINGS arrives before the tick= ets and
>>> the client doesn=E2=80=99t need to wait for the receipt of SET= TINGS to bind
>>> them to the ticket. It also simplifies the server binding SETT= INGS to
>>> the ticket since that is done as part of binding transport par= ameters
>>> to the ticket.
>>>
>>> This also provides opportunities for future features. Since th= e
>>> exchange of SETTINGS occurs before application data, a new fea= ture
>>> doesn=E2=80=99t need to be specified in a way to provide an up= grade path from
>>> =E2=80=9Cvanilla=E2=80=9D H3 to something including this featu= re, and instead be
>>> guaranteed that the new feature can be used for the entire con= nection.
>>>
>>> Without application parameters, each application that needs to=
>>> advertise or negotiate application settings needs its own mech= anism to
>>> do so. This would result in multiple transport parameters or >>> extensions leading to duplication of work and layering violati= ons.
>>> Applications could instead exchange these settings in applicat= ion
>>> data, meaning that each application needs to define the semant= ics of
>>> application data received before and after the settings have b= een
>>> exchanged, as H3 currently does.
>>>
>>> There is already a demonstrated need for an application parame= ters
>>> mechanism in the QUIC handshake. One example is
>>> https://tools.ietf.org/html/d= raft-vvv-webtransport-quic-00 which is
>>> currently using a =E2=80=9Cweb_accepted_origins=E2=80=9D trans= port parameter but could
>>> easily use an application parameters mechanism instead.
>>>
>>> I see two downsides to this proposal. The first is that the cl= ient=E2=80=99s
>>> application parameters are sent in the clear. Application desi= gners
>>> will need to make a decision of how much they want to use this=
>>> functionality (they could limit what is sent by the client or = only use
>>> application parameters in the server direction). For H3, there= are
>>> only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, QPACK_BLOCKED_S= TREAMS,
>>> and MAX_HEADER_LIST_SIZE, which do not reveal any information = about
>>> the user or the server they are connecting to and are likely c= onstant
>>> per H3 implementation.
>>>
>>> The other downside is that if too much data is put in applicat= ion
>>> parameters, it could cause the number of packets for a client = or
>>> server=E2=80=99s flight to go from N to N+1, which would incre= ase the chance
>>> of head of line blocking.
>>>
>>> Related issues:
>>> https://github.com/quicwg/base-drafts/= issues/2790: Binding settings
>>> into session tickets
>>> https://github.com/quicwg/base-drafts/= issues/2945: When to send the
>>> SETTINGS frame
>>> https://github.com/quicwg/base-drafts/= issues/2783: Consider making
>>> SETTINGS part of the control stream header
>>> https://github.com/quicwg/base-drafts/i= ssues/436: Move SETTINGS into
>>> TLS Handshake
>>>
--000000000000c76cd80593e2ec8b-- From nobody Tue Oct 1 18:23:20 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A36412009E for ; Tue, 1 Oct 2019 18:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 IKiAnZa_k5eK for ; Tue, 1 Oct 2019 18:23:16 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 D3FFD120073 for ; Tue, 1 Oct 2019 18:23:15 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id u3so11377026lfl.10 for ; Tue, 01 Oct 2019 18:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5xfGGxjC23zl+3LNwLA7+gvYPdE9TA14Mwvqjwf4rvU=; b=qLAJH9HQOSosS9vXGWa/cL3obO8DQOdFpX+y1H/Fx4Bk5kVeI8lcQLHqTnYfCRrxu8 JZdDl98Aqzbnw7+M3suxPMbzmvSVfISMDtjw2Mo2veqTlk75JrmOULjD1dd/B2rXBjTI XYIg6dYamtNgDiyc6Peode6C0a/bV5xHwSO6yhx74aO3Wl+JrtEYDyy85U6GkK1yfRsy AkyMDbbZoKpP0VMCIJHV8GDHvRTH/06IzpT1QPSxtX0EpABoUguGyca4OZRDS16K1M0M vNsQtRUfZrhF9uCuIqt2+i0EKyz6a1Ygzkx+8aADAAkak2bnYrmbWFFFhjtM28A9kaZ4 Olqw== 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:content-transfer-encoding; bh=5xfGGxjC23zl+3LNwLA7+gvYPdE9TA14Mwvqjwf4rvU=; b=l/pCtT0qgHNKi65PpgTlzoQKekevt3xGOd7gbWS4laDyXkfEuxnqp/VeEvg7C5sg8S 5g4ACEGmS+5oUDUJiwB3zg4RGSpCRrTaCG1wZ5qtD8wusQuRs1CXq5c25mxGbx2U7X1O ybemVHdKf7fB/Z+fTyDe4g8n6oj5gtdDLM0MPgDHU+mgknbPv7Jia8v3b5dAIhlmxk8c 3uLWYSQ4/iBBBp70zxr7OSVaG/+M8bNLr2XS3FWPR8u9UXE1cbW+HadqCvXCgO5/7kom /IczIytVeCMvYPKo8zfY+vdnKwjsGE1nn6I3/CZtD4LV/sHaH/HAnZQUyzyrmqrTG3YT XA+g== X-Gm-Message-State: APjAAAW/1Jc8ksx3jHhL4vOjUr7rgJM1mAxizA1PHqG6CKuy96ox20/b pf9IHhvVas44Jj+LlpkRcczzDrbZV40X3HaU85U= X-Google-Smtp-Source: APXvYqyH25FyxAYf7uYOo4RCWnrVczemRJs5WdA/TVRX1S8EqG2tIo6jttUB4R4kDaoPQNS+LPp8yjojX5xBXSkX9dk= X-Received: by 2002:ac2:4a89:: with SMTP id l9mr360167lfp.122.1569979394080; Tue, 01 Oct 2019 18:23:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kazuho Oku Date: Wed, 2 Oct 2019 10:23:03 +0900 Message-ID: Subject: Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS To: David Schinazi Cc: Nick Harper , Eric Rescorla , IETF QUIC WG , Ted Hardie 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: Wed, 02 Oct 2019 01:23:18 -0000 2019=E5=B9=B410=E6=9C=882=E6=97=A5(=E6=B0=B4) 9:21 David Schinazi : > > Additionally, the current status quo makes it hard to have SETTINGS > play nicely with 0-RTT. Fixing this is important to deploying IETF QUIC. While I understand and share the pain, I am not sure if this should be a blocker for QUIC v1, as 0-RTT is essentially a must-implement for HTTP/3 (the primary application protocol for QUIC v1). 0-RTT requires clients (and servers) to operate without the knowledge of the settings that are sent by the server. Until the client receives the settings of the server and switches to using 1-RTT packets, the client is expected to use the settings of the previous connection. The server is expected to accept 0-RTT only if it knows that the settings parameters of that the client is using for 0-RTT. Assuming that we cannot remove this requirement, I do not think it's too complicated to require endpoints when using 1-RTT to operate without the knowledge of settings (i.e. operate with a very conservative set of properties) until it receives the settings from the peer. > We're chartered to produce a protocol with fast connection establishment, > and if we fail to negotiate options and extensions nicely with that, we'l= l > harm extensibility long-term and cause deployment of damaging workarounds= . > > David > > On Tue, Oct 1, 2019 at 4:41 PM Nick Harper wrote: >> >> I think it loses most of its utility if it's not a v1 feature. The >> main motivation for the feature is to simplify application protocols. >> At the time that v2 is introduced and application protocols are being >> specified to use it, existing application protocols will already have >> an application-specific way to negotiate params, so they will continue >> to use that instead of using both the existing application-specific >> mechanism (for v1) and v2-only application parameters feature (for >> v2+). (I'm assuming that as applications switch from using QUIC v1 to >> QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS 1.3, instead >> of like upgrading H2 to H3.) >> >> On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla wrote: >> > >> > Does this need to be a 1.0 feature? >> > >> > On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie wrote= : >> >> >> >> Hi Nick, >> >> >> >> Two points in addition to the privacy issue already raised make me co= ncur with Roberto that this should be v2 or later. The first is this: >> >> >> >> "Negotiating or advertising features is something multiple applicatio= nswill need to do and is not a feature specific to H3." >> >> >> >> Absolutely true, but there is also a fairly large variability in how = applications do this. If we design something now that works for H3, it may= very well be sub-optimal or useless for later application targets. Gettin= g something general enough to handle DNS, WEBRTC, SMTP, plus the various f= lavors of IoT protocols I've heard as targets hoping to move to QUIC is goi= ng to take time and care, and it will block completion of v1. >> >> >> >> The second is this: >> >> >> >> *The other downside is that if too much data is put in application pa= rameters, it could cause the number of packets for a client or server=E2=80= =99s flight to go from N to N+1, which would increase the chance of head of= line blocking. >> >> >> >> Depending on what counts as application parameters, this could be mor= e than N+1. Someone running NETCONF over QUIC, for example, would be using= a fairly verbose syntax in which each parameter is a full URN. >> >> >> >> regards, >> >> >> >> Ted Hardie >> >> >> >> >> >> On Thu, Sep 26, 2019 at 5:52 PM Nick Harper wrote: >> >>> >> >>> I propose introducing application parameters to the QUIC handshake a= nd >> >>> using this new mechanism for H3 SETTINGS instead of sending them as >> >>> the first thing in the control stream. Application parameters would >> >>> allow applications using QUIC to advertise or negotiate >> >>> application-specific parameters during the cryptographic and transpo= rt >> >>> handshake. It would guarantee that the client and server have >> >>> exchanged their application parameters once the handshake is complet= e. >> >>> >> >>> Specifically, I=E2=80=99m proposing a new =E2=80=9Capplication_layer= _parameters=E2=80=9D >> >>> transport parameter, which when sent by the client is a series of AL= PN >> >>> identifiers with an opaque blob of application parameters per >> >>> identifier, and when sent by the server is a single opaque blob of >> >>> application parameters for the application identified in the ALPN >> >>> extension. >> >>> >> >>> Negotiating or advertising features is something multiple applicatio= ns >> >>> will need to do and is not a feature specific to H3. Whatever we do = in >> >>> H3 will likely be copied by other applications using QUIC. By >> >>> providing a general mechanism in QUIC transport, we provide >> >>> applications with a consistent way of achieving this goal. QUIC has = a >> >>> design pattern of collapsing multiple layers into one to save on rou= nd >> >>> trips (e.g. combining crypto and transport handshake); this fits in >> >>> with that pattern. >> >>> >> >>> Using application parameters for H3 SETTINGS clears up some issues. = H3 >> >>> doesn=E2=80=99t need to specify that an endpoint shouldn=E2=80=99t w= ait for its peer=E2=80=99s >> >>> SETTINGS since they=E2=80=99ve already arrived. Likewise, there is n= o >> >>> confusion about whether SETTINGS arriving after session tickets are >> >>> bound to the session tickets; SETTINGS arrives before the tickets an= d >> >>> the client doesn=E2=80=99t need to wait for the receipt of SETTINGS = to bind >> >>> them to the ticket. It also simplifies the server binding SETTINGS t= o >> >>> the ticket since that is done as part of binding transport parameter= s >> >>> to the ticket. >> >>> >> >>> This also provides opportunities for future features. Since the >> >>> exchange of SETTINGS occurs before application data, a new feature >> >>> doesn=E2=80=99t need to be specified in a way to provide an upgrade = path from >> >>> =E2=80=9Cvanilla=E2=80=9D H3 to something including this feature, an= d instead be >> >>> guaranteed that the new feature can be used for the entire connectio= n. >> >>> >> >>> Without application parameters, each application that needs to >> >>> advertise or negotiate application settings needs its own mechanism = to >> >>> do so. This would result in multiple transport parameters or >> >>> extensions leading to duplication of work and layering violations. >> >>> Applications could instead exchange these settings in application >> >>> data, meaning that each application needs to define the semantics of >> >>> application data received before and after the settings have been >> >>> exchanged, as H3 currently does. >> >>> >> >>> There is already a demonstrated need for an application parameters >> >>> mechanism in the QUIC handshake. One example is >> >>> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 which is >> >>> currently using a =E2=80=9Cweb_accepted_origins=E2=80=9D transport p= arameter but could >> >>> easily use an application parameters mechanism instead. >> >>> >> >>> I see two downsides to this proposal. The first is that the client= =E2=80=99s >> >>> application parameters are sent in the clear. Application designers >> >>> will need to make a decision of how much they want to use this >> >>> functionality (they could limit what is sent by the client or only u= se >> >>> application parameters in the server direction). For H3, there are >> >>> only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, QPACK_BLOCKED_STREAMS= , >> >>> and MAX_HEADER_LIST_SIZE, which do not reveal any information about >> >>> the user or the server they are connecting to and are likely constan= t >> >>> per H3 implementation. >> >>> >> >>> The other downside is that if too much data is put in application >> >>> parameters, it could cause the number of packets for a client or >> >>> server=E2=80=99s flight to go from N to N+1, which would increase th= e chance >> >>> of head of line blocking. >> >>> >> >>> Related issues: >> >>> https://github.com/quicwg/base-drafts/issues/2790: Binding settings >> >>> into session tickets >> >>> https://github.com/quicwg/base-drafts/issues/2945: When to send the >> >>> SETTINGS frame >> >>> https://github.com/quicwg/base-drafts/issues/2783: Consider making >> >>> SETTINGS part of the control stream header >> >>> https://github.com/quicwg/base-drafts/issues/436: Move SETTINGS into >> >>> TLS Handshake >> >>> >> --=20 Kazuho Oku From nobody Wed Oct 2 14:21:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4951208B2 for ; Wed, 2 Oct 2019 14:21:11 -0700 (PDT) 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=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 k1M-9UaRba-q for ; Wed, 2 Oct 2019 14:21:06 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B83412029C for ; Wed, 2 Oct 2019 14:21:06 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id m13so343626ljj.11 for ; Wed, 02 Oct 2019 14:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2JB1QopW/OZ19kyDa8stDOkO27OBpMOV657l7HDV4tM=; b=Qz2ZO0iFvBIcO6S9VZzAw1G8A0Uaz2y9XSaDY7vLitCgFatXPIck0JYc5e+EdWbJ41 IZMjOIukVis/ggP2j/z7m5oazpa0xVN6TmUkwJqk0n1jpc7lda+GvV4L+DCi1FatNYdN 7rtFfg8udohpyE2YB2yvBPRQs+r1XkxskrXry4aw9B1AafOmKODIKYDxRFpZq2UOUqf7 vUsCAZ6rWRZDqVJ1K8O6mqBtYeXVmRepqzKeSpIthHtL3e9fBmLBm1TmMJE9eH/fPZt1 WVOGvVZkPxUW9XxBDTJaLh4VUZFDqLjxq5UcTbbpHtSQe9LLf6s7IVFs/RDzyeTi/PK2 CY3Q== 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=2JB1QopW/OZ19kyDa8stDOkO27OBpMOV657l7HDV4tM=; b=MPlb8yH9Jks24rxaFuCQelMnxhGLlC+C8jY4XqNJEMxqx2pHs3JSSuodrb26nJbbr5 Cb/ZSq9qX47FTu+xVHClQEgMhiOaEfntVAVBnoxhOXCcQdknzruEwvOEf1ujV32343W3 3DRr+H0oNGwAfbIR1KMBew9ZHPRzW5r+hoFb60MFXEeag76hbOsWDT+ZRSPpKWHDwlQs CwqgWeb6g00nP364LusPUFxou2K+PeW83aTWwS8AkzQFne4XFZMZD1W0Plh0ti86hcsC QadYrAYtyK4O46D+2UUC4XB2LDBjI8/l1dbc0sf1PF0kU5d/1hY+iUNtkDybolAkoFwd JliA== X-Gm-Message-State: APjAAAWlNsxgr/TWchytqlD3vi1vaR2P2tUZj1Ywsf17rtiE0oatqnlJ 6O/EB9mTTwurJOl2HcN8trunTZWUYxpi3xqa/Fc= X-Google-Smtp-Source: APXvYqzSXLn4ZV6kE8cvfqf4QK796qkxSGZ6AH6B9c45t5jVjvtW/BNk6mDdhjt20ceFCu4N9zylSpf8XrHYGOXMMxY= X-Received: by 2002:a2e:6a13:: with SMTP id f19mr3807422ljc.17.1570051264155; Wed, 02 Oct 2019 14:21:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Wed, 2 Oct 2019 14:20:52 -0700 Message-ID: Subject: Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS To: Kazuho Oku Cc: Nick Harper , Eric Rescorla , IETF QUIC WG , Ted Hardie Content-Type: multipart/alternative; boundary="000000000000e113240593f40b29" 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, 02 Oct 2019 21:21:12 -0000 --000000000000e113240593f40b29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If we decide that the first requests need to operate without knowledge of settings, we're effectively crippling the main extension mechanism we have in HTTP/3. I'm not comfortable saying that for the entire lifetime of QUICv1 we cannot have extensions that impact the first requests. That feels like painting ourselves into a corner. There are many features that we can punt out of QUICv1 and figure out later as extensions, but it's critical that we build an extension mechanism that allows that. On Tue, Oct 1, 2019 at 6:23 PM Kazuho Oku wrote: > 2019=E5=B9=B410=E6=9C=882=E6=97=A5(=E6=B0=B4) 9:21 David Schinazi : > > > > Additionally, the current status quo makes it hard to have SETTINGS > > play nicely with 0-RTT. Fixing this is important to deploying IETF QUIC= . > > While I understand and share the pain, I am not sure if this should be > a blocker for QUIC v1, as 0-RTT is essentially a must-implement for > HTTP/3 (the primary application protocol for QUIC v1). > > 0-RTT requires clients (and servers) to operate without the knowledge > of the settings that are sent by the server. Until the client receives > the settings of the server and switches to using 1-RTT packets, the > client is expected to use the settings of the previous connection. The > server is expected to accept 0-RTT only if it knows that the settings > parameters of that the client is using for 0-RTT. > > Assuming that we cannot remove this requirement, I do not think it's > too complicated to require endpoints when using 1-RTT to operate > without the knowledge of settings (i.e. operate with a very > conservative set of properties) until it receives the settings from > the peer. > > > We're chartered to produce a protocol with fast connection establishmen= t, > > and if we fail to negotiate options and extensions nicely with that, > we'll > > harm extensibility long-term and cause deployment of damaging > workarounds. > > > > David > > > > On Tue, Oct 1, 2019 at 4:41 PM Nick Harper 40google.com@dmarc.ietf.org> wrote: > >> > >> I think it loses most of its utility if it's not a v1 feature. The > >> main motivation for the feature is to simplify application protocols. > >> At the time that v2 is introduced and application protocols are being > >> specified to use it, existing application protocols will already have > >> an application-specific way to negotiate params, so they will continue > >> to use that instead of using both the existing application-specific > >> mechanism (for v1) and v2-only application parameters feature (for > >> v2+). (I'm assuming that as applications switch from using QUIC v1 to > >> QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS 1.3, instead > >> of like upgrading H2 to H3.) > >> > >> On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla wrote: > >> > > >> > Does this need to be a 1.0 feature? > >> > > >> > On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie > wrote: > >> >> > >> >> Hi Nick, > >> >> > >> >> Two points in addition to the privacy issue already raised make me > concur with Roberto that this should be v2 or later. The first is this: > >> >> > >> >> "Negotiating or advertising features is something multiple > applicationswill need to do and is not a feature specific to H3." > >> >> > >> >> Absolutely true, but there is also a fairly large variability in ho= w > applications do this. If we design something now that works for H3, it m= ay > very well be sub-optimal or useless for later application targets. Getti= ng > something general enough to handle DNS, WEBRTC, SMTP, plus the various > flavors of IoT protocols I've heard as targets hoping to move to QUIC is > going to take time and care, and it will block completion of v1. > >> >> > >> >> The second is this: > >> >> > >> >> *The other downside is that if too much data is put in application > parameters, it could cause the number of packets for a client or server= =E2=80=99s > flight to go from N to N+1, which would increase the chance of head of li= ne > blocking. > >> >> > >> >> Depending on what counts as application parameters, this could be > more than N+1. Someone running NETCONF over QUIC, for example, would be > using a fairly verbose syntax in which each parameter is a full URN. > >> >> > >> >> regards, > >> >> > >> >> Ted Hardie > >> >> > >> >> > >> >> On Thu, Sep 26, 2019 at 5:52 PM Nick Harper 40google.com@dmarc.ietf.org> wrote: > >> >>> > >> >>> I propose introducing application parameters to the QUIC handshake > and > >> >>> using this new mechanism for H3 SETTINGS instead of sending them a= s > >> >>> the first thing in the control stream. Application parameters woul= d > >> >>> allow applications using QUIC to advertise or negotiate > >> >>> application-specific parameters during the cryptographic and > transport > >> >>> handshake. It would guarantee that the client and server have > >> >>> exchanged their application parameters once the handshake is > complete. > >> >>> > >> >>> Specifically, I=E2=80=99m proposing a new =E2=80=9Capplication_lay= er_parameters=E2=80=9D > >> >>> transport parameter, which when sent by the client is a series of > ALPN > >> >>> identifiers with an opaque blob of application parameters per > >> >>> identifier, and when sent by the server is a single opaque blob of > >> >>> application parameters for the application identified in the ALPN > >> >>> extension. > >> >>> > >> >>> Negotiating or advertising features is something multiple > applications > >> >>> will need to do and is not a feature specific to H3. Whatever we d= o > in > >> >>> H3 will likely be copied by other applications using QUIC. By > >> >>> providing a general mechanism in QUIC transport, we provide > >> >>> applications with a consistent way of achieving this goal. QUIC ha= s > a > >> >>> design pattern of collapsing multiple layers into one to save on > round > >> >>> trips (e.g. combining crypto and transport handshake); this fits i= n > >> >>> with that pattern. > >> >>> > >> >>> Using application parameters for H3 SETTINGS clears up some issues= . > H3 > >> >>> doesn=E2=80=99t need to specify that an endpoint shouldn=E2=80=99t= wait for its > peer=E2=80=99s > >> >>> SETTINGS since they=E2=80=99ve already arrived. Likewise, there is= no > >> >>> confusion about whether SETTINGS arriving after session tickets ar= e > >> >>> bound to the session tickets; SETTINGS arrives before the tickets > and > >> >>> the client doesn=E2=80=99t need to wait for the receipt of SETTING= S to bind > >> >>> them to the ticket. It also simplifies the server binding SETTINGS > to > >> >>> the ticket since that is done as part of binding transport > parameters > >> >>> to the ticket. > >> >>> > >> >>> This also provides opportunities for future features. Since the > >> >>> exchange of SETTINGS occurs before application data, a new feature > >> >>> doesn=E2=80=99t need to be specified in a way to provide an upgrad= e path > from > >> >>> =E2=80=9Cvanilla=E2=80=9D H3 to something including this feature, = and instead be > >> >>> guaranteed that the new feature can be used for the entire > connection. > >> >>> > >> >>> Without application parameters, each application that needs to > >> >>> advertise or negotiate application settings needs its own mechanis= m > to > >> >>> do so. This would result in multiple transport parameters or > >> >>> extensions leading to duplication of work and layering violations. > >> >>> Applications could instead exchange these settings in application > >> >>> data, meaning that each application needs to define the semantics = of > >> >>> application data received before and after the settings have been > >> >>> exchanged, as H3 currently does. > >> >>> > >> >>> There is already a demonstrated need for an application parameters > >> >>> mechanism in the QUIC handshake. One example is > >> >>> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 which i= s > >> >>> currently using a =E2=80=9Cweb_accepted_origins=E2=80=9D transport= parameter but > could > >> >>> easily use an application parameters mechanism instead. > >> >>> > >> >>> I see two downsides to this proposal. The first is that the client= =E2=80=99s > >> >>> application parameters are sent in the clear. Application designer= s > >> >>> will need to make a decision of how much they want to use this > >> >>> functionality (they could limit what is sent by the client or only > use > >> >>> application parameters in the server direction). For H3, there are > >> >>> only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, > QPACK_BLOCKED_STREAMS, > >> >>> and MAX_HEADER_LIST_SIZE, which do not reveal any information abou= t > >> >>> the user or the server they are connecting to and are likely > constant > >> >>> per H3 implementation. > >> >>> > >> >>> The other downside is that if too much data is put in application > >> >>> parameters, it could cause the number of packets for a client or > >> >>> server=E2=80=99s flight to go from N to N+1, which would increase = the chance > >> >>> of head of line blocking. > >> >>> > >> >>> Related issues: > >> >>> https://github.com/quicwg/base-drafts/issues/2790: Binding setting= s > >> >>> into session tickets > >> >>> https://github.com/quicwg/base-drafts/issues/2945: When to send th= e > >> >>> SETTINGS frame > >> >>> https://github.com/quicwg/base-drafts/issues/2783: Consider making > >> >>> SETTINGS part of the control stream header > >> >>> https://github.com/quicwg/base-drafts/issues/436: Move SETTINGS > into > >> >>> TLS Handshake > >> >>> > >> > > > -- > Kazuho Oku > --000000000000e113240593f40b29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If we decide that the first requests need to operate witho= ut knowledge of settings,
we're effectively crippling the main exte= nsion mechanism we have in HTTP/3.
I'm not comfortable saying= that for the entire lifetime of QUICv1 we cannot have
extensions= that impact the first requests. That feels like painting ourselves into a = corner.

There are many features that we can punt o= ut of QUICv1 and figure out later as extensions,
but it's cri= tical that we build an extension mechanism that allows that.
On Tue, O= ct 1, 2019 at 6:23 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
2019=E5=B9=B410=E6=9C=882=E6=97=A5(=E6=B0=B4) 9:21 Davi= d Schinazi <dschinazi.ietf@gmail.com>:
>
> Additionally, the current status quo makes it hard to have SETTINGS > play nicely with 0-RTT. Fixing this is important to deploying IETF QUI= C.

While I understand and share the pain, I am not sure if this should be
a blocker for QUIC v1, as 0-RTT is essentially a must-implement for
HTTP/3 (the primary application protocol for QUIC v1).

0-RTT requires clients (and servers) to operate without the knowledge
of the settings that are sent by the server. Until the client receives
the settings of the server and switches to using 1-RTT packets, the
client is expected to use the settings of the previous connection. The
server is expected to accept 0-RTT only if it knows that the settings
parameters of that the client is using for 0-RTT.

Assuming that we cannot remove this requirement, I do not think it's too complicated to require endpoints when using 1-RTT to operate
without the knowledge of settings (i.e. operate with a very
conservative set of properties) until it receives the settings from
the peer.

> We're chartered to produce a protocol with fast connection establi= shment,
> and if we fail to negotiate options and extensions nicely with that, w= e'll
> harm extensibility long-term and cause deployment of damaging workarou= nds.
>
> David
>
> On Tue, Oct 1, 2019 at 4:41 PM Nick Harper <nharper=3D40google.com@dmarc.ietf= .org> wrote:
>>
>> I think it loses most of its utility if it's not a v1 feature.= The
>> main motivation for the feature is to simplify application protoco= ls.
>> At the time that v2 is introduced and application protocols are be= ing
>> specified to use it, existing application protocols will already h= ave
>> an application-specific way to negotiate params, so they will cont= inue
>> to use that instead of using both the existing application-specifi= c
>> mechanism (for v1) and v2-only application parameters feature (for=
>> v2+). (I'm assuming that as applications switch from using QUI= C v1 to
>> QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS 1.3, ins= tead
>> of like upgrading H2 to H3.)
>>
>> On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla <ekr@rtfm.com> wrote:
>> >
>> > Does this need to be a 1.0 feature?
>> >
>> > On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie <ted.ietf@gmail.com> wrote= :
>> >>
>> >> Hi Nick,
>> >>
>> >> Two points in addition to the privacy issue already raise= d make me concur with Roberto that this should be v2 or later.=C2=A0 The fi= rst is this:
>> >>
>> >> "Negotiating or advertising features is something mu= ltiple applicationswill need to do and is not a feature specific to H3.&quo= t;
>> >>
>> >> Absolutely true, but there is also a fairly large variabi= lity in how applications do this.=C2=A0 If we design something now that wor= ks for H3, it may very well be sub-optimal or useless for later application= targets.=C2=A0 Getting something general enough to handle DNS, WEBRTC,=C2= =A0 SMTP, plus the various flavors of IoT protocols I've heard as targe= ts hoping to move to QUIC is going to take time and care, and it will block= completion of v1.
>> >>
>> >> The second is this:
>> >>
>> >> *The other downside is that if too much data is put in ap= plication parameters, it could cause the number of packets for a client or = server=E2=80=99s flight to go from N to N+1, which would increase the chanc= e of head of line blocking.
>> >>
>> >> Depending on what counts as application parameters, this = could be more than N+1.=C2=A0 Someone running NETCONF over QUIC, for exampl= e, would be using a fairly verbose syntax in which each parameter is a full= URN.
>> >>
>> >> regards,
>> >>
>> >> Ted Hardie
>> >>
>> >>
>> >> On Thu, Sep 26, 2019 at 5:52 PM Nick Harper <nharper= =3D40googl= e.com@dmarc.ietf.org> wrote:
>> >>>
>> >>> I propose introducing application parameters to the Q= UIC handshake and
>> >>> using this new mechanism for H3 SETTINGS instead of s= ending them as
>> >>> the first thing in the control stream. Application pa= rameters would
>> >>> allow applications using QUIC to advertise or negotia= te
>> >>> application-specific parameters during the cryptograp= hic and transport
>> >>> handshake. It would guarantee that the client and ser= ver have
>> >>> exchanged their application parameters once the hands= hake is complete.
>> >>>
>> >>> Specifically, I=E2=80=99m proposing a new =E2=80=9Cap= plication_layer_parameters=E2=80=9D
>> >>> transport parameter, which when sent by the client is= a series of ALPN
>> >>> identifiers with an opaque blob of application parame= ters per
>> >>> identifier, and when sent by the server is a single o= paque blob of
>> >>> application parameters for the application identified= in the ALPN
>> >>> extension.
>> >>>
>> >>> Negotiating or advertising features is something mult= iple applications
>> >>> will need to do and is not a feature specific to H3. = Whatever we do in
>> >>> H3 will likely be copied by other applications using = QUIC. By
>> >>> providing a general mechanism in QUIC transport, we p= rovide
>> >>> applications with a consistent way of achieving this = goal. QUIC has a
>> >>> design pattern of collapsing multiple layers into one= to save on round
>> >>> trips (e.g. combining crypto and transport handshake)= ; this fits in
>> >>> with that pattern.
>> >>>
>> >>> Using application parameters for H3 SETTINGS clears u= p some issues. H3
>> >>> doesn=E2=80=99t need to specify that an endpoint shou= ldn=E2=80=99t wait for its peer=E2=80=99s
>> >>> SETTINGS since they=E2=80=99ve already arrived. Likew= ise, there is no
>> >>> confusion about whether SETTINGS arriving after sessi= on tickets are
>> >>> bound to the session tickets; SETTINGS arrives before= the tickets and
>> >>> the client doesn=E2=80=99t need to wait for the recei= pt of SETTINGS to bind
>> >>> them to the ticket. It also simplifies the server bin= ding SETTINGS to
>> >>> the ticket since that is done as part of binding tran= sport parameters
>> >>> to the ticket.
>> >>>
>> >>> This also provides opportunities for future features.= Since the
>> >>> exchange of SETTINGS occurs before application data, = a new feature
>> >>> doesn=E2=80=99t need to be specified in a way to prov= ide an upgrade path from
>> >>> =E2=80=9Cvanilla=E2=80=9D H3 to something including t= his feature, and instead be
>> >>> guaranteed that the new feature can be used for the e= ntire connection.
>> >>>
>> >>> Without application parameters, each application that= needs to
>> >>> advertise or negotiate application settings needs its= own mechanism to
>> >>> do so. This would result in multiple transport parame= ters or
>> >>> extensions leading to duplication of work and layerin= g violations.
>> >>> Applications could instead exchange these settings in= application
>> >>> data, meaning that each application needs to define t= he semantics of
>> >>> application data received before and after the settin= gs have been
>> >>> exchanged, as H3 currently does.
>> >>>
>> >>> There is already a demonstrated need for an applicati= on parameters
>> >>> mechanism in the QUIC handshake. One example is
>> >>> https://tools.ietf.o= rg/html/draft-vvv-webtransport-quic-00 which is
>> >>> currently using a =E2=80=9Cweb_accepted_origins=E2=80= =9D transport parameter but could
>> >>> easily use an application parameters mechanism instea= d.
>> >>>
>> >>> I see two downsides to this proposal. The first is th= at the client=E2=80=99s
>> >>> application parameters are sent in the clear. Applica= tion designers
>> >>> will need to make a decision of how much they want to= use this
>> >>> functionality (they could limit what is sent by the c= lient or only use
>> >>> application parameters in the server direction). For = H3, there are
>> >>> only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, QPACK_= BLOCKED_STREAMS,
>> >>> and MAX_HEADER_LIST_SIZE, which do not reveal any inf= ormation about
>> >>> the user or the server they are connecting to and are= likely constant
>> >>> per H3 implementation.
>> >>>
>> >>> The other downside is that if too much data is put in= application
>> >>> parameters, it could cause the number of packets for = a client or
>> >>> server=E2=80=99s flight to go from N to N+1, which wo= uld increase the chance
>> >>> of head of line blocking.
>> >>>
>> >>> Related issues:
>> >>> https://github.com/quicwg/bas= e-drafts/issues/2790: Binding settings
>> >>> into session tickets
>> >>> https://github.com/quicwg/bas= e-drafts/issues/2945: When to send the
>> >>> SETTINGS frame
>> >>> https://github.com/quicwg/bas= e-drafts/issues/2783: Consider making
>> >>> SETTINGS part of the control stream header
>> >>> https://github.com/quicwg/base= -drafts/issues/436: Move SETTINGS into
>> >>> TLS Handshake
>> >>>
>>


--
Kazuho Oku
--000000000000e113240593f40b29-- From nobody Wed Oct 2 16:50:18 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E1A12021C for ; Wed, 2 Oct 2019 16:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 gxVWHcmSGu9M for ; Wed, 2 Oct 2019 16:50:06 -0700 (PDT) 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 C3C43120108 for ; Wed, 2 Oct 2019 16:50:05 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id c195so352885lfg.9 for ; Wed, 02 Oct 2019 16:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=H8F4aRAlUbLGjr3+9jjTFrqaujdI3hkfsn4iLMwuAls=; b=HAGlWjOUzFRoEbA88hHHkCF55eCBDhRt5sEjq31weIYbe9DRuY/z+lRaYz/oIQH6/N 10qY/cY7v7Os0BSBnv8eN+wo1et3A/7jL+7ua9iG4yqOvhvj7dIHHTrNfPhpiBwb8Aoy HPUPiZhIWWgIhQ8WSzmMoWm0w3ROL1MtF8RM13tpQzzfv8ib7q4OoNxZWNtrSXSXNvk/ noZ15jX9nU35xX2B7fixAfB978tEHoUQ3McYJNjicyi9rFx5Dn/UTPMLJP3N/RMEhUca kWZ39e1PIVEV2EE7Q0D2GO63RxiEPgKVFgspcooPYqBMNxfF9jZd15tp9NsmghMhXNig 5S9Q== 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:content-transfer-encoding; bh=H8F4aRAlUbLGjr3+9jjTFrqaujdI3hkfsn4iLMwuAls=; b=GoxQWb12ux7OYX4QZTrusiCiN3/tY7RF0dpO16Rt+0zlgySvApgx2X5Wwi86p9ITBp 1LZ2phgwKF5bB5n+eL91mAcjvMb/abC4HndftemoASxcIkSzipIDQumij/K7MIQJEpZB 1wxBAep+63QBC4ucza9uNrly6FvPAoqYvoC8SN8WAro55AFLcsof5D3pkOfrbGjGBd9P 5p0URhVXMRfxhwU1//MpgjMqka9WIq+a8AgIDwRP+5uXV16p7t5RT0QTrNlyX53zWDfh OX8kWF2YVZAD7f+JVIJ5CZV4BVhGK0y0uV2UptXMAPR73/dSWRYuK/TNqHR1zHGdRre+ SD6Q== X-Gm-Message-State: APjAAAURDCkhqqJguv5nWoqUklhtVOMA0rsbK8440EIrHF6YSZvsjbot Ouapq8BCIqE15DQWoz/1qGCXpykx/3exVNpVqhI= X-Google-Smtp-Source: APXvYqyoHr2azE/E2yaVdFlGvWTedo6KTacYflsCjTh3zYJlUmmw0aUf8/xpD+9kkjU3sNQqb5uI9qy153cE8Vtq6dE= X-Received: by 2002:a19:3f47:: with SMTP id m68mr3851354lfa.108.1570060203901; Wed, 02 Oct 2019 16:50:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kazuho Oku Date: Thu, 3 Oct 2019 08:49:49 +0900 Message-ID: Subject: Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS To: David Schinazi Cc: Nick Harper , Eric Rescorla , IETF QUIC WG , Ted Hardie 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: Wed, 02 Oct 2019 23:50:12 -0000 2019=E5=B9=B410=E6=9C=883=E6=97=A5(=E6=9C=A8) 6:21 David Schinazi : > > If we decide that the first requests need to operate without knowledge of= settings, > we're effectively crippling the main extension mechanism we have in HTTP/= 3. > I'm not comfortable saying that for the entire lifetime of QUICv1 we cann= ot have > extensions that impact the first requests. That feels like painting ourse= lves into a corner. > > There are many features that we can punt out of QUICv1 and figure out lat= er as extensions, > but it's critical that we build an extension mechanism that allows that. For HTTP/3, I think that we'd likely be fine with not having settings delivered before issuing requests. That's how HTTP/2 has been, and we are used to dealing with that. Though admittedly, QPACK is more disciplined on what can be done in such case compared to HPACK. Other application protocols using QUIC v1 can define their own TP, if having settings exchanged before 1-RTT data becomes a critical issue for them. > > On Tue, Oct 1, 2019 at 6:23 PM Kazuho Oku wrote: >> >> 2019=E5=B9=B410=E6=9C=882=E6=97=A5(=E6=B0=B4) 9:21 David Schinazi : >> > >> > Additionally, the current status quo makes it hard to have SETTINGS >> > play nicely with 0-RTT. Fixing this is important to deploying IETF QUI= C. >> >> While I understand and share the pain, I am not sure if this should be >> a blocker for QUIC v1, as 0-RTT is essentially a must-implement for >> HTTP/3 (the primary application protocol for QUIC v1). >> >> 0-RTT requires clients (and servers) to operate without the knowledge >> of the settings that are sent by the server. Until the client receives >> the settings of the server and switches to using 1-RTT packets, the >> client is expected to use the settings of the previous connection. The >> server is expected to accept 0-RTT only if it knows that the settings >> parameters of that the client is using for 0-RTT. >> >> Assuming that we cannot remove this requirement, I do not think it's >> too complicated to require endpoints when using 1-RTT to operate >> without the knowledge of settings (i.e. operate with a very >> conservative set of properties) until it receives the settings from >> the peer. >> >> > We're chartered to produce a protocol with fast connection establishme= nt, >> > and if we fail to negotiate options and extensions nicely with that, w= e'll >> > harm extensibility long-term and cause deployment of damaging workarou= nds. >> > >> > David >> > >> > On Tue, Oct 1, 2019 at 4:41 PM Nick Harper wrote: >> >> >> >> I think it loses most of its utility if it's not a v1 feature. The >> >> main motivation for the feature is to simplify application protocols. >> >> At the time that v2 is introduced and application protocols are being >> >> specified to use it, existing application protocols will already have >> >> an application-specific way to negotiate params, so they will continu= e >> >> to use that instead of using both the existing application-specific >> >> mechanism (for v1) and v2-only application parameters feature (for >> >> v2+). (I'm assuming that as applications switch from using QUIC v1 to >> >> QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS 1.3, instea= d >> >> of like upgrading H2 to H3.) >> >> >> >> On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla wrote: >> >> > >> >> > Does this need to be a 1.0 feature? >> >> > >> >> > On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie wr= ote: >> >> >> >> >> >> Hi Nick, >> >> >> >> >> >> Two points in addition to the privacy issue already raised make me= concur with Roberto that this should be v2 or later. The first is this: >> >> >> >> >> >> "Negotiating or advertising features is something multiple applica= tionswill need to do and is not a feature specific to H3." >> >> >> >> >> >> Absolutely true, but there is also a fairly large variability in h= ow applications do this. If we design something now that works for H3, it = may very well be sub-optimal or useless for later application targets. Get= ting something general enough to handle DNS, WEBRTC, SMTP, plus the variou= s flavors of IoT protocols I've heard as targets hoping to move to QUIC is = going to take time and care, and it will block completion of v1. >> >> >> >> >> >> The second is this: >> >> >> >> >> >> *The other downside is that if too much data is put in application= parameters, it could cause the number of packets for a client or server=E2= =80=99s flight to go from N to N+1, which would increase the chance of head= of line blocking. >> >> >> >> >> >> Depending on what counts as application parameters, this could be = more than N+1. Someone running NETCONF over QUIC, for example, would be us= ing a fairly verbose syntax in which each parameter is a full URN. >> >> >> >> >> >> regards, >> >> >> >> >> >> Ted Hardie >> >> >> >> >> >> >> >> >> On Thu, Sep 26, 2019 at 5:52 PM Nick Harper wrote: >> >> >>> >> >> >>> I propose introducing application parameters to the QUIC handshak= e and >> >> >>> using this new mechanism for H3 SETTINGS instead of sending them = as >> >> >>> the first thing in the control stream. Application parameters wou= ld >> >> >>> allow applications using QUIC to advertise or negotiate >> >> >>> application-specific parameters during the cryptographic and tran= sport >> >> >>> handshake. It would guarantee that the client and server have >> >> >>> exchanged their application parameters once the handshake is comp= lete. >> >> >>> >> >> >>> Specifically, I=E2=80=99m proposing a new =E2=80=9Capplication_la= yer_parameters=E2=80=9D >> >> >>> transport parameter, which when sent by the client is a series of= ALPN >> >> >>> identifiers with an opaque blob of application parameters per >> >> >>> identifier, and when sent by the server is a single opaque blob o= f >> >> >>> application parameters for the application identified in the ALPN >> >> >>> extension. >> >> >>> >> >> >>> Negotiating or advertising features is something multiple applica= tions >> >> >>> will need to do and is not a feature specific to H3. Whatever we = do in >> >> >>> H3 will likely be copied by other applications using QUIC. By >> >> >>> providing a general mechanism in QUIC transport, we provide >> >> >>> applications with a consistent way of achieving this goal. QUIC h= as a >> >> >>> design pattern of collapsing multiple layers into one to save on = round >> >> >>> trips (e.g. combining crypto and transport handshake); this fits = in >> >> >>> with that pattern. >> >> >>> >> >> >>> Using application parameters for H3 SETTINGS clears up some issue= s. H3 >> >> >>> doesn=E2=80=99t need to specify that an endpoint shouldn=E2=80=99= t wait for its peer=E2=80=99s >> >> >>> SETTINGS since they=E2=80=99ve already arrived. Likewise, there i= s no >> >> >>> confusion about whether SETTINGS arriving after session tickets a= re >> >> >>> bound to the session tickets; SETTINGS arrives before the tickets= and >> >> >>> the client doesn=E2=80=99t need to wait for the receipt of SETTIN= GS to bind >> >> >>> them to the ticket. It also simplifies the server binding SETTING= S to >> >> >>> the ticket since that is done as part of binding transport parame= ters >> >> >>> to the ticket. >> >> >>> >> >> >>> This also provides opportunities for future features. Since the >> >> >>> exchange of SETTINGS occurs before application data, a new featur= e >> >> >>> doesn=E2=80=99t need to be specified in a way to provide an upgra= de path from >> >> >>> =E2=80=9Cvanilla=E2=80=9D H3 to something including this feature,= and instead be >> >> >>> guaranteed that the new feature can be used for the entire connec= tion. >> >> >>> >> >> >>> Without application parameters, each application that needs to >> >> >>> advertise or negotiate application settings needs its own mechani= sm to >> >> >>> do so. This would result in multiple transport parameters or >> >> >>> extensions leading to duplication of work and layering violations= . >> >> >>> Applications could instead exchange these settings in application >> >> >>> data, meaning that each application needs to define the semantics= of >> >> >>> application data received before and after the settings have been >> >> >>> exchanged, as H3 currently does. >> >> >>> >> >> >>> There is already a demonstrated need for an application parameter= s >> >> >>> mechanism in the QUIC handshake. One example is >> >> >>> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 which = is >> >> >>> currently using a =E2=80=9Cweb_accepted_origins=E2=80=9D transpor= t parameter but could >> >> >>> easily use an application parameters mechanism instead. >> >> >>> >> >> >>> I see two downsides to this proposal. The first is that the clien= t=E2=80=99s >> >> >>> application parameters are sent in the clear. Application designe= rs >> >> >>> will need to make a decision of how much they want to use this >> >> >>> functionality (they could limit what is sent by the client or onl= y use >> >> >>> application parameters in the server direction). For H3, there ar= e >> >> >>> only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, QPACK_BLOCKED_STRE= AMS, >> >> >>> and MAX_HEADER_LIST_SIZE, which do not reveal any information abo= ut >> >> >>> the user or the server they are connecting to and are likely cons= tant >> >> >>> per H3 implementation. >> >> >>> >> >> >>> The other downside is that if too much data is put in application >> >> >>> parameters, it could cause the number of packets for a client or >> >> >>> server=E2=80=99s flight to go from N to N+1, which would increase= the chance >> >> >>> of head of line blocking. >> >> >>> >> >> >>> Related issues: >> >> >>> https://github.com/quicwg/base-drafts/issues/2790: Binding settin= gs >> >> >>> into session tickets >> >> >>> https://github.com/quicwg/base-drafts/issues/2945: When to send t= he >> >> >>> SETTINGS frame >> >> >>> https://github.com/quicwg/base-drafts/issues/2783: Consider makin= g >> >> >>> SETTINGS part of the control stream header >> >> >>> https://github.com/quicwg/base-drafts/issues/436: Move SETTINGS i= nto >> >> >>> TLS Handshake >> >> >>> >> >> >> >> >> -- >> Kazuho Oku --=20 Kazuho Oku From nobody Sat Oct 5 17:45:23 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6207012001E for ; Sat, 5 Oct 2019 17:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=f6riCEK4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ffgpOD20 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXtB_TGUtt4F for ; Sat, 5 Oct 2019 17:45:19 -0700 (PDT) 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 7DE2812004A for ; Sat, 5 Oct 2019 17:45:19 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 982283CF for ; Sat, 5 Oct 2019 20:45:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 05 Oct 2019 20:45:18 -0400 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= fm3; bh=Tm3Na/Hb5U3KiO4x5znNoKPK09c97aW871N8rrG8zuI=; b=f6riCEK4 YOu0j96fcMyX12PDS9OipiWo/KM/rbGbGGXyxj/2/bAZOgFf85TNaBjeadV/bupk pzLZ/YADQ7Vc75cSbHK244nvd3xNCGmVvecewRlh02XqRtjuLp6xRpoYNkNu3Ofh eDdfOo3DG/zmGcMwvXUCAKub0LOzg1lpKm4UvdPJ7inelVtXeuKGH8EPV//YLTob UtYuL/8iSSwpIm1wuUOS5dPORjwjVMEQagljRv3LwpM7MAGRnpV8VyTxvpGDFIwL shVck/Ee6z3Y+Fv6tPc3YCPlMtUtv0+YGPTRnXn/FPOkexF0J8kgnFQCq5d3Vy6W vZLksopBk7ooVQ== 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=fm3; bh=Tm3Na/Hb5U3KiO4x5znNoKPK09c97 aW871N8rrG8zuI=; b=ffgpOD20ZSzVq761AjZ2Pb/j2qPLghlhDAgMwZ7h/RmuV VahN/n4foD6mot6v8levHUjUCFtNC90m12o8Hp8eB2QbuHCwlXzIALBypUFhFssA 5xPIpzAELw7j9IUm1YqGoRc1uJdgl8YtfAUll2Ri1hRrJ82mjC9mS1TV9SmQKwWC JfR+jYvEVGRgoLWBqw60DShAN6BMP/AQexiWLGgB4kJhBtAUtIEhDyBkgX5GaSgh sIa7AI/b5d5nMjbC5eoc6nBmVwnBojDjKMYQnSvkATHrhGLlMb3pa9Bv9VF19lcu Giq0o1M0EkERpVgHsBbqmk8BgWQL8H5x7O5uUJ1yA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheeggddtiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgspgfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc fkphepudduledrledrgeefrddvgedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id E44C78005A for ; Sat, 5 Oct 2019 20:45:16 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 8E60FC03FA for ; Sun, 6 Oct 2019 00:45:12 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============4604614339136004366==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20191006004512.8E60FC03FA@cloud.mnot.net> Date: Sun, 6 Oct 2019 00:45:12 +0000 (UTC) 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, 06 Oct 2019 00:45:23 -0000 --===============4604614339136004366== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+6/-1/=F0=9F=92=AC28) 6 issues created: - Lost Server Initial Takes Too Long to be Retransmitted (by nibanks) https://github.com/quicwg/base-drafts/issues/3078 = - SRTT vs. smoothed_rtt in quic-recovery (by jrudolph) https://github.com/quicwg/base-drafts/issues/3076 = - Discussion in quic-recovery of delayed ack being 25ms does not seem to = relate to anything (by jrudolph) https://github.com/quicwg/base-drafts/issues/3075 = - Probe packet section needs to suggest a crypto context (by martinduke) https://github.com/quicwg/base-drafts/issues/3074 = - Boolean blocked streams setting (by bencebeky) https://github.com/quicwg/base-drafts/issues/3073 = - Mention unidirectional Stream Types 2 and 3 (QPACK) in -http (by Lekens= teyn) https://github.com/quicwg/base-drafts/issues/3071 = 13 issues received 28 new comments: - #3053 Padding requirement seems to be incorrect. (6 by DavidSchinazi, e= kr, mikkelfj) https://github.com/quicwg/base-drafts/issues/3053 [-transport] [design]= [proposal-ready] = - #3073 Boolean blocked streams setting (5 by kazuho, tatsuhiro-t, dtikho= nov, afrind, ianswett) https://github.com/quicwg/base-drafts/issues/3073 [-qpack] [design] = - #3046 Handling of Retire Prior To field (3 by kazuho, MikeBishop, niban= ks) https://github.com/quicwg/base-drafts/issues/3046 [-transport] = - #3074 Probe packet section needs to suggest a crypto context (2 by mart= induke, ianswett) https://github.com/quicwg/base-drafts/issues/3074 [-recovery] = - #3075 Discussion in quic-recovery of delayed ack being 25ms does not se= em to relate to anything (2 by ianswett) https://github.com/quicwg/base-drafts/issues/3075 [-recovery] [editoria= l] = - #3078 Lost Server Initial Takes Too Long to be Retransmitted (2 by mart= en-seemann, nibanks) https://github.com/quicwg/base-drafts/issues/3078 = - #3061 Unclear what to do when QUIC Version Hints are missing (2 by Davi= dSchinazi, MikeBishop) https://github.com/quicwg/base-drafts/issues/3061 [-http] = - #3076 SRTT vs. smoothed_rtt in quic-recovery (1 by mikkelfj) https://github.com/quicwg/base-drafts/issues/3076 [-recovery] [editoria= l] = - #2152 Why does stateless reset have to be checked after MAC failure (1 = by ekr) https://github.com/quicwg/base-drafts/issues/2152 [-transport] [design]= [proposal-ready] = - #3020 Transport parameter registry is too constraining for innovation (= 1 by ekr) https://github.com/quicwg/base-drafts/issues/3020 [-transport] [design] = - #3063 http: Allow unquoted tokens in Alt-Svc quic parameter (1 by Leken= steyn) https://github.com/quicwg/base-drafts/issues/3063 [-http] = - #3014 Handling of corrupt Retry packets (1 by mikkelfj) https://github.com/quicwg/base-drafts/issues/3014 [-transport] [design] = - #3034 Allow PING in Initial/Handshake? (1 by martinduke) https://github.com/quicwg/base-drafts/issues/3034 [-tls] [-transport] [= design] [proposal-ready] = 1 issues closed: - ACK-eliciting vs ack-eliciting https://github.com/quicwg/base-drafts/is= sues/3068 [-recovery] [-transport] [editorial] = Pull requests ------------- * quicwg/base-drafts (+2/-1/=F0=9F=92=AC1) 2 pull requests submitted: - Remove obsolete 'Discussion' section (by ianswett) https://github.com/quicwg/base-drafts/pull/3077 [-transport] = - Added implementation status section (by hamchaoui) https://github.com/quicwg/base-drafts/pull/3072 = 1 pull requests received 1 new comments: - #3072 Added implementation status section (1 by hamchaoui) https://github.com/quicwg/base-drafts/pull/3072 = 1 pull requests merged: - ack-eliciting not ACK-eliciting https://github.com/quicwg/base-drafts/pull/3069 [-transport] [editorial= ] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============4604614339136004366== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday October 06, 2019

Issues

quicwg/base-drafts (+6/-1/=F0=9F=92=AC28)

6 issues created:

13 issues received 28 new comments:

1 issues closed:

Pull requests

quicwg/base-drafts (+2/-1/=F0=9F=92=AC1)

2 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============4604614339136004366==-- From antdl@microsoft.com Mon Oct 7 10:01:30 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2420012007A for ; Mon, 7 Oct 2019 10:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=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 CRV2wUfJHjWZ for ; Mon, 7 Oct 2019 10:01:27 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80139.outbound.protection.outlook.com [40.107.8.139]) (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 DF2DB120043 for ; Mon, 7 Oct 2019 10:01:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jhCECRaa/KJt3a4+E9nJ+FaEN0F7/qQVhw7pSfnuJhz8nfWxjW+wwFPcfzSCNb0y9iiM8aD5fDJqPr6cyTyYYT4D96BZNbYuy0Zt8QWwPMlX2ht5kAriX5F0KBhrykHX4e4GFPrqI8BiN5TqMKEkU8eZ1XZWYVrkL1EefFIu9+80HCx/kCqeWDZM6U+nWx+sPOW0WWYKP28+fuaVulVRggp0uT4GpWlSolbaAuHPU06DuksxdymFZhxfhVKedt865hG402QH4KFosjmX2/+FS9YBBKsg8qezJu7msAvNCWeHCjtbAvsjHMmopjBMY+NjOX9eE10Mb/kflVUJjfPQZg== 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=0vPDhAZAoTR1eI1J+JZKjdh7sLTB4EV1N258913oi40=; b=T5tyW2V7vnzTkym3EIof8FXXH9wOeXUS7K1CD4rx2pJ4jCStLXYWRMLojISdlSgvjPgAuX4r9N8PgZ4XwKH7EfAnz9dBDp+hlJgPnTBJhOttx+mg77tjgASEtp3E9mr0JtaHaMXCiA4T1BXgWQEF9cba+DbKyHw9ftANQ1Dd174ftsg+zOg/WVrnhMdI2bRS7pmyBvvi49wywfrKJevz64R+dTOaPV5SgyMOyvrS2sCwq6dZoJKnghyjzWVHcmT2wzV+Y1647Os2E29NkNRM+uIiiUpIZl6m+DHFJXPZtZ6TT1aXUw1hS/a/nG9toz0ZjHZKBxu44YlfDZJ2tyLotg== 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=0vPDhAZAoTR1eI1J+JZKjdh7sLTB4EV1N258913oi40=; b=BtBZ3uadNCq5FngOSoZk4I9tE+i/RJfZILfzDmUjBcQyi3kTPNclgN8K1cskSsuG+CJP/cJCGPOQPBBxFdHrlQa+gO8C+/wGdH/R8cqw3Sp9gjyiVzD4R8/0tQYiw3sIQtpC2w7gMhYHXhpX8sdLwUP105o0VL/FI1hm8WHhcSA= Received: from VI1PR83MB0352.EURPRD83.prod.outlook.com (10.165.198.149) by VI1PR83MB0270.EURPRD83.prod.outlook.com (20.176.180.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2367.3; Mon, 7 Oct 2019 17:01:24 +0000 Received: from VI1PR83MB0352.EURPRD83.prod.outlook.com ([fe80::394d:ea47:c2fc:9fc0]) by VI1PR83MB0352.EURPRD83.prod.outlook.com ([fe80::394d:ea47:c2fc:9fc0%8]) with mapi id 15.20.2347.015; Mon, 7 Oct 2019 17:01:23 +0000 From: Antoine Delignat-Lavaud To: QUIC Working Group Subject: Announcing the QUIC Privacy & Security Workshop @ NDSS (Feb 23-26 2020) Thread-Topic: Announcing the QUIC Privacy & Security Workshop @ NDSS (Feb 23-26 2020) Thread-Index: AdV9LJf3ByrGMywdSYWM+FEb8a1JGw== Date: Mon, 7 Oct 2019 17:01:23 +0000 Message-ID: Accept-Language: en-GB, 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=antdl@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-07T17:01:21.6065286Z; 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=055ee52c-af8a-4ea9-b047-63b30f763992; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=antdl@microsoft.com; x-originating-ip: [213.205.242.95] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 228658a2-8acf-4bd0-8e82-08d74b47fc09 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: VI1PR83MB0270:|VI1PR83MB0270: x-ms-exchange-transport-forked: True x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-o365-sonar-daas-pilot: True x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(366004)(136003)(39860400002)(346002)(376002)(189003)(199004)(22452003)(2906002)(86362001)(790700001)(15650500001)(3846002)(2420400007)(316002)(54896002)(6436002)(6116002)(256004)(55016002)(236005)(14454004)(9686003)(6306002)(606006)(14444005)(7696005)(10090500001)(486006)(55236004)(6916009)(26005)(6506007)(102836004)(476003)(25786009)(33656002)(186003)(478600001)(7736002)(966005)(74316002)(10290500003)(99286004)(8936002)(81166006)(81156014)(8676002)(66066001)(5660300002)(8990500004)(52536014)(64756008)(66946007)(71190400001)(66446008)(66476007)(76116006)(66556008)(71200400001)(66574012)(7110500001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR83MB0270; H:VI1PR83MB0352.EURPRD83.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: 0YcWcZqSSiK3nMYmP9hhz2fmp+fek1TyKs7EmvkTPbpy2z4MGjA7ytv2Iqk1CndEJzh1xuRwC+aYwdZ73yvUkp5AgDkKUECj2ze4+dZhmt9QuHnqmoAik0I2ALCptekyvUPPMj7mQeOTOrvPLKTpyyihpJVkifJsgv0ks8qViuS36TCOowpEqOIIzoFQoZ8jA0jnp6pEQe++y75JFezGnb9T+UDTRFJc7HeZ5SngcNTCN3tmFW0V0KI1cJyeHdbgHTqm/ycsdJcGRt7vQkHR+iwemD2h2oFUrBvuuxTRWz4CQ4oNF4d1XQER9e5lUIMXV3r29CQp+/bedIjrPEFTf6G+4FLKUtVdiYAhZHuZB3OeYXECof6w5wFuJY9Xk/AtBnHKOk2ypxxqRElO30zAhguP7sCAiFul+wHx0JpZfUNs7PNgXOZBXyq6NvEV/K1Iy3IBfLQFUqZbBbU11oZO8A== Content-Type: multipart/alternative; boundary="_000_VI1PR83MB0352500096DDCDC303C0E18AB29B0VI1PR83MB0352EURP_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 228658a2-8acf-4bd0-8e82-08d74b47fc09 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2019 17:01:23.7121 (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: 0Ar+UwyT5oQIF9UW55YKazyVkqjexk7owiL6WYnEXtSVvc5RxROuJB24wWPOR52vqwtom9/wXCWttfxNAfxoPQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR83MB0270 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, 07 Oct 2019 17:02:17 -0000 --_000_VI1PR83MB0352500096DDCDC303C0E18AB29B0VI1PR83MB0352EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Full call for papers: https://www.ndss-symposium.org/ndss2020/cfp-quic-priv= acy-and-security-workshop/ We are pleased to announce that the Network and Distributed System Security= symposium (NDSS, organized by the Internet Society) will be hosting a QUIC= Privacy & Security [QUIPS] workshop next year. The goal of this workshop i= s to bring security analysis results reviewed by a panel of academic and in= dustrial experts to the attention of the QUIC working group and developer c= ommunities in order to build confidence in and improve QUIC before its wide= spread deployment. We are seeking contributions covering many aspects of th= e design and implantation of QUIC, including (but not limited to): * Integration with the TLS 1.3 handshake: QUIC is designed to re-use th= e TLS 1.3 [RFC8446] authenticated key exchange protocol that produces the t= raffic secrets used to encrypt QUIC packets. While the TLS 1.3 key exchange= protocol has received extensive formal analysis effort during its standard= ization, QUIC's modular use of the TLS handshake to generate secrets and au= thenticate negotiated transport parameters has not received as much attenti= on. Some of the properties of TLS 1.3, such as the authentication by the ha= ndshake of the termination of 0-RTT data by the "end of early data" message= , rely on assumptions that hold for the TLS record layer, but not for the Q= UIC record layer. * Packet protection: analysis of TLS assume reliable, ordered delivery = of network messages, which does not hold in QUIC. The effect of packet loss= on QUIC's record layer security is important and not well understood. More= over, QUIC's record layer provides features that TLS does not, such as head= er protection. Capturing the semantics of this new packet protection algori= thm and proving its security is critical. * Denial of Service (DoS) features: QUIC has a number of features desig= ned to reduce the effects of DoS, both on individual connections, such as d= uplicate packet detection and complete packet protection, server resources,= such as Retry, and the resources of bystanders, such as anti-reflection. I= t has yet to be shown whether or not these techniques achieve their desired= goals. * Privacy: many of QUIC's new features account for and attempt to mitig= ate the linkability of packets to users across network paths and between co= nnections. For example, voluntary connection migration requires endpoints t= o use new connection identifiers if possible as a way of preventing cross-p= ath linkability. Also, as a means of improving endpoint privacy postures, a= mong others, QUIC does not mandate endpoints provide any way for networks t= o measure per-connection Round Trip Time (RTT). The optional spin bit is th= e only signal made willingly available to the network. Currently, there is = no strong analysis supporting the concrete privacy benefits these features = provide to QUIC endpoints. * Application security: while TLS exposes a socket-based send/recv inte= rface, QUIC integrates most of the dynamic stream multiplexing interface fr= om HTTP/2. Applications must target this new interface, leading to new prot= ocols such as HTTP/3. The security implications of the new transport interf= ace for legacy and new applications are not well studied. For instance, it = is unclear how an application can tell apart which parts of incoming messag= es have been protected with the 0-RTT or the 1-RTT secret. Submissions are due on December 13 and must be submitted to https://easycha= ir.org/conferences/?conf=3Dquips20 Registration to the workshop will be part of the registration process for N= DSS (TBA on https://www.ndss-symposium.org/) We are looking forward to see you best work towards making a QUIC a secure = protocol. Best regards, The QUIPS Chairs Antoine Delignat-Lavaud & Christopher Wood --_000_VI1PR83MB0352500096DDCDC303C0E18AB29B0VI1PR83MB0352EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Full call for papers: https://www.ndss-symposium.org/ndss2020/cfp-quic-privacy-and-security-works= hop/

 

We are pleased to announce that the Network and Dist= ributed System Security symposium (NDSS, organized by the Internet Society)= will be hosting a QUIC Privacy & Security [QUIPS] workshop next year. = The goal of this workshop is to bring security analysis results reviewed by a panel of academic and industrial e= xperts to the attention of the QUIC working group and developer communities= in order to build confidence in and improve QUIC before its widespread dep= loyment. We are seeking contributions covering many aspects of the design and implantation of QUIC, including (b= ut not limited to):

  • Integration with the TLS 1.3 handshake: QUIC is designed to re-use the TLS = 1.3 [RFC8446] authenticated key exchange protocol that produces the traffic= secrets used to encrypt QUIC packets. While the TLS 1.3 key exchange proto= col has received extensive formal analysis effort during its standardization, QUIC’s modular use of th= e TLS handshake to generate secrets and authenticate negotiated transport p= arameters has not received as much attention. Some of the properties of TLS= 1.3, such as the authentication by the handshake of the termination of 0-RTT data by the “end of early data= ” message, rely on assumptions that hold for the TLS record layer, bu= t not for the QUIC record layer.

  • Packet protection: analysis of TLS assume reliable, ordered delivery of net= work messages, which does not hold in QUIC. The effect of packet loss on QU= IC’s record layer security is important and not well understood. More= over, QUIC’s record layer provides features that TLS does not, such as header protection. Capturing the semantics of t= his new packet protection algorithm and proving its security is critical.
  • Denial of Service (DoS) features: QUIC has a number of features designed to= reduce the effects of DoS, both on individual connections, such as duplica= te packet detection and complete packet protection, server resources, such = as Retry, and the resources of bystanders, such as anti-reflection. It has yet to be shown whether or not these techn= iques achieve their desired goals.

  • Privacy: many of QUIC’s new features account for and attempt to mitig= ate the linkability of packets to users across network paths and between co= nnections. For example, voluntary connection migration requires endpoints t= o use new connection identifiers if possible as a way of preventing cross-path linkability. Also, as a means of improvi= ng endpoint privacy postures, among others, QUIC does not mandate endpoints= provide any way for networks to measure per-connection Round Trip Time (RT= T). The optional spin bit is the only signal made willingly available to the network. Currently, there is n= o strong analysis supporting the concrete privacy benefits these features p= rovide to QUIC endpoints.

  • Application security: while TLS exposes a socket-based send/recv interface,= QUIC integrates most of the dynamic stream multiplexing interface from HTT= P/2. Applications must target this new interface, leading to new protocols = such as HTTP/3. The security implications of the new transport interface for legacy and new applications are not wel= l studied. For instance, it is unclear how an application can tell apart wh= ich parts of incoming messages have been protected with the 0-RTT or the 1-= RTT secret.

 

Submissions are due on December 13 and must be submi= tted to https://easychair.org/conferences/?conf=3Dquips20

Registration to the workshop will be part of the reg= istration process for NDSS (TBA on https://www.ndss-symposium.org/= )

 

We are looking forward to see you best work towards = making a QUIC a secure protocol.

 

Best regards,

The QUIPS Chairs

Antoine Delignat-Lavaud & Christopher Wood<= /o:p>

--_000_VI1PR83MB0352500096DDCDC303C0E18AB29B0VI1PR83MB0352EURP_-- From nobody Mon Oct 7 10:22:20 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423681200B3 for ; Mon, 7 Oct 2019 10:22:19 -0700 (PDT) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VSQ-zITf-18Y for ; Mon, 7 Oct 2019 10:22:17 -0700 (PDT) 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 A5461120071 for ; Mon, 7 Oct 2019 10:22:16 -0700 (PDT) Received: from xse100.mail2web.com ([66.113.196.100] helo=xse.mail2web.com) by mx63.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iHWi5-0004Hr-KL for quic@ietf.org; Mon, 07 Oct 2019 19:22:14 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46n6f40RhVz7V78 for ; Mon, 7 Oct 2019 10:19:08 -0700 (PDT) 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 1iHWf5-0003Cw-UB for quic@ietf.org; Mon, 07 Oct 2019 10:19:07 -0700 Received: (qmail 13261 invoked from network); 7 Oct 2019 17:19:07 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Oct 2019 17:19:07 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-1E2E68E4-A371-4CD8-B335-841C73B15594 Content-Transfer-Encoding: 7bit From: Christian Huitema Mime-Version: 1.0 (1.0) Subject: Re: Announcing the QUIC Privacy & Security Workshop @ NDSS (Feb 23-26 2020) Date: Mon, 7 Oct 2019 10:19:06 -0700 Message-Id: References: Cc: QUIC Working Group In-Reply-To: To: Antoine Delignat-Lavaud X-Mailer: iPhone Mail (17A860) X-Originating-IP: 66.113.196.100 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.100/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.100/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ezqdolHG91LK5q2HN6uCHCpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fuc/ygxh5kciL2xDa/5Pc3PU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+5aB4itzNZ07CdqP+KMfGjQPLhBThvdgyPN49yzDQzRHY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhMjx7v77N42Z/zX3DQBtZa/0j9rMdVQseW3F+doIupqmER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnOu9dHI/x63E XXKWrOjLtA8Ya0DFhKR0reMjbnA+hNVVxS5wmcBtKi2ekFKqDSpuSTKR6RgQ6scM/oDJnhhySxkp l3vNQ2phMy7KWpS14/+amhlKb/lC+C9AijoWgc8vkIGThCScvU0cCIiHSQbmcVKw6dluZZE7Q7VU Z5fKaRPeIPeg9WrzDXOtahmLPdT6/AhUquDeP1ZVPFlovgIWt6LNH+LbDqQKWY8Kslp3kEVAXPWl FdaGOH191uXjgjQN/RTaYTLUj/RFhcnr3QktcdiAsKf8YkYlSSEiWomXrhiQ1vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM= X-Report-Abuse-To: spam@quarantine9.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: Mon, 07 Oct 2019 17:22:20 -0000 --Apple-Mail-1E2E68E4-A371-4CD8-B335-841C73B15594 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Will you consider remote participation to the workshop? -- Christian Huitema=20 > On Oct 7, 2019, at 10:02 AM, Antoine Delignat-Lavaud wrote: >=20 > =EF=BB=BF > Full call for papers: https://www.ndss-symposium.org/ndss2020/cfp-quic-pri= vacy-and-security-workshop/ > =20 > We are pleased to announce that the Network and Distributed System Securit= y symposium (NDSS, organized by the Internet Society) will be hosting a QUIC= Privacy & Security [QUIPS] workshop next year. The goal of this workshop is= to bring security analysis results reviewed by a panel of academic and indu= strial experts to the attention of the QUIC working group and developer comm= unities in order to build confidence in and improve QUIC before its widespre= ad deployment. We are seeking contributions covering many aspects of the des= ign and implantation of QUIC, including (but not limited to): >=20 > Integration with the TLS 1.3 handshake: QUIC is designed to re-use the TLS= 1.3 [RFC8446] authenticated key exchange protocol that produces the traffic= secrets used to encrypt QUIC packets. While the TLS 1.3 key exchange protoc= ol has received extensive formal analysis effort during its standardization,= QUIC=E2=80=99s modular use of the TLS handshake to generate secrets and aut= henticate negotiated transport parameters has not received as much attention= . Some of the properties of TLS 1.3, such as the authentication by the hands= hake of the termination of 0-RTT data by the =E2=80=9Cend of early data=E2=80= =9D message, rely on assumptions that hold for the TLS record layer, but not= for the QUIC record layer. >=20 > Packet protection: analysis of TLS assume reliable, ordered delivery of ne= twork messages, which does not hold in QUIC. The effect of packet loss on QU= IC=E2=80=99s record layer security is important and not well understood. Mor= eover, QUIC=E2=80=99s record layer provides features that TLS does not, such= as header protection. Capturing the semantics of this new packet protection= algorithm and proving its security is critical. >=20 > Denial of Service (DoS) features: QUIC has a number of features designed t= o reduce the effects of DoS, both on individual connections, such as duplica= te packet detection and complete packet protection, server resources, such a= s Retry, and the resources of bystanders, such as anti-reflection. It has ye= t to be shown whether or not these techniques achieve their desired goals. >=20 > Privacy: many of QUIC=E2=80=99s new features account for and attempt to mi= tigate the linkability of packets to users across network paths and between c= onnections. For example, voluntary connection migration requires endpoints t= o use new connection identifiers if possible as a way of preventing cross-pa= th linkability. Also, as a means of improving endpoint privacy postures, amo= ng others, QUIC does not mandate endpoints provide any way for networks to m= easure per-connection Round Trip Time (RTT). The optional spin bit is the on= ly signal made willingly available to the network. Currently, there is no st= rong analysis supporting the concrete privacy benefits these features provid= e to QUIC endpoints. >=20 > Application security: while TLS exposes a socket-based send/recv interface= , QUIC integrates most of the dynamic stream multiplexing interface from HTT= P/2. Applications must target this new interface, leading to new protocols s= uch as HTTP/3. The security implications of the new transport interface for l= egacy and new applications are not well studied. For instance, it is unclear= how an application can tell apart which parts of incoming messages have bee= n protected with the 0-RTT or the 1-RTT secret. > =20 > Submissions are due on December 13 and must be submitted to https://easych= air.org/conferences/?conf=3Dquips20 > Registration to the workshop will be part of the registration process for N= DSS (TBA on https://www.ndss-symposium.org/) > =20 > We are looking forward to see you best work towards making a QUIC a secure= protocol. > =20 > Best regards, > The QUIPS Chairs > Antoine Delignat-Lavaud & Christopher Wood --Apple-Mail-1E2E68E4-A371-4CD8-B335-841C73B15594 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Will you consider remote participation to t= he workshop?

-- Christian Huitema 

On Oct 7, 2019, at 10:02 AM, Antoine= Delignat-Lavaud <antdl=3D40microsoft.com@dmarc.ietf.org> wrote:
=EF=BB=BF =

Full call for papers: https://www.ndss-symposium.org/ndss2020/cfp-quic-privacy-and-security-worksh= op/

 

We are pleased to announce that the Network and Distr= ibuted System Security symposium (NDSS, organized by the Internet Society) w= ill be hosting a QUIC Privacy & Security [QUIPS] workshop next year. The= goal of this workshop is to bring security analysis results reviewed by a panel of academic and industrial ex= perts to the attention of the QUIC working group and developer communities i= n order to build confidence in and improve QUIC before its widespread deploy= ment. We are seeking contributions covering many aspects of the design and implantation of QUIC, including (bu= t not limited to):

  • Integration with the TLS 1.3 handshake: QUIC is designed to re-use the TLS 1= .3 [RFC8446] authenticated key exchange protocol that produces the traffic s= ecrets used to encrypt QUIC packets. While the TLS 1.3 key exchange protocol= has received extensive formal analysis effort during its standardization, QUIC=E2=80=99s modular use of t= he TLS handshake to generate secrets and authenticate negotiated transport p= arameters has not received as much attention. Some of the properties of TLS 1= .3, such as the authentication by the handshake of the termination of 0-RTT data by the =E2=80=9Cend of early dat= a=E2=80=9D message, rely on assumptions that hold for the TLS record layer, b= ut not for the QUIC record layer.

  • Packet protection: analysis of TLS assume reliable, ordered delivery of netw= ork messages, which does not hold in QUIC. The effect of packet loss on QUIC= =E2=80=99s record layer security is important and not well understood. Moreo= ver, QUIC=E2=80=99s record layer provides features that TLS does not, such as header protection. Capturing the semantics of th= is new packet protection algorithm and proving its security is critical.
    =
  • Denial of Service (DoS) features: QUIC has a number of features designed to r= educe the effects of DoS, both on individual connections, such as duplicate p= acket detection and complete packet protection, server resources, such as Re= try, and the resources of bystanders, such as anti-reflection. It has yet to be shown whether or not these techni= ques achieve their desired goals.

  • Privacy: many of QUIC=E2=80=99s new features account for and attempt to miti= gate the linkability of packets to users across network paths and between co= nnections. For example, voluntary connection migration requires endpoints to= use new connection identifiers if possible as a way of preventing cross-path linkability. Also, as a means of improvin= g endpoint privacy postures, among others, QUIC does not mandate endpoints p= rovide any way for networks to measure per-connection Round Trip Time (RTT).= The optional spin bit is the only signal made willingly available to the network. Currently, there is no= strong analysis supporting the concrete privacy benefits these features pro= vide to QUIC endpoints.

  • Application security: while TLS exposes a socket-based send/recv interface, Q= UIC integrates most of the dynamic stream multiplexing interface from HTTP/2= . Applications must target this new interface, leading to new protocols such= as HTTP/3. The security implications of the new transport interface for legacy and new applications are not well= studied. For instance, it is unclear how an application can tell apart whic= h parts of incoming messages have been protected with the 0-RTT or the 1-RTT= secret.

 

Submissions are due on December 13 and must be submit= ted to https://easychair.org/conferences/?conf=3Dquips20

Registration to the workshop will be part of the regi= stration process for NDSS (TBA on https://www.ndss-symposium.org/<= /a>)

 

We are looking forward to see you best work towards m= aking a QUIC a secure protocol.

 

Best regards,

The QUIPS Chairs

Antoine Delignat-Lavaud & Christopher Wood

= --Apple-Mail-1E2E68E4-A371-4CD8-B335-841C73B15594-- From nobody Tue Oct 8 23:34:22 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05214120088 for ; Tue, 8 Oct 2019 23:34:21 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 FfktikA8O9ji for ; Tue, 8 Oct 2019 23:34:18 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B22E120019 for ; Tue, 8 Oct 2019 23:34:18 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id A89444005C for ; Wed, 9 Oct 2019 09:34:16 +0300 (EEST) Received: from slate.eggert.org (Slate.eggert.org [172.19.235.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 54D138449C1 for ; Wed, 9 Oct 2019 09:34:10 +0300 (EEST) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_7AAAA686-2B15-4FEB-AC3A-F59D50756E81"; protocol="application/pgp-signature"; micalg=pgp-sha512 Reply-To: tsvwg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Fwd: [tsvwg] WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019 Date: Wed, 9 Oct 2019 09:34:09 +0300 References: To: QUIC IETF mailing list Message-Id: <68B30800-1D1F-4F2D-8416-71051C1AC303@eggert.org> X-MailScanner-ID: 54D138449C1.A198C 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: Wed, 09 Oct 2019 06:34:21 -0000 --Apple-Mail=_7AAAA686-2B15-4FEB-AC3A-F59D50756E81 Content-Type: multipart/alternative; boundary="Apple-Mail=_B74BF7E8-95BA-4025-983E-D45D6D11E434" --Apple-Mail=_B74BF7E8-95BA-4025-983E-D45D6D11E434 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This draft is of obvious interest to the QUIC WG. Please send last-call = comments to tsvwg@ietf.org . Lars Begin forwarded message: >=20 > From: "Black, David" > Subject: [tsvwg] WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes = 23 October 2019 > Date: October 9, 2019 at 0:05:31 GMT+3 > To: "tsvwg@ietf.org" >=20 > This email announces a TSVWG Working Group Last Call (WGLC) on: >=20 > The Impact of Transport Header Confidentiality on Network Operation = and > Evolution of the Internet > draft-ietf-tsvwg-transport-encrypt-08 > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ = >=20 > This draft is intended to become an Informational RFC. >=20 > This WGLC will run through the end of the day on Wednesday, October = 23. > That should allow time before the Singapore draft submission cutoff = for > the authors to revise the draft with any changes that result from = WGLC. >=20 > Comments should be sent to the tsvwg@ietf.org = list, although purely > editorial comments may be sent directly to the authors. Please cc: the > WG chairs at tsvwg-chairs@ietf.org if = you would like the chairs to > track such editorial comments as part of the WGLC process. >=20 > No IPR disclosures have been submitted directly on this draft. >=20 > Thanks, > David, Gorry and Wes > (TSVWG Co-Chairs) --Apple-Mail=_B74BF7E8-95BA-4025-983E-D45D6D11E434 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = draft is of obvious interest to the QUIC WG. Please send last-call = comments to tsvwg@ietf.org.

Lars

Begin = forwarded message:

From: = "Black, David" <David.Black@dell.com>
Subject: = [tsvwg] WGLC: = draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
Date: = October 9, 2019 at 0:05:31 = GMT+3
To: = "tsvwg@ietf.org" <tsvwg@ietf.org>

This = email announces a TSVWG Working Group Last Call (WGLC) on:
 
The = Impact of Transport Header Confidentiality on Network Operation and
          &nb= sp;            = Evolution of the Internet
          &nb= sp;      = draft-ietf-tsvwg-transport-encrypt-08
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-enc= rypt/
 
This draft is intended to become an Informational RFC.
 
This WGLC = will run through the end of the day on Wednesday, October 23.
That = should allow time before the Singapore draft submission cutoff for
the = authors to revise the draft with any changes that result from WGLC.
 
Comments = should be sent to the tsvwg@ietf.org list, although purely
editorial = comments may be sent directly to the authors. Please cc: the
WG chairs = at tsvwg-chairs@ietf.org  = if you would like the chairs to
track such editorial comments as part = of the WGLC process.
 
No IPR disclosures have been submitted directly on this = draft.
 
Thanks,
David, Gorry and Wes
(TSVWG = Co-Chairs)

= --Apple-Mail=_B74BF7E8-95BA-4025-983E-D45D6D11E434-- --Apple-Mail=_7AAAA686-2B15-4FEB-AC3A-F59D50756E81 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl2df2EACgkQVLXDCb9w wVd5Eg/+OeJgrJpyQriRDZ3tctjqLQYQ1zYRAs4hZWKpOtR6GOcIUdlpyjUyae0J uAeOssQGhU0boTGU8XqGTZk6wRObetechEgXM0IEvreb+PPUnd+eFU90hfC7A8fb idiejG40gCA3kR4lN6bZVNtgN3ihS7A4C/BXdKETeZKD8ufdS399kHHnGqdgYFUR d0t5jwwij1j3v2t+HkwJA9rk35rJenIExf1951eISzocYKlBjpbxezyuAeNyF5Xm zIbqOHUQE0Nz05I8X3fnf+BUd+XcFGuwQ/WZrDgJ/RhLesUq69/FczHtzb3alq4g Y1DoDmPg0DUwKM9RPH1A1zwxrul67lqtnBw02CVp1k2lg4ZuwcNzIeseMUS9Z9jQ mcpTNcz+C/WkZ+q+ZNa4MSKXVeAb7b2eZqH0TQCRJjaBKyxXKGEU+Z7FaiEw+fU1 9KLrhPqtZr4/yK2CSkqOX2R4igOdpTCEXqQ/c0gXOnL5dybmsMf8rRbm6dJpwS8e orPAFN1EGfjSCSuxMSAlk1n9gnQmpDjo4FOMv39hxdyQeKcsmLtV1m7eLXH6tLAV 9iSej1eI8dp8+3QEKpxX8cJJJKFwRtohAj4HV4NIbl7vZ2iGesHO+TDy0gcqwuox gNtHKHRs7N8SAvhl22VG2uHvVylfyBHGTXlqMKlI2GcchI3pkcM= =rXiU -----END PGP SIGNATURE----- --Apple-Mail=_7AAAA686-2B15-4FEB-AC3A-F59D50756E81-- From nobody Wed Oct 9 02:14:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192DF1200A3 for ; Wed, 9 Oct 2019 02:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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, HTTPS_HTTP_MISMATCH=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=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 hTTWXU2siGK5 for ; Wed, 9 Oct 2019 02:14:03 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00131.outbound.protection.outlook.com [40.107.0.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6212120047 for ; Wed, 9 Oct 2019 02:14:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NALlAxk4a3eAQrwJaFk3aNjhsSpTtcD69uKiAgL3Q0HkWvgTMSj3yrc2UPm5jEaaRLR2dJ+LgD6OP/ppP0zvPcef0T+BVzU0a1e+O9Put3uhzSFG8O4N4ghJjSNAxvXp8pvjgPmG7RFsLr9kh1/5Bou6Cg3y/ejBilE/n8aT8vwLzLzZFaQWe34JmCuRdMzjN46QH6F8EckzQIz5lXjEimeCiW7x6lBtSfzqpOlzNCRFENGzh9sO+RRl71kYuLXIGUhaH0VglM57Z3Q4Ut/9ArBf3olhlmdwzLuCxwCYw1msssPkXWMxans2yfS08NPZRUCSrgGrFTeCAMSPo833gQ== 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=wTagtU7siCrfJ4lftq+qW3HP8WAwwYXSyJjLwIPGL40=; b=RijI7Q9TW6W/vPE8PnRhmzex0mO5Qx/fpz4ZFMNOcRaVfFNl7OawuoTeuLhBx5K3smJ1Hx2zJlnbdWJBlgs9vwMcuNSrGgdG28Gq4uk6PsnkEr0wGbBlBVkc4n9ZsBe/U7QoybuLcJyyvP5KDxJiLDiIblhQpQCBXJdJvTV3w6rnDbIVeNd6M8WrdQpLMZQrTIo1UPO7r2VEL0jp9D3HMqgLviTco79mWioy1N/SCEhtByjoFJzLyg2sb9V7yo6CHjwYsghJap/gu6TkdPoz7xkyyrebd/jW1XTk50DPAwpGBXoE37D2Jff1HiTquwCEvDlwPCNBqA7780HgESUgZQ== 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=wTagtU7siCrfJ4lftq+qW3HP8WAwwYXSyJjLwIPGL40=; b=MpyNPS3Zubve7DA/1UilcIv1eCvmehSpg3YCJMBJqONP+CEleJB9gS2KyUU98rqSqpAdhwzm+Tm452uk8jrVaNZnMC00xpd5HqpenoZPL6png3p3nPOxwVJZ4a2WC4iS1g17Pw1m5w/BG8Wq15Oyn6c/x/Jz0BiSOYNvQSgI1VU= Received: from VI1PR83MB0352.EURPRD83.prod.outlook.com (10.165.198.149) by VI1PR83MB0367.EURPRD83.prod.outlook.com (10.165.198.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.12; Wed, 9 Oct 2019 09:13:59 +0000 Received: from VI1PR83MB0352.EURPRD83.prod.outlook.com ([fe80::394d:ea47:c2fc:9fc0]) by VI1PR83MB0352.EURPRD83.prod.outlook.com ([fe80::394d:ea47:c2fc:9fc0%9]) with mapi id 15.20.2367.004; Wed, 9 Oct 2019 09:13:59 +0000 From: Antoine Delignat-Lavaud To: Christian Huitema CC: QUIC Working Group Subject: RE: Announcing the QUIC Privacy & Security Workshop @ NDSS (Feb 23-26 2020) Thread-Topic: Announcing the QUIC Privacy & Security Workshop @ NDSS (Feb 23-26 2020) Thread-Index: AdV9LJf3ByrGMywdSYWM+FEb8a1JGwABrqkAAFOY+iA= Date: Wed, 9 Oct 2019 09:13:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, 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=antdl@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-10-09T09:13:57.5186511Z; 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=9822049d-78b0-468e-8c0d-f52cea2e7911; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=antdl@microsoft.com; x-originating-ip: [128.93.88.141] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14c2be59-f4c0-4516-e9e2-08d74c990557 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: VI1PR83MB0367: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-o365-sonar-daas-pilot: True x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(39860400002)(346002)(376002)(396003)(366004)(199004)(189003)(26005)(256004)(790700001)(186003)(3846002)(99286004)(86362001)(66946007)(66446008)(6116002)(66476007)(76176011)(71200400001)(102836004)(6916009)(7696005)(53546011)(71190400001)(22452003)(6506007)(81156014)(8676002)(446003)(74316002)(81166006)(316002)(7736002)(8936002)(64756008)(11346002)(14444005)(476003)(76116006)(486006)(66574012)(66556008)(7110500001)(25786009)(10090500001)(10290500003)(478600001)(5660300002)(236005)(4326008)(2420400007)(606006)(66066001)(33656002)(8990500004)(6436002)(6306002)(54896002)(9686003)(229853002)(966005)(14454004)(2906002)(52536014)(6246003)(55016002)(15650500001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR83MB0367; H:VI1PR83MB0352.EURPRD83.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: 2svQS2Z7qiDxQwVNtbMbutgLQiDYqPYnqEW46ZN6OC/jlnQymOzRc4M6PMkmdAm6i0guq4/QRlU9Kr70H9uGphOmrLNwN0ISEyRIjJHKyh5UKVQ0YTZK0P3uC2jg1AQfPbKQBUZwRQjyMv5nC6TdMjwZnhc+VO961rMNCf7TBED1AgwEcvGpx0raf0sYiQ0JGLxwyLxa9nOfmWO6WkyMAZGR6TARUgiQpyXY6u6eA1QJopqzKYykbvdNenNzMKZrbRhE1ikQudzlX7z0viqOfIpI+0rq7ozcondjWv6nE5RT7mUmDr/PaAtFbCyd9+zcg2lRbQqavj7f6g7TliWV+0ANtA8i8s0sVVFtDRe58P9XEqdWt9vl7tFeR5/kyLZduzas6L3020vWUb07oSOeZASAg/lwu+3uQbcy+xAUHqdBotTLlrxOPNhgz/9VfA0px08AZyWE7dmhn8uRYYm7jA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_VI1PR83MB0352939CA2DD87A578D1E4F3B2950VI1PR83MB0352EURP_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14c2be59-f4c0-4516-e9e2-08d74c990557 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2019 09:13:59.6960 (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: A0fnOhARAvV/GVRdN/vWxVsgIzSi3SgAFDTLC481aUu7ypI2o+L8r1NUpAYiyvtVDPtulVgd93rq5MRSF4AUgA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR83MB0367 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, 09 Oct 2019 09:14:06 -0000 --_000_VI1PR83MB0352939CA2DD87A578D1E4F3B2950VI1PR83MB0352EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbG9va2luZyBpbnRvIGl0IOKAkyBJIGhvcGUgd2UgY2FuIG9mZmVyIHNvbWUgZm9ybSBv ZiByZW1vdGUgcGFydGljaXBhdGlvbi4NCg0KQmVzdCwNCkFudG9pbmUNCg0KRnJvbTogUVVJQyA8 cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuIEh1aXRlbWENClNl bnQ6IDA3IE9jdG9iZXIgMjAxOSAxOToxOQ0KVG86IEFudG9pbmUgRGVsaWduYXQtTGF2YXVkIDxh bnRkbD00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogUVVJQyBXb3JraW5nIEdy b3VwIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEFubm91bmNpbmcgdGhlIFFVSUMgUHJp dmFjeSAmIFNlY3VyaXR5IFdvcmtzaG9wIEAgTkRTUyAoRmViIDIzLTI2IDIwMjApDQoNCldpbGwg eW91IGNvbnNpZGVyIHJlbW90ZSBwYXJ0aWNpcGF0aW9uIHRvIHRoZSB3b3Jrc2hvcD8NCi0tIENo cmlzdGlhbiBIdWl0ZW1hDQoNCg0KT24gT2N0IDcsIDIwMTksIGF0IDEwOjAyIEFNLCBBbnRvaW5l IERlbGlnbmF0LUxhdmF1ZCA8YW50ZGw9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1h aWx0bzphbnRkbD00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCu+7vw0K RnVsbCBjYWxsIGZvciBwYXBlcnM6IGh0dHBzOi8vd3d3Lm5kc3Mtc3ltcG9zaXVtLm9yZy9uZHNz MjAyMC9jZnAtcXVpYy1wcml2YWN5LWFuZC1zZWN1cml0eS13b3Jrc2hvcC88aHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3 Lm5kc3Mtc3ltcG9zaXVtLm9yZyUyRm5kc3MyMDIwJTJGY2ZwLXF1aWMtcHJpdmFjeS1hbmQtc2Vj dXJpdHktd29ya3Nob3AlMkYmZGF0YT0wMiU3QzAxJTdDYW50ZGwlNDBtaWNyb3NvZnQuY29tJTdD MTg4N2U0N2YzY2E0NDM5OTU0NjEwOGQ3NGI0YWYyOTAlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MDYwNjU3NTgzNzQ4MTMzJnNkYXRhPVF6MnFQYTNwM0NF NlFjJTJCajFqOE1KajdHN0VuSzd1VlRWTTNOS0FPRG9odyUzRCZyZXNlcnZlZD0wPg0KDQpXZSBh cmUgcGxlYXNlZCB0byBhbm5vdW5jZSB0aGF0IHRoZSBOZXR3b3JrIGFuZCBEaXN0cmlidXRlZCBT eXN0ZW0gU2VjdXJpdHkgc3ltcG9zaXVtIChORFNTLCBvcmdhbml6ZWQgYnkgdGhlIEludGVybmV0 IFNvY2lldHkpIHdpbGwgYmUgaG9zdGluZyBhIFFVSUMgUHJpdmFjeSAmIFNlY3VyaXR5IFtRVUlQ U10gd29ya3Nob3AgbmV4dCB5ZWFyLiBUaGUgZ29hbCBvZiB0aGlzIHdvcmtzaG9wIGlzIHRvIGJy aW5nIHNlY3VyaXR5IGFuYWx5c2lzIHJlc3VsdHMgcmV2aWV3ZWQgYnkgYSBwYW5lbCBvZiBhY2Fk ZW1pYyBhbmQgaW5kdXN0cmlhbCBleHBlcnRzIHRvIHRoZSBhdHRlbnRpb24gb2YgdGhlIFFVSUMg d29ya2luZyBncm91cCBhbmQgZGV2ZWxvcGVyIGNvbW11bml0aWVzIGluIG9yZGVyIHRvIGJ1aWxk IGNvbmZpZGVuY2UgaW4gYW5kIGltcHJvdmUgUVVJQyBiZWZvcmUgaXRzIHdpZGVzcHJlYWQgZGVw bG95bWVudC4gV2UgYXJlIHNlZWtpbmcgY29udHJpYnV0aW9ucyBjb3ZlcmluZyBtYW55IGFzcGVj dHMgb2YgdGhlIGRlc2lnbiBhbmQgaW1wbGFudGF0aW9uIG9mIFFVSUMsIGluY2x1ZGluZyAoYnV0 IG5vdCBsaW1pdGVkIHRvKToNCg0KDQoNCiAgKiAgIEludGVncmF0aW9uIHdpdGggdGhlIFRMUyAx LjMgaGFuZHNoYWtlOiBRVUlDIGlzIGRlc2lnbmVkIHRvIHJlLXVzZSB0aGUgVExTIDEuLjMgW1JG Qzg0NDZdIGF1dGhlbnRpY2F0ZWQga2V5IGV4Y2hhbmdlIHByb3RvY29sIHRoYXQgcHJvZHVjZXMg dGhlIHRyYWZmaWMgc2VjcmV0cyB1c2VkIHRvIGVuY3J5cHQgUVVJQyBwYWNrZXRzLiBXaGlsZSB0 aGUgVExTIDEuMyBrZXkgZXhjaGFuZ2UgcHJvdG9jb2wgaGFzIHJlY2VpdmVkIGV4dGVuc2l2ZSBm b3JtYWwgYW5hbHlzaXMgZWZmb3J0IGR1cmluZyBpdHMgc3RhbmRhcmRpemF0aW9uLCBRVUlD4oCZ cyBtb2R1bGFyIHVzZSBvZiB0aGUgVExTIGhhbmRzaGFrZSB0byBnZW5lcmF0ZSBzZWNyZXRzIGFu ZCBhdXRoZW50aWNhdGUgbmVnb3RpYXRlZCB0cmFuc3BvcnQgcGFyYW1ldGVycyBoYXMgbm90IHJl Y2VpdmVkIGFzIG11Y2ggYXR0ZW50aW9uLiBTb21lIG9mIHRoZSBwcm9wZXJ0aWVzIG9mIFRMUyAx Li4zLCBzdWNoIGFzIHRoZSBhdXRoZW50aWNhdGlvbiBieSB0aGUgaGFuZHNoYWtlIG9mIHRoZSB0 ZXJtaW5hdGlvbiBvZiAwLVJUVCBkYXRhIGJ5IHRoZSDigJxlbmQgb2YgZWFybHkgZGF0YeKAnSBt ZXNzYWdlLCByZWx5IG9uIGFzc3VtcHRpb25zIHRoYXQgaG9sZCBmb3IgdGhlIFRMUyByZWNvcmQg bGF5ZXIsIGJ1dCBub3QgZm9yIHRoZSBRVUlDIHJlY29yZCBsYXllci4NCg0KDQogICogICBQYWNr ZXQgcHJvdGVjdGlvbjogYW5hbHlzaXMgb2YgVExTIGFzc3VtZSByZWxpYWJsZSwgb3JkZXJlZCBk ZWxpdmVyeSBvZiBuZXR3b3JrIG1lc3NhZ2VzLCB3aGljaCBkb2VzIG5vdCBob2xkIGluIFFVSUMu IFRoZSBlZmZlY3Qgb2YgcGFja2V0IGxvc3Mgb24gUVVJQ+KAmXMgcmVjb3JkIGxheWVyIHNlY3Vy aXR5IGlzIGltcG9ydGFudCBhbmQgbm90IHdlbGwgdW5kZXJzdG9vZC4gTW9yZW92ZXIsIFFVSUPi gJlzIHJlY29yZCBsYXllciBwcm92aWRlcyBmZWF0dXJlcyB0aGF0IFRMUyBkb2VzIG5vdCwgc3Vj aCBhcyBoZWFkZXIgcHJvdGVjdGlvbi4gQ2FwdHVyaW5nIHRoZSBzZW1hbnRpY3Mgb2YgdGhpcyBu ZXcgcGFja2V0IHByb3RlY3Rpb24gYWxnb3JpdGhtIGFuZCBwcm92aW5nIGl0cyBzZWN1cml0eSBp cyBjcml0aWNhbC4NCg0KDQogICogICBEZW5pYWwgb2YgU2VydmljZSAoRG9TKSBmZWF0dXJlczog UVVJQyBoYXMgYSBudW1iZXIgb2YgZmVhdHVyZXMgZGVzaWduZWQgdG8gcmVkdWNlIHRoZSBlZmZl Y3RzIG9mIERvUywgYm90aCBvbiBpbmRpdmlkdWFsIGNvbm5lY3Rpb25zLCBzdWNoIGFzIGR1cGxp Y2F0ZSBwYWNrZXQgZGV0ZWN0aW9uIGFuZCBjb21wbGV0ZSBwYWNrZXQgcHJvdGVjdGlvbiwgc2Vy dmVyIHJlc291cmNlcywgc3VjaCBhcyBSZXRyeSwgYW5kIHRoZSByZXNvdXJjZXMgb2YgYnlzdGFu ZGVycywgc3VjaCBhcyBhbnRpLXJlZmxlY3Rpb24uIEl0IGhhcyB5ZXQgdG8gYmUgc2hvd24gd2hl dGhlciBvciBub3QgdGhlc2UgdGVjaG5pcXVlcyBhY2hpZXZlIHRoZWlyIGRlc2lyZWQgZ29hbHMu DQoNCg0KICAqICAgUHJpdmFjeTogbWFueSBvZiBRVUlD4oCZcyBuZXcgZmVhdHVyZXMgYWNjb3Vu dCBmb3IgYW5kIGF0dGVtcHQgdG8gbWl0aWdhdGUgdGhlIGxpbmthYmlsaXR5IG9mIHBhY2tldHMg dG8gdXNlcnMgYWNyb3NzIG5ldHdvcmsgcGF0aHMgYW5kIGJldHdlZW4gY29ubmVjdGlvbnMuIEZv ciBleGFtcGxlLCB2b2x1bnRhcnkgY29ubmVjdGlvbiBtaWdyYXRpb24gcmVxdWlyZXMgZW5kcG9p bnRzIHRvIHVzZSBuZXcgY29ubmVjdGlvbiBpZGVudGlmaWVycyBpZiBwb3NzaWJsZSBhcyBhIHdh eSBvZiBwcmV2ZW50aW5nIGNyb3NzLXBhdGggbGlua2FiaWxpdHkuIEFsc28sIGFzIGEgbWVhbnMg b2YgaW1wcm92aW5nIGVuZHBvaW50IHByaXZhY3kgcG9zdHVyZXMsIGFtb25nIG90aGVycywgUVVJ QyBkb2VzIG5vdCBtYW5kYXRlIGVuZHBvaW50cyBwcm92aWRlIGFueSB3YXkgZm9yIG5ldHdvcmtz IHRvIG1lYXN1cmUgcGVyLWNvbm5lY3Rpb24gUm91bmQgVHJpcCBUaW1lIChSVFQpLiBUaGUgb3B0 aW9uYWwgc3BpbiBiaXQgaXMgdGhlIG9ubHkgc2lnbmFsIG1hZGUgd2lsbGluZ2x5IGF2YWlsYWJs ZSB0byB0aGUgbmV0d29yay4gQ3VycmVudGx5LCB0aGVyZSBpcyBubyBzdHJvbmcgYW5hbHlzaXMg c3VwcG9ydGluZyB0aGUgY29uY3JldGUgcHJpdmFjeSBiZW5lZml0cyB0aGVzZSBmZWF0dXJlcyBw cm92aWRlIHRvIFFVSUMgZW5kcG9pbnRzLg0KDQoNCiAgKiAgIEFwcGxpY2F0aW9uIHNlY3VyaXR5 OiB3aGlsZSBUTFMgZXhwb3NlcyBhIHNvY2tldC1iYXNlZCBzZW5kL3JlY3YgaW50ZXJmYWNlLCBR VUlDIGludGVncmF0ZXMgbW9zdCBvZiB0aGUgZHluYW1pYyBzdHJlYW0gbXVsdGlwbGV4aW5nIGlu dGVyZmFjZSBmcm9tIEhUVFAvMi4uIEFwcGxpY2F0aW9ucyBtdXN0IHRhcmdldCB0aGlzIG5ldyBp bnRlcmZhY2UsIGxlYWRpbmcgdG8gbmV3IHByb3RvY29scyBzdWNoIGFzIEhUVFAvMy4gVGhlIHNl Y3VyaXR5IGltcGxpY2F0aW9ucyBvZiB0aGUgbmV3IHRyYW5zcG9ydCBpbnRlcmZhY2UgZm9yIGxl Z2FjeSBhbmQgbmV3IGFwcGxpY2F0aW9ucyBhcmUgbm90IHdlbGwgc3R1ZGllZC4gRm9yIGluc3Rh bmNlLCBpdCBpcyB1bmNsZWFyIGhvdyBhbiBhcHBsaWNhdGlvbiBjYW4gdGVsbCBhcGFydCB3aGlj aCBwYXJ0cyBvZiBpbmNvbWluZyBtZXNzYWdlcyBoYXZlIGJlZW4gcHJvdGVjdGVkIHdpdGggdGhl IDAtUlRUIG9yIHRoZSAxLVJUVCBzZWNyZXQuDQoNClN1Ym1pc3Npb25zIGFyZSBkdWUgb24gRGVj ZW1iZXIgMTMgYW5kIG11c3QgYmUgc3VibWl0dGVkIHRvIGh0dHBzOi8vZWFzeWNoYWlyLm9yZy9j b25mZXJlbmNlcy8/Y29uZj1xdWlwczIwPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmVhc3ljaGFpci5vcmclMkZjb25mZXJl bmNlcyUyRiUzRmNvbmYlM0RxdWlwczIwJmRhdGE9MDIlN0MwMSU3Q2FudGRsJTQwbWljcm9zb2Z0 LmNvbSU3QzE4ODdlNDdmM2NhNDQzOTk1NDYxMDhkNzRiNGFmMjkwJTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzA2MDY1NzU4Mzc1ODEyOCZzZGF0YT1Ob2o4 aHo0c2E1bXE3ODZYcVdFMTVBemF4M1Bna1BSM3lJRGpvcml3VEJVJTNEJnJlc2VydmVkPTA+DQpS ZWdpc3RyYXRpb24gdG8gdGhlIHdvcmtzaG9wIHdpbGwgYmUgcGFydCBvZiB0aGUgcmVnaXN0cmF0 aW9uIHByb2Nlc3MgZm9yIE5EU1MgKFRCQSBvbiBodHRwczovL3d3dy5uZHNzLXN5bXBvc2l1bS5v cmcvPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRnd3dy5uZHNzLXN5bXBvc2l1bS5vcmclMkYmZGF0YT0wMiU3QzAxJTdDYW50 ZGwlNDBtaWNyb3NvZnQuY29tJTdDMTg4N2U0N2YzY2E0NDM5OTU0NjEwOGQ3NGI0YWYyOTAlN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MDYwNjU3NTgzNzU4 MTI4JnNkYXRhPVhjZnBqOEhZdVdVQXJ1dnJaMTBMM0pRSzE5a0RaY2JrV2ZOQiUyRjNWc3d5YyUz RCZyZXNlcnZlZD0wPikNCg0KV2UgYXJlIGxvb2tpbmcgZm9yd2FyZCB0byBzZWUgeW91IGJlc3Qg d29yayB0b3dhcmRzIG1ha2luZyBhIFFVSUMgYSBzZWN1cmUgcHJvdG9jb2wuDQoNCkJlc3QgcmVn YXJkcywNClRoZSBRVUlQUyBDaGFpcnMNCkFudG9pbmUgRGVsaWduYXQtTGF2YXVkICYgQ2hyaXN0 b3BoZXIgV29vZA0K --_000_VI1PR83MB0352939CA2DD87A578D1E4F3B2950VI1PR83MB0352EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNt Ow0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjE5NjE3NTk2Nzg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwMDM1NTI1 NDQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1s aXN0LWlkOjIwMTI3NTQ4Mzk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjc3MjQ0Njg2NiAxMzY4OTU2MzMwIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3 NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTc7fQ0K QGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoy MC42NXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMTps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU2LjY1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDo5Mi42NXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMjguNjVwdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjE2NC42NXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MjAwLjY1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzNi42NXB0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6MjcyLjY1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozMDgu NjVwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJlt IGxvb2tpbmcgaW50byBpdCDigJMgSSBob3BlIHdlIGNhbiBvZmZlciBzb21lIGZvcm0gb2YgcmVt b3RlIHBhcnRpY2lwYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbnRvaW5lPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+IFFVSUMg Jmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0 aWFuIEh1aXRlbWE8YnI+DQo8Yj5TZW50OjwvYj4gMDcgT2N0b2JlciAyMDE5IDE5OjE5PGJyPg0K PGI+VG86PC9iPiBBbnRvaW5lIERlbGlnbmF0LUxhdmF1ZCAmbHQ7YW50ZGw9NDBtaWNyb3NvZnQu Y29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gUVVJQyBXb3JraW5nIEdyb3Vw ICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQW5ub3VuY2lu ZyB0aGUgUVVJQyBQcml2YWN5ICZhbXA7IFNlY3VyaXR5IFdvcmtzaG9wIEAgTkRTUyAoRmViIDIz LTI2IDIwMjApPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5XaWxsIHlvdSBjb25zaWRlciByZW1vdGUgcGFy dGljaXBhdGlvbiB0byB0aGUgd29ya3Nob3A/PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LS0gQ2hyaXN0aWFuIEh1aXRlbWEmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIE9j dCA3LCAyMDE5LCBhdCAxMDowMiBBTSwgQW50b2luZSBEZWxpZ25hdC1MYXZhdWQgJmx0OzxhIGhy ZWY9Im1haWx0bzphbnRkbD00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciPmFudGRsPTQw bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7v u78gPHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GdWxsIGNhbGwgZm9yIHBhcGVyczogPGEg aHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGd3d3Lm5kc3Mtc3ltcG9zaXVtLm9yZyUyRm5kc3MyMDIwJTJGY2ZwLXF1 aWMtcHJpdmFjeS1hbmQtc2VjdXJpdHktd29ya3Nob3AlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q2Fu dGRsJTQwbWljcm9zb2Z0LmNvbSU3QzE4ODdlNDdmM2NhNDQzOTk1NDYxMDhkNzRiNGFmMjkwJTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzA2MDY1NzU4Mzc0 ODEzMyZhbXA7c2RhdGE9UXoycVBhM3AzQ0U2UWMlMkJqMWo4TUpqN0c3RW5LN3VWVFZNM05LQU9E b2h3JTNEJmFtcDtyZXNlcnZlZD0wIj4NCmh0dHBzOi8vd3d3Lm5kc3Mtc3ltcG9zaXVtLm9yZy9u ZHNzMjAyMC9jZnAtcXVpYy1wcml2YWN5LWFuZC1zZWN1cml0eS13b3Jrc2hvcC88L2E+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSBwbGVhc2VkIHRvIGFubm91bmNlIHRoYXQgdGhlIE5l dHdvcmsgYW5kIERpc3RyaWJ1dGVkIFN5c3RlbSBTZWN1cml0eSBzeW1wb3NpdW0gKE5EU1MsIG9y Z2FuaXplZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSkgd2lsbCBiZSBob3N0aW5nIGEgUVVJQyBQ cml2YWN5ICZhbXA7IFNlY3VyaXR5IFtRVUlQU10gd29ya3Nob3AgbmV4dCB5ZWFyLiBUaGUgZ29h bCBvZiB0aGlzIHdvcmtzaG9wIGlzIHRvIGJyaW5nDQogc2VjdXJpdHkgYW5hbHlzaXMgcmVzdWx0 cyByZXZpZXdlZCBieSBhIHBhbmVsIG9mIGFjYWRlbWljIGFuZCBpbmR1c3RyaWFsIGV4cGVydHMg dG8gdGhlIGF0dGVudGlvbiBvZiB0aGUgUVVJQyB3b3JraW5nIGdyb3VwIGFuZCBkZXZlbG9wZXIg Y29tbXVuaXRpZXMgaW4gb3JkZXIgdG8gYnVpbGQgY29uZmlkZW5jZSBpbiBhbmQgaW1wcm92ZSBR VUlDIGJlZm9yZSBpdHMgd2lkZXNwcmVhZCBkZXBsb3ltZW50LiBXZSBhcmUgc2Vla2luZyBjb250 cmlidXRpb25zDQogY292ZXJpbmcgbWFueSBhc3BlY3RzIG9mIHRoZSBkZXNpZ24gYW5kIGltcGxh bnRhdGlvbiBvZiBRVUlDLCBpbmNsdWRpbmcgKGJ1dCBub3QgbGltaXRlZCB0byk6PGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi0xNS4zNXB0O21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCkludGVncmF0aW9uIHdpdGggdGhl IFRMUyAxLjMgaGFuZHNoYWtlOiBRVUlDIGlzIGRlc2lnbmVkIHRvIHJlLXVzZSB0aGUgVExTIDEu LjMgW1JGQzg0NDZdIGF1dGhlbnRpY2F0ZWQga2V5IGV4Y2hhbmdlIHByb3RvY29sIHRoYXQgcHJv ZHVjZXMgdGhlIHRyYWZmaWMgc2VjcmV0cyB1c2VkIHRvIGVuY3J5cHQgUVVJQyBwYWNrZXRzLiBX aGlsZSB0aGUgVExTIDEuMyBrZXkgZXhjaGFuZ2UgcHJvdG9jb2wgaGFzIHJlY2VpdmVkIGV4dGVu c2l2ZSBmb3JtYWwNCiBhbmFseXNpcyBlZmZvcnQgZHVyaW5nIGl0cyBzdGFuZGFyZGl6YXRpb24s IFFVSUPigJlzIG1vZHVsYXIgdXNlIG9mIHRoZSBUTFMgaGFuZHNoYWtlIHRvIGdlbmVyYXRlIHNl Y3JldHMgYW5kIGF1dGhlbnRpY2F0ZSBuZWdvdGlhdGVkIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGhh cyBub3QgcmVjZWl2ZWQgYXMgbXVjaCBhdHRlbnRpb24uIFNvbWUgb2YgdGhlIHByb3BlcnRpZXMg b2YgVExTIDEuLjMsIHN1Y2ggYXMgdGhlIGF1dGhlbnRpY2F0aW9uIGJ5IHRoZQ0KIGhhbmRzaGFr ZSBvZiB0aGUgdGVybWluYXRpb24gb2YgMC1SVFQgZGF0YSBieSB0aGUg4oCcZW5kIG9mIGVhcmx5 IGRhdGHigJ0gbWVzc2FnZSwgcmVseSBvbiBhc3N1bXB0aW9ucyB0aGF0IGhvbGQgZm9yIHRoZSBU TFMgcmVjb3JkIGxheWVyLCBidXQgbm90IGZvciB0aGUgUVVJQyByZWNvcmQgbGF5ZXIuPGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi0xNS4zNXB0O21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NClBh Y2tldCBwcm90ZWN0aW9uOiBhbmFseXNpcyBvZiBUTFMgYXNzdW1lIHJlbGlhYmxlLCBvcmRlcmVk IGRlbGl2ZXJ5IG9mIG5ldHdvcmsgbWVzc2FnZXMsIHdoaWNoIGRvZXMgbm90IGhvbGQgaW4gUVVJ Qy4gVGhlIGVmZmVjdCBvZiBwYWNrZXQgbG9zcyBvbiBRVUlD4oCZcyByZWNvcmQgbGF5ZXIgc2Vj dXJpdHkgaXMgaW1wb3J0YW50IGFuZCBub3Qgd2VsbCB1bmRlcnN0b29kLiBNb3Jlb3ZlciwgUVVJ Q+KAmXMgcmVjb3JkIGxheWVyIHByb3ZpZGVzIGZlYXR1cmVzDQogdGhhdCBUTFMgZG9lcyBub3Qs IHN1Y2ggYXMgaGVhZGVyIHByb3RlY3Rpb24uIENhcHR1cmluZyB0aGUgc2VtYW50aWNzIG9mIHRo aXMgbmV3IHBhY2tldCBwcm90ZWN0aW9uIGFsZ29yaXRobSBhbmQgcHJvdmluZyBpdHMgc2VjdXJp dHkgaXMgY3JpdGljYWwuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi0xNS4zNXB0O21zby1saXN0 OmwxIGxldmVsMSBsZm8zIj4NCkRlbmlhbCBvZiBTZXJ2aWNlIChEb1MpIGZlYXR1cmVzOiBRVUlD IGhhcyBhIG51bWJlciBvZiBmZWF0dXJlcyBkZXNpZ25lZCB0byByZWR1Y2UgdGhlIGVmZmVjdHMg b2YgRG9TLCBib3RoIG9uIGluZGl2aWR1YWwgY29ubmVjdGlvbnMsIHN1Y2ggYXMgZHVwbGljYXRl IHBhY2tldCBkZXRlY3Rpb24gYW5kIGNvbXBsZXRlIHBhY2tldCBwcm90ZWN0aW9uLCBzZXJ2ZXIg cmVzb3VyY2VzLCBzdWNoIGFzIFJldHJ5LCBhbmQgdGhlIHJlc291cmNlcyBvZiBieXN0YW5kZXJz LA0KIHN1Y2ggYXMgYW50aS1yZWZsZWN0aW9uLiBJdCBoYXMgeWV0IHRvIGJlIHNob3duIHdoZXRo ZXIgb3Igbm90IHRoZXNlIHRlY2huaXF1ZXMgYWNoaWV2ZSB0aGVpciBkZXNpcmVkIGdvYWxzLjxi cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDotMTUuMzVwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+ DQpQcml2YWN5OiBtYW55IG9mIFFVSUPigJlzIG5ldyBmZWF0dXJlcyBhY2NvdW50IGZvciBhbmQg YXR0ZW1wdCB0byBtaXRpZ2F0ZSB0aGUgbGlua2FiaWxpdHkgb2YgcGFja2V0cyB0byB1c2VycyBh Y3Jvc3MgbmV0d29yayBwYXRocyBhbmQgYmV0d2VlbiBjb25uZWN0aW9ucy4gRm9yIGV4YW1wbGUs IHZvbHVudGFyeSBjb25uZWN0aW9uIG1pZ3JhdGlvbiByZXF1aXJlcyBlbmRwb2ludHMgdG8gdXNl IG5ldyBjb25uZWN0aW9uIGlkZW50aWZpZXJzIGlmIHBvc3NpYmxlDQogYXMgYSB3YXkgb2YgcHJl dmVudGluZyBjcm9zcy1wYXRoIGxpbmthYmlsaXR5LiBBbHNvLCBhcyBhIG1lYW5zIG9mIGltcHJv dmluZyBlbmRwb2ludCBwcml2YWN5IHBvc3R1cmVzLCBhbW9uZyBvdGhlcnMsIFFVSUMgZG9lcyBu b3QgbWFuZGF0ZSBlbmRwb2ludHMgcHJvdmlkZSBhbnkgd2F5IGZvciBuZXR3b3JrcyB0byBtZWFz dXJlIHBlci1jb25uZWN0aW9uIFJvdW5kIFRyaXAgVGltZSAoUlRUKS4gVGhlIG9wdGlvbmFsIHNw aW4gYml0IGlzIHRoZQ0KIG9ubHkgc2lnbmFsIG1hZGUgd2lsbGluZ2x5IGF2YWlsYWJsZSB0byB0 aGUgbmV0d29yay4gQ3VycmVudGx5LCB0aGVyZSBpcyBubyBzdHJvbmcgYW5hbHlzaXMgc3VwcG9y dGluZyB0aGUgY29uY3JldGUgcHJpdmFjeSBiZW5lZml0cyB0aGVzZSBmZWF0dXJlcyBwcm92aWRl IHRvIFFVSUMgZW5kcG9pbnRzLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDotMTUuMzVwdDttc28t bGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpBcHBsaWNhdGlvbiBzZWN1cml0eTogd2hpbGUgVExTIGV4 cG9zZXMgYSBzb2NrZXQtYmFzZWQgc2VuZC9yZWN2IGludGVyZmFjZSwgUVVJQyBpbnRlZ3JhdGVz IG1vc3Qgb2YgdGhlIGR5bmFtaWMgc3RyZWFtIG11bHRpcGxleGluZyBpbnRlcmZhY2UgZnJvbSBI VFRQLzIuLiBBcHBsaWNhdGlvbnMgbXVzdCB0YXJnZXQgdGhpcyBuZXcgaW50ZXJmYWNlLCBsZWFk aW5nIHRvIG5ldyBwcm90b2NvbHMgc3VjaCBhcyBIVFRQLzMuIFRoZSBzZWN1cml0eSBpbXBsaWNh dGlvbnMNCiBvZiB0aGUgbmV3IHRyYW5zcG9ydCBpbnRlcmZhY2UgZm9yIGxlZ2FjeSBhbmQgbmV3 IGFwcGxpY2F0aW9ucyBhcmUgbm90IHdlbGwgc3R1ZGllZC4gRm9yIGluc3RhbmNlLCBpdCBpcyB1 bmNsZWFyIGhvdyBhbiBhcHBsaWNhdGlvbiBjYW4gdGVsbCBhcGFydCB3aGljaCBwYXJ0cyBvZiBp bmNvbWluZyBtZXNzYWdlcyBoYXZlIGJlZW4gcHJvdGVjdGVkIHdpdGggdGhlIDAtUlRUIG9yIHRo ZSAxLVJUVCBzZWNyZXQuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1Ym1pc3Npb25z IGFyZSBkdWUgb24gRGVjZW1iZXIgMTMgYW5kIG11c3QgYmUgc3VibWl0dGVkIHRvIDxhIGhyZWY9 Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRmVhc3ljaGFpci5vcmclMkZjb25mZXJlbmNlcyUyRiUzRmNvbmYlM0RxdWlwczIw JmFtcDtkYXRhPTAyJTdDMDElN0NhbnRkbCU0MG1pY3Jvc29mdC5jb20lN0MxODg3ZTQ3ZjNjYTQ0 Mzk5NTQ2MTA4ZDc0YjRhZjI5MCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdD MSU3QzAlN0M2MzcwNjA2NTc1ODM3NTgxMjgmYW1wO3NkYXRhPU5vajhoejRzYTVtcTc4NlhxV0Ux NUF6YXgzUGdrUFIzeUlEam9yaXdUQlUlM0QmYW1wO3Jlc2VydmVkPTAiPg0KaHR0cHM6Ly9lYXN5 Y2hhaXIub3JnL2NvbmZlcmVuY2VzLz9jb25mPXF1aXBzMjA8L2E+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdpc3RyYXRpb24gdG8gdGhlIHdvcmtzaG9wIHdpbGwgYmUg cGFydCBvZiB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgZm9yIE5EU1MgKFRCQSBvbg0KPGEgaHJl Zj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGd3d3Lm5kc3Mtc3ltcG9zaXVtLm9yZyUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdD YW50ZGwlNDBtaWNyb3NvZnQuY29tJTdDMTg4N2U0N2YzY2E0NDM5OTU0NjEwOGQ3NGI0YWYyOTAl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MDYwNjU3NTgz NzU4MTI4JmFtcDtzZGF0YT1YY2ZwajhIWXVXVUFydXZyWjEwTDNKUUsxOWtEWmNia1dmTkIlMkYz VnN3eWMlM0QmYW1wO3Jlc2VydmVkPTAiPg0KaHR0cHM6Ly93d3cubmRzcy1zeW1wb3NpdW0ub3Jn LzwvYT4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSBsb29raW5nIGZvcndhcmQgdG8g c2VlIHlvdSBiZXN0IHdvcmsgdG93YXJkcyBtYWtpbmcgYSBRVUlDIGEgc2VjdXJlIHByb3RvY29s LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgUVVJUFMgQ2hhaXJzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbnRvaW5lIERlbGlnbmF0LUxhdmF1ZCAmYW1wOyBDaHJpc3RvcGhl ciBXb29kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_VI1PR83MB0352939CA2DD87A578D1E4F3B2950VI1PR83MB0352EURP_-- From nobody Thu Oct 10 14:52:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A68120059 for ; Thu, 10 Oct 2019 14:52:31 -0700 (PDT) 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 Lnjjqeu71aub for ; Thu, 10 Oct 2019 14:52:28 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A7D120041 for ; Thu, 10 Oct 2019 14:52:27 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id i185so6269193oif.9 for ; Thu, 10 Oct 2019 14:52:27 -0700 (PDT) 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=FUzsp9q5XdGNUc+ze9nnMDQ2vdAWqojjqD1Wg9G0SuA=; b=L5y+drfJaWK4ubTUyA344sHyuQ/hl7hnrbL8fqbHpR46/SGTMvgfnpzvRnAB2sRxJU O2OVE+whwekYVdzMWQnoNK31/TwpEbjjmhXeaAx6MV0VReoR68QpMwD+8FQLplijZe49 Mk76E7AxOaTfUM8Mx6hLgmIeCxXx/r4ZL59qprJTAJH2ym2QH1OD1nXJ1OoHNIBRTxKi WYyaoFxoRpoIRSS8BYvn9F1f8msnr/n0JrIkmdPPLf6R4xIeCfISR4HasDugHP0R6+Sb BbKd0wvPDt0qZdAH6owe/dT7aDCZpcbz0xjOpUtElPhFd8/Z7+xnR9/mYQ51hZd/gIG/ wGZA== 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=FUzsp9q5XdGNUc+ze9nnMDQ2vdAWqojjqD1Wg9G0SuA=; b=L6y1VSRZPsmE6RSGYR/YrZI+q3ifviTwSqBirKFLXQDYBUnXnrx9k2Ar1ameeKTjnU PhXmWH7DvT1Up7LpjxPoWvj/ivktXR5FBx8PiY5esGOPQd8f3sshWbX0G7/DltebYnGi lDCiUYDF+OuCHVMJnA8KCyAsVFOlAuW1kQQGY/zOr4X3h3F67PCWM6sJ0PKGzkhHOvoQ q+azxr8GFIce4R4iuTUaQSTJn81jJJgugWkm24PCIuKomUUL1r9yAMW4xz0l3p12DSAQ Z6KQguHHvBJbBXWRQIjER4GcKpb/CYaZ8aPM23dKvwTJPo7GlDMVrVez3F2kCtChKria 7xKA== X-Gm-Message-State: APjAAAVRZjiAgskTP2se9hRgCTGhbc4YWKTTBJcdoCddH4gFfOf8O8bx DwBHh+8ZvR6APjReG78RMiZOHWmsXBuc+p1HCB48SA== X-Google-Smtp-Source: APXvYqzeTStULfmfm6D67yzynwn3xc7ykJTfkP7lJN6yqp96+9wCWQX1Mld2l0T0h6fDTa19UxHpqmETUnmJgwHk+y8= X-Received: by 2002:aca:6087:: with SMTP id u129mr9801017oib.149.1570744346577; Thu, 10 Oct 2019 14:52:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Harper Date: Thu, 10 Oct 2019 14:52:14 -0700 Message-ID: Subject: Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS To: Kazuho Oku Cc: David Schinazi , Eric Rescorla , IETF QUIC WG , Ted Hardie Content-Type: multipart/alternative; boundary="000000000000cfe5d40594956aab" 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, 10 Oct 2019 21:52:32 -0000 --000000000000cfe5d40594956aab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I filed https://github.com/quicwg/base-drafts/issues/3086 for this issue and so we can discuss it next week in Cupertino. On Wed, Oct 2, 2019 at 4:50 PM Kazuho Oku wrote: > 2019=E5=B9=B410=E6=9C=883=E6=97=A5(=E6=9C=A8) 6:21 David Schinazi : > > > > If we decide that the first requests need to operate without knowledge > of settings, > > we're effectively crippling the main extension mechanism we have in > HTTP/3. > > I'm not comfortable saying that for the entire lifetime of QUICv1 we > cannot have > > extensions that impact the first requests. That feels like painting > ourselves into a corner. > > > > There are many features that we can punt out of QUICv1 and figure out > later as extensions, > > but it's critical that we build an extension mechanism that allows that= . > > For HTTP/3, I think that we'd likely be fine with not having settings > delivered before issuing requests. That's how HTTP/2 has been, and we > are used to dealing with that. Though admittedly, QPACK is more > disciplined on what can be done in such case compared to HPACK. > > Other application protocols using QUIC v1 can define their own TP, if > having settings exchanged before 1-RTT data becomes a critical issue > for them. > > > > > On Tue, Oct 1, 2019 at 6:23 PM Kazuho Oku wrote: > >> > >> 2019=E5=B9=B410=E6=9C=882=E6=97=A5(=E6=B0=B4) 9:21 David Schinazi : > >> > > >> > Additionally, the current status quo makes it hard to have SETTINGS > >> > play nicely with 0-RTT. Fixing this is important to deploying IETF > QUIC. > >> > >> While I understand and share the pain, I am not sure if this should be > >> a blocker for QUIC v1, as 0-RTT is essentially a must-implement for > >> HTTP/3 (the primary application protocol for QUIC v1). > >> > >> 0-RTT requires clients (and servers) to operate without the knowledge > >> of the settings that are sent by the server. Until the client receives > >> the settings of the server and switches to using 1-RTT packets, the > >> client is expected to use the settings of the previous connection. The > >> server is expected to accept 0-RTT only if it knows that the settings > >> parameters of that the client is using for 0-RTT. > >> > >> Assuming that we cannot remove this requirement, I do not think it's > >> too complicated to require endpoints when using 1-RTT to operate > >> without the knowledge of settings (i.e. operate with a very > >> conservative set of properties) until it receives the settings from > >> the peer. > >> > >> > We're chartered to produce a protocol with fast connection > establishment, > >> > and if we fail to negotiate options and extensions nicely with that, > we'll > >> > harm extensibility long-term and cause deployment of damaging > workarounds. > >> > > >> > David > >> > > >> > On Tue, Oct 1, 2019 at 4:41 PM Nick Harper 40google.com@dmarc.ietf.org> wrote: > >> >> > >> >> I think it loses most of its utility if it's not a v1 feature. The > >> >> main motivation for the feature is to simplify application protocol= s. > >> >> At the time that v2 is introduced and application protocols are bei= ng > >> >> specified to use it, existing application protocols will already ha= ve > >> >> an application-specific way to negotiate params, so they will > continue > >> >> to use that instead of using both the existing application-specific > >> >> mechanism (for v1) and v2-only application parameters feature (for > >> >> v2+). (I'm assuming that as applications switch from using QUIC v1 = to > >> >> QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS 1.3, > instead > >> >> of like upgrading H2 to H3.) > >> >> > >> >> On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla wrote: > >> >> > > >> >> > Does this need to be a 1.0 feature? > >> >> > > >> >> > On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie > wrote: > >> >> >> > >> >> >> Hi Nick, > >> >> >> > >> >> >> Two points in addition to the privacy issue already raised make > me concur with Roberto that this should be v2 or later. The first is thi= s: > >> >> >> > >> >> >> "Negotiating or advertising features is something multiple > applicationswill need to do and is not a feature specific to H3." > >> >> >> > >> >> >> Absolutely true, but there is also a fairly large variability in > how applications do this. If we design something now that works for H3, = it > may very well be sub-optimal or useless for later application targets. > Getting something general enough to handle DNS, WEBRTC, SMTP, plus the > various flavors of IoT protocols I've heard as targets hoping to move to > QUIC is going to take time and care, and it will block completion of v1. > >> >> >> > >> >> >> The second is this: > >> >> >> > >> >> >> *The other downside is that if too much data is put in > application parameters, it could cause the number of packets for a client > or server=E2=80=99s flight to go from N to N+1, which would increase the = chance of > head of line blocking. > >> >> >> > >> >> >> Depending on what counts as application parameters, this could b= e > more than N+1. Someone running NETCONF over QUIC, for example, would be > using a fairly verbose syntax in which each parameter is a full URN. > >> >> >> > >> >> >> regards, > >> >> >> > >> >> >> Ted Hardie > >> >> >> > >> >> >> > >> >> >> On Thu, Sep 26, 2019 at 5:52 PM Nick Harper 40google.com@dmarc.ietf.org> wrote: > >> >> >>> > >> >> >>> I propose introducing application parameters to the QUIC > handshake and > >> >> >>> using this new mechanism for H3 SETTINGS instead of sending the= m > as > >> >> >>> the first thing in the control stream. Application parameters > would > >> >> >>> allow applications using QUIC to advertise or negotiate > >> >> >>> application-specific parameters during the cryptographic and > transport > >> >> >>> handshake. It would guarantee that the client and server have > >> >> >>> exchanged their application parameters once the handshake is > complete. > >> >> >>> > >> >> >>> Specifically, I=E2=80=99m proposing a new =E2=80=9Capplication_= layer_parameters=E2=80=9D > >> >> >>> transport parameter, which when sent by the client is a series > of ALPN > >> >> >>> identifiers with an opaque blob of application parameters per > >> >> >>> identifier, and when sent by the server is a single opaque blob > of > >> >> >>> application parameters for the application identified in the AL= PN > >> >> >>> extension. > >> >> >>> > >> >> >>> Negotiating or advertising features is something multiple > applications > >> >> >>> will need to do and is not a feature specific to H3. Whatever w= e > do in > >> >> >>> H3 will likely be copied by other applications using QUIC. By > >> >> >>> providing a general mechanism in QUIC transport, we provide > >> >> >>> applications with a consistent way of achieving this goal. QUIC > has a > >> >> >>> design pattern of collapsing multiple layers into one to save o= n > round > >> >> >>> trips (e.g. combining crypto and transport handshake); this fit= s > in > >> >> >>> with that pattern. > >> >> >>> > >> >> >>> Using application parameters for H3 SETTINGS clears up some > issues. H3 > >> >> >>> doesn=E2=80=99t need to specify that an endpoint shouldn=E2=80= =99t wait for its > peer=E2=80=99s > >> >> >>> SETTINGS since they=E2=80=99ve already arrived. Likewise, there= is no > >> >> >>> confusion about whether SETTINGS arriving after session tickets > are > >> >> >>> bound to the session tickets; SETTINGS arrives before the > tickets and > >> >> >>> the client doesn=E2=80=99t need to wait for the receipt of SETT= INGS to > bind > >> >> >>> them to the ticket. It also simplifies the server binding > SETTINGS to > >> >> >>> the ticket since that is done as part of binding transport > parameters > >> >> >>> to the ticket. > >> >> >>> > >> >> >>> This also provides opportunities for future features. Since the > >> >> >>> exchange of SETTINGS occurs before application data, a new > feature > >> >> >>> doesn=E2=80=99t need to be specified in a way to provide an upg= rade path > from > >> >> >>> =E2=80=9Cvanilla=E2=80=9D H3 to something including this featur= e, and instead be > >> >> >>> guaranteed that the new feature can be used for the entire > connection. > >> >> >>> > >> >> >>> Without application parameters, each application that needs to > >> >> >>> advertise or negotiate application settings needs its own > mechanism to > >> >> >>> do so. This would result in multiple transport parameters or > >> >> >>> extensions leading to duplication of work and layering > violations.. > >> >> >>> Applications could instead exchange these settings in applicati= on > >> >> >>> data, meaning that each application needs to define the > semantics of > >> >> >>> application data received before and after the settings have be= en > >> >> >>> exchanged, as H3 currently does. > >> >> >>> > >> >> >>> There is already a demonstrated need for an application > parameters > >> >> >>> mechanism in the QUIC handshake. One example is > >> >> >>> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > which is > >> >> >>> currently using a =E2=80=9Cweb_accepted_origins=E2=80=9D transp= ort parameter but > could > >> >> >>> easily use an application parameters mechanism instead. > >> >> >>> > >> >> >>> I see two downsides to this proposal. The first is that the > client=E2=80=99s > >> >> >>> application parameters are sent in the clear. Application > designers > >> >> >>> will need to make a decision of how much they want to use this > >> >> >>> functionality (they could limit what is sent by the client or > only use > >> >> >>> application parameters in the server direction). For H3, there > are > >> >> >>> only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, > QPACK_BLOCKED_STREAMS, > >> >> >>> and MAX_HEADER_LIST_SIZE, which do not reveal any information > about > >> >> >>> the user or the server they are connecting to and are likely > constant > >> >> >>> per H3 implementation. > >> >> >>> > >> >> >>> The other downside is that if too much data is put in applicati= on > >> >> >>> parameters, it could cause the number of packets for a client o= r > >> >> >>> server=E2=80=99s flight to go from N to N+1, which would increa= se the > chance > >> >> >>> of head of line blocking. > >> >> >>> > >> >> >>> Related issues: > >> >> >>> https://github.com/quicwg/base-drafts/issues/2790: Binding > settings > >> >> >>> into session tickets > >> >> >>> https://github.com/quicwg/base-drafts/issues/2945: When to send > the > >> >> >>> SETTINGS frame > >> >> >>> https://github.com/quicwg/base-drafts/issues/2783: Consider > making > >> >> >>> SETTINGS part of the control stream header > >> >> >>> https://github.com/quicwg/base-drafts/issues/436: Move SETTINGS > into > >> >> >>> TLS Handshake > >> >> >>> > >> >> > >> > >> > >> -- > >> Kazuho Oku > > > > -- > Kazuho Oku > --000000000000cfe5d40594956aab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I filed=C2=A0https://github.com/quicwg/base-drafts/issues/3086=C2= =A0for this issue and so we can discuss it next week in Cupertino.
On Wed, O= ct 2, 2019 at 4:50 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
2019=E5=B9=B410=E6=9C=883=E6=97=A5(=E6=9C=A8) 6:21 Davi= d Schinazi <dschinazi.ietf@gmail.com>:
>
> If we decide that the first requests need to operate without knowledge= of settings,
> we're effectively crippling the main extension mechanism we have i= n HTTP/3.
> I'm not comfortable saying that for the entire lifetime of QUICv1 = we cannot have
> extensions that impact the first requests. That feels like painting ou= rselves into a corner.
>
> There are many features that we can punt out of QUICv1 and figure out = later as extensions,
> but it's critical that we build an extension mechanism that allows= that.

For HTTP/3, I think that we'd likely be fine with not having settings delivered before issuing requests. That's how HTTP/2 has been, and we are used to dealing with that. Though admittedly, QPACK is more
disciplined on what can be done in such case compared to HPACK.

Other application protocols using QUIC v1 can define their own TP, if
having settings exchanged before 1-RTT data becomes a critical issue
for them.

>
> On Tue, Oct 1, 2019 at 6:23 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> 2019=E5=B9=B410=E6=9C=882=E6=97=A5(=E6=B0=B4) 9:21 David Schinazi = <dschinazi= .ietf@gmail.com>:
>> >
>> > Additionally, the current status quo makes it hard to have SE= TTINGS
>> > play nicely with 0-RTT. Fixing this is important to deploying= IETF QUIC.
>>
>> While I understand and share the pain, I am not sure if this shoul= d be
>> a blocker for QUIC v1, as 0-RTT is essentially a must-implement fo= r
>> HTTP/3 (the primary application protocol for QUIC v1).
>>
>> 0-RTT requires clients (and servers) to operate without the knowle= dge
>> of the settings that are sent by the server. Until the client rece= ives
>> the settings of the server and switches to using 1-RTT packets, th= e
>> client is expected to use the settings of the previous connection.= The
>> server is expected to accept 0-RTT only if it knows that the setti= ngs
>> parameters of that the client is using for 0-RTT.
>>
>> Assuming that we cannot remove this requirement, I do not think it= 's
>> too complicated to require endpoints when using 1-RTT to operate >> without the knowledge of settings (i.e. operate with a very
>> conservative set of properties) until it receives the settings fro= m
>> the peer.
>>
>> > We're chartered to produce a protocol with fast connectio= n establishment,
>> > and if we fail to negotiate options and extensions nicely wit= h that, we'll
>> > harm extensibility long-term and cause deployment of damaging= workarounds.
>> >
>> > David
>> >
>> > On Tue, Oct 1, 2019 at 4:41 PM Nick Harper <nharper=3D40google.com@d= marc.ietf.org> wrote:
>> >>
>> >> I think it loses most of its utility if it's not a v1= feature. The
>> >> main motivation for the feature is to simplify applicatio= n protocols.
>> >> At the time that v2 is introduced and application protoco= ls are being
>> >> specified to use it, existing application protocols will = already have
>> >> an application-specific way to negotiate params, so they = will continue
>> >> to use that instead of using both the existing applicatio= n-specific
>> >> mechanism (for v1) and v2-only application parameters fea= ture (for
>> >> v2+). (I'm assuming that as applications switch from = using QUIC v1 to
>> >> QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS= 1.3, instead
>> >> of like upgrading H2 to H3.)
>> >>
>> >> On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla <ekr@rtfm.com> wrote:
>> >> >
>> >> > Does this need to be a 1.0 feature?
>> >> >
>> >> > On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie <ted.ietf@gmail.com&= gt; wrote:
>> >> >>
>> >> >> Hi Nick,
>> >> >>
>> >> >> Two points in addition to the privacy issue alre= ady raised make me concur with Roberto that this should be v2 or later.=C2= =A0 The first is this:
>> >> >>
>> >> >> "Negotiating or advertising features is som= ething multiple applicationswill need to do and is not a feature specific t= o H3."
>> >> >>
>> >> >> Absolutely true, but there is also a fairly larg= e variability in how applications do this.=C2=A0 If we design something now= that works for H3, it may very well be sub-optimal or useless for later ap= plication targets.=C2=A0 Getting something general enough to handle DNS, WE= BRTC,=C2=A0 SMTP, plus the various flavors of IoT protocols I've heard = as targets hoping to move to QUIC is going to take time and care, and it wi= ll block completion of v1.
>> >> >>
>> >> >> The second is this:
>> >> >>
>> >> >> *The other downside is that if too much data is = put in application parameters, it could cause the number of packets for a c= lient or server=E2=80=99s flight to go from N to N+1, which would increase = the chance of head of line blocking.
>> >> >>
>> >> >> Depending on what counts as application paramete= rs, this could be more than N+1.=C2=A0 Someone running NETCONF over QUIC, f= or example, would be using a fairly verbose syntax in which each parameter = is a full URN.
>> >> >>
>> >> >> regards,
>> >> >>
>> >> >> Ted Hardie
>> >> >>
>> >> >>
>> >> >> On Thu, Sep 26, 2019 at 5:52 PM Nick Harper <= nharper=3D= 40google.com@dmarc.ietf.org> wrote:
>> >> >>>
>> >> >>> I propose introducing application parameters= to the QUIC handshake and
>> >> >>> using this new mechanism for H3 SETTINGS ins= tead of sending them as
>> >> >>> the first thing in the control stream. Appli= cation parameters would
>> >> >>> allow applications using QUIC to advertise o= r negotiate
>> >> >>> application-specific parameters during the c= ryptographic and transport
>> >> >>> handshake. It would guarantee that the clien= t and server have
>> >> >>> exchanged their application parameters once = the handshake is complete.
>> >> >>>
>> >> >>> Specifically, I=E2=80=99m proposing a new = =E2=80=9Capplication_layer_parameters=E2=80=9D
>> >> >>> transport parameter, which when sent by the = client is a series of ALPN
>> >> >>> identifiers with an opaque blob of applicati= on parameters per
>> >> >>> identifier, and when sent by the server is a= single opaque blob of
>> >> >>> application parameters for the application i= dentified in the ALPN
>> >> >>> extension.
>> >> >>>
>> >> >>> Negotiating or advertising features is somet= hing multiple applications
>> >> >>> will need to do and is not a feature specifi= c to H3. Whatever we do in
>> >> >>> H3 will likely be copied by other applicatio= ns using QUIC. By
>> >> >>> providing a general mechanism in QUIC transp= ort, we provide
>> >> >>> applications with a consistent way of achiev= ing this goal. QUIC has a
>> >> >>> design pattern of collapsing multiple layers= into one to save on round
>> >> >>> trips (e.g. combining crypto and transport h= andshake); this fits in
>> >> >>> with that pattern.
>> >> >>>
>> >> >>> Using application parameters for H3 SETTINGS= clears up some issues. H3
>> >> >>> doesn=E2=80=99t need to specify that an endp= oint shouldn=E2=80=99t wait for its peer=E2=80=99s
>> >> >>> SETTINGS since they=E2=80=99ve already arriv= ed. Likewise, there is no
>> >> >>> confusion about whether SETTINGS arriving af= ter session tickets are
>> >> >>> bound to the session tickets; SETTINGS arriv= es before the tickets and
>> >> >>> the client doesn=E2=80=99t need to wait for = the receipt of SETTINGS to bind
>> >> >>> them to the ticket. It also simplifies the s= erver binding SETTINGS to
>> >> >>> the ticket since that is done as part of bin= ding transport parameters
>> >> >>> to the ticket.
>> >> >>>
>> >> >>> This also provides opportunities for future = features. Since the
>> >> >>> exchange of SETTINGS occurs before applicati= on data, a new feature
>> >> >>> doesn=E2=80=99t need to be specified in a wa= y to provide an upgrade path from
>> >> >>> =E2=80=9Cvanilla=E2=80=9D H3 to something in= cluding this feature, and instead be
>> >> >>> guaranteed that the new feature can be used = for the entire connection.
>> >> >>>
>> >> >>> Without application parameters, each applica= tion that needs to
>> >> >>> advertise or negotiate application settings = needs its own mechanism to
>> >> >>> do so. This would result in multiple transpo= rt parameters or
>> >> >>> extensions leading to duplication of work an= d layering violations..
>> >> >>> Applications could instead exchange these se= ttings in application
>> >> >>> data, meaning that each application needs to= define the semantics of
>> >> >>> application data received before and after t= he settings have been
>> >> >>> exchanged, as H3 currently does.
>> >> >>>
>> >> >>> There is already a demonstrated need for an = application parameters
>> >> >>> mechanism in the QUIC handshake. One example= is
>> >> >>> https://too= ls.ietf.org/html/draft-vvv-webtransport-quic-00 which is
>> >> >>> currently using a =E2=80=9Cweb_accepted_orig= ins=E2=80=9D transport parameter but could
>> >> >>> easily use an application parameters mechani= sm instead.
>> >> >>>
>> >> >>> I see two downsides to this proposal. The fi= rst is that the client=E2=80=99s
>> >> >>> application parameters are sent in the clear= . Application designers
>> >> >>> will need to make a decision of how much the= y want to use this
>> >> >>> functionality (they could limit what is sent= by the client or only use
>> >> >>> application parameters in the server directi= on). For H3, there are
>> >> >>> only three SETTINGS, QPACK_MAX_TABLE_CAPACIT= Y, QPACK_BLOCKED_STREAMS,
>> >> >>> and MAX_HEADER_LIST_SIZE, which do not revea= l any information about
>> >> >>> the user or the server they are connecting t= o and are likely constant
>> >> >>> per H3 implementation.
>> >> >>>
>> >> >>> The other downside is that if too much data = is put in application
>> >> >>> parameters, it could cause the number of pac= kets for a client or
>> >> >>> server=E2=80=99s flight to go from N to N+1,= which would increase the chance
>> >> >>> of head of line blocking.
>> >> >>>
>> >> >>> Related issues:
>> >> >>> https://github.com/q= uicwg/base-drafts/issues/2790: Binding settings
>> >> >>> into session tickets
>> >> >>> https://github.com/q= uicwg/base-drafts/issues/2945: When to send the
>> >> >>> SETTINGS frame
>> >> >>> https://github.com/q= uicwg/base-drafts/issues/2783: Consider making
>> >> >>> SETTINGS part of the control stream header >> >> >>> https://github.com/qu= icwg/base-drafts/issues/436: Move SETTINGS into
>> >> >>> TLS Handshake
>> >> >>>
>> >>
>>
>>
>> --
>> Kazuho Oku



--
Kazuho Oku
--000000000000cfe5d40594956aab-- From nobody Sat Oct 12 01:24:52 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E9E12008A; Sat, 12 Oct 2019 01:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 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, UNPARSEABLE_RELAY=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 haYrQwozz2g2; Sat, 12 Oct 2019 01:24:48 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7ADE120047; Sat, 12 Oct 2019 01:24:47 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 46qyYB3gy6z8tDv; Sat, 12 Oct 2019 10:24:46 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 46qyYB1KKHz2xC0; Sat, 12 Oct 2019 10:24:46 +0200 (CEST) Received: from OPEXCAUBM41.corporate.adroot.infra.ftgroup ([fe80::857d:4f67:b0a7:10d7]) by OPEXCAUBM6C.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Sat, 12 Oct 2019 10:24:45 +0200 From: To: "quic@ietf.org" , "ietf-http-wg@w3.org" CC: "quic-chairs@ietf.org" , "httpbis-chairs@ietf.org" , "quic-ads@ietf.org" , "httpbis-ads@ietf.org" , "allison.mankin@gmail.com" , Gonzalo Camarillo Subject: LS from 3GPP on QUIC network level troubleshooting capabilities Thread-Topic: LS from 3GPP on QUIC network level troubleshooting capabilities Thread-Index: AdWA0hpjWJ/tXLvVSCu8fqJq00l+9A== Date: Sat, 12 Oct 2019 08:24:45 +0000 Message-ID: <20859_1570868686_5DA18DCE_20859_72_1_6B7134B31289DC4FAF731D844122B36E3A240FE0@OPEXCAUBM41.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/mixed; boundary="_006_6B7134B31289DC4FAF731D844122B36E3A240FE0OPEXCAUBM41corp_" MIME-Version: 1.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: Sat, 12 Oct 2019 08:24:51 -0000 --_006_6B7134B31289DC4FAF731D844122B36E3A240FE0OPEXCAUBM41corp_ Content-Type: multipart/related; boundary="_005_6B7134B31289DC4FAF731D844122B36E3A240FE0OPEXCAUBM41corp_"; type="multipart/alternative" --_005_6B7134B31289DC4FAF731D844122B36E3A240FE0OPEXCAUBM41corp_ Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E3A240FE0OPEXCAUBM41corp_" --_000_6B7134B31289DC4FAF731D844122B36E3A240FE0OPEXCAUBM41corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4). This WG is actually studying the introduction of QUIC as transport protocol= instead of HTTP/2 in the 5G core network. The WG has some questions regarding the troubleshooting capabilities suppor= ted by QUIC compared to the ones available with TCP. The LS is officially addressed to the QUIC WG. However, it was highlighted = that httpbis WG could also be interested in. I will let you decide if only = QUIC or both are relevant in the discussion. Next CT4 WG meetings: 3GPP TSG CT4#95 11th - 15th November 2019 Reno, US 3GPP TSG CT4#96 24th - 28th February 2020 Sophia Antipol= is, FR It would be good to receive an official feedback at the latest for the Febr= uary meeting, where the study will be concluded (at least for this release). Regards, ________________________________ [http://www.orange.com/sirius/logos_mail/orange_logo.gif] Lionel Morand Chair of 3GPP TSG CT 3GPP Liaison Person to IETF Chair of IETF Dime and Radext WGs Core Network Senior Architect and Diameter expert Cell. +33 6 07 75 89 36 lionel.morand@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E3A240FE0OPEXCAUBM41corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Please find enclosed a liaison = statement from the 3GPP CT WG 4 (CT4).

This WG is actually studying th= e introduction of QUIC as transport protocol instead of HTTP/2 in the 5G co= re network.

The WG has some questions regar= ding the troubleshooting capabilities supported by QUIC compared to the one= s available with TCP.

 

The LS is officially addressed = to the QUIC WG. However, it was highlighted that httpbis WG could also be i= nterested in. I will let you decide if only QUIC or both are relevant in th= e discussion.

 

Next CT4 WG meetings:

3GPP TSG CT4#95  &nbs= p;        11th – 15th November 201= 9       Reno, US

3GPP TSG CT4#96  &nbs= p;        24th – 28th February 202= 0          Sophia Antipolis, F= R

 

It would be good to receive an = official feedback at the latest for the February meeting, where the study w= ill be concluded (at least for this release).

 

Regards,

 

3D"=

Lion= el Morand
Chair of 3GPP TSG CT

3GPP Li= aison Person to IETF

Chair o= f IETF Dime and Radext WGs
Core Network Senior Architect and Diameter expert

Cell. +33 6 07 75 89 36
lionel.morand@orange.com

 

 

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E3A240FE0OPEXCAUBM41corp_-- --_005_6B7134B31289DC4FAF731D844122B36E3A240FE0OPEXCAUBM41corp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=998; creation-date="Sat, 12 Oct 2019 08:24:44 GMT"; modification-date="Sat, 12 Oct 2019 08:24:44 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAyADIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCxRRRX 52fpgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAWbXT7y+3fZbaSbZ97YOlEen3ksTypaytGh IdgvCkdc1s6PfWv9kpZy37WMkVyJy4H+sX0qXUdctbq0kSKWSNZb3fIi8Ex4xmu+OHo+zUnLX5HB LEV/aOCjpfz/AK1/4cw5NLv4ljaS0lUSHCEr1NJPpt9bKjTWksYkbapZep9K63+2tKhTy47tGQXK SIApyFA7nuaq2mtQNNIGdp5H1HzY0PUp6itJYSgnbn/Iyji8Q1fk/M52bStQt9vnWcybiFXK9Se1 S/2W8LbL5jZueV8xeCK7Bp4dEtIprmeWdDfM/wC8GCoPoPaub16+juIILeK6huER2ceXHt2596Vb C0qMW29e39foOji61aSilp31/r7zDf5XYD5gDgH1ooorzT0wooooAKMleQSCOhHaiinHcT2Hy3E9 w486aSTA43sTj86ZRRWlf+IzKh/DQUUUVkbH/9k= --_005_6B7134B31289DC4FAF731D844122B36E3A240FE0OPEXCAUBM41corp_-- --_006_6B7134B31289DC4FAF731D844122B36E3A240FE0OPEXCAUBM41corp_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="Liaison Statement on QUIC network level troubleshooting capabilities.docx" Content-Description: Liaison Statement on QUIC network level troubleshooting capabilities.docx Content-Disposition: attachment; filename="Liaison Statement on QUIC network level troubleshooting capabilities.docx"; size=28096; creation-date="Sat, 12 Oct 2019 08:21:04 GMT"; modification-date="Sat, 12 Oct 2019 08:21:04 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDuIuk+yQEAADcIAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lU+P0zAQxe9IfIfIV5S4ywEh1HQPyyJxgZUo4uzak9ba+I88093tt2eSNlEXunWh20ul1Jn3fh47 b6bXT64tHiChDb4WV9VEFOB1MNYva/Fz/qX8KAok5Y1qg4dabADF9eztm+l8EwELrvZYixVR/CQl 6hU4hVWI4HmlCckp4se0lFHpe7UE+X4y+SB18ASeSuo0xGz6GRq1bqm4feK/tyQJWhTFzfbFzqsW KsbWakVMKh+8+cOl3DlUXNm/gysb8R1jCHnQoVt52WBX951bk6yB4k4l+qYcY8jHkIw0Qa8d76E6 LnOAMzSN1TDWd2oxBQ2I3HPXVuOKU9YP/C9y+LVbQOLK1wcZpbMQSJsW8PUJtron2v+ytLptGtB8 4/KH4rDsOl9tLfZq825AxP0+xeT5d1DmTh53ylmER1j8uBjFnngWpAmBfKBLnP0onYUAby7EMChn ERrOqblatHDCzfvHSzFKZyGIwxdk/3t1Nkcvc8ySY+ouhYgc5uk/tj2kdVddcv5FSGRhzOtDeTc6 8iA4e3/QjRoD5kTvPvN1cF3k41dzgY9/T/xY25+B9POSN3F2N/4aQgPN4DAgyX7sz34DAAD//wMA UEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbv Bd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2Jtg R99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+R zBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9Swa bDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4B AAD//wMAUEsDBBQABgAIAAAAIQDsxNKv9QEAAMsHAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54 bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyVTW/bMAyG7wP2HwLd a9nJljZFne6wbgiwAUWbYcdBkWlbqC0JEts0+/VjEjhxPqxihS+2Rcl8H7yUxJvb17oavIDzyuiU JVHMBqClyZQuUvZr/u3iig08Cp2JymhI2Qo8u51+/HDzAJVA+smXyvoBZdE+ZSWivebcyxJq4SNj QdNMblwtkIau4FbIJ1EAH8bxmLt2DjY9yDmYZSlzs4z05ytLym/nNnmuJHw18rkGjWckeEmZXKX0 EyUVrgBMWS1UheZ69P3+/ocSyhv9BdCrNWyz6KfJSP/uFcFpUTF+HjQZdZDWSjrjTY6RNDXfQhJc Mubx5NACTgvW6H6W+UY8Za1gRG526f+nfHx5pO1xVYH/rbC8y3OQ2CI4mQpxXHbYcGYzvF0w0Jk2 SHtuV68mEkJIhh0MXaVIjrxoLF/XXGeQ7eWPZ0IYXRTvcmJbgz3IdhySTzpMeJe8fq4X4OhW2BPs QiGIcZ8QuTF4tB12oRBE0qsVSJcb7G3YDPnmmYQgPvfpxBIWj4BI9WgdjVYwBJLQHd/flZobjXOx qFqO7EIhik99QvgTL5pICGHSJ8KZ1rLuWJ7a4XK5jEaFtZsGmKPljxak58LJUr1QK5z88XS0wNNX dDUZ0YueF8kwjv4qS4ybTnXahPhBC57+AwAA//8DAFBLAwQUAAYACAAAACEAPhUHGJIUAADXegAA EQAAAHdvcmQvZG9jdW1lbnQueG1s7F3bcqPIln2fiPkHQuelOqIscxMIz7HOQUiqqYi6eGx39GMH lpBFGAEDyG730/zD/Eh/Q3/KfMmsnYCUiRCSdauqjlMPJRun8rJzX9a+ZPL3f/w2D6RnL0n9KLxu KW25JXnhOJr44eN16+f70UW3JaWZG07cIAq969arl7b+0fv3f/v7y9UkGi/mXphJ6CJMr17i8XVr lmXx1eVlOp55czdtz/1xEqXRNGuPo/llNJ36Y+/yJUoml6qsyOynOInGXppiPMcNn920VXQ3X+8t ir0QY02jZO5maTtKHi/nbvK0iC/Qe+xm/oMf+Nkr+paNspvourVIwqtiQhfLCdFXrvIJFR/lN5K1 VdSMm39zUFCAjXiZeAHmEIXpzI9Xy9i3NyxxVk7puWkRz/OgbPcSK/raeMsl77IHg8R9wVasOlzr roYYk/xL8yCnA+3valerPSpy02KKHaEulnPYZQrimOVM5q4fLrvZjzQ8cSERh/D3hyRaxMvpxP5h vX0Mn5Z9kWC+YWaywSSPX1r6pg7WRPdu5sZeS5qPrz4+hlHiPgSY0YuiS8SRrR6UxUM0eaXPWMLj q9hN3I+T65Zq2orTHaot9jTzfsvoqaF0lE7X0fD0CoppcnvdkmXNkpWhsnx0AzGVZdPs9Lv95cOB N3UXQbbe/IZ7xGZxk7CPu+w18DDKsxtct5xbJ4ImvHEfvdYl/TlzH9Lis2yT+I+zjMaLI5DMMjSL ml6u2qaxO4YAoYU7zTyaZN5Xko/4wDr22f9hdJNE0ZT9nP5ejqB2ix7ZN9BznH8zQQNGDGHlND2h 6w2d6nynmG1P+3BzI93ffbhw7qVfPujSZ8/LaN5/s3S2HLYoRqQdB959TYxYOdXeMsCuK3P0i00r YCyjKJ2RtWSZ41BT2Uw1bsy9N0u3LGFJxBXUmShMsm7r+qAzwNogYqUwmcW/5Yo5UahlqfLhkYUp WmSBH3qfnoOS0+skY5dNPplM3ERJFiXR7++luwCaIPTd/5BkU6A8pK2kz/6cA33jJZkd+I9hSYt0 EQODjRM/zqqSms2OPwOQsNAaDL1dkdaCxo4TL/WSZ6/Vk/7vf/5XUpTjj/wjrP3rOIsevEQCRt1F 7hRFcUxzpO8gd7qhGWZnKYoCC5V8xcmd2JwZMXmkD3WNmdTCMMSCERuGF1lW2K+4P2EK9iHKsmi+ ZDWo+QDG+uUq/f26RbMut59Z13EURDBb7iKLCk4su6kxh+PAcxPqgZlDXelo9B2m4MvhxCZdDdC8 2mSrUS14NRlFYZaiYzcd+4BPduK7wL4vVzM7TPnfx7DN+R/ZUA/5/07KPjlTy6wi0cGhXhkIUAVL WaqaDQrX0VTLVB1MYZvCFXfydseNZzq+MP/Fx14kKMV9y3L6g6FqyyNxObrjdEcD3SY6L8HYfssp etiJj+/9LGFsXM65SfNmPTQPvKud1RVYGbxAZGE2mV/aSDZ0awUphZ1irN37tPsw5MuW0rVSrndS FEqbOiHzPJQVMBYT8g36mcG3pi7Uvm5bw7yLnnPf1HT7aECITR3wY9WvWG9crgr20hqXO/W8yYM7 fmruJl9yuZn5ztkDtSt3m0iJvfivnz86jV1X/Ixduw69DI7pkxR4z14gZfD/4BilsyhiUHtXkvbG buyy0IbvpcKXSDaYjhCcKtNSFa1jV5wqXVVVuFCiU/XdyfEvRK6PmTc/iizXblvxMJfl0d2vtPk7 UFW2FbigDuJjp1f2a06kUWBlP5yAvQNvCh9XsboMSczc8BEmvXjATNwR7CXpRjI5pfqtZzW1b+uO NqB5cBZQ66q2IXNKlHTa6VntLlok4zfYjLz9cRitozsysQbvonf7sj6Sm1TPVi1ey8B8v1tUu7nf vLboe95g9MRwQT2bGPbIshS54plqfatrmQpCtQXZvk82uY+OwyJiqCo3IcJWfhzej5gp2kUbadrQ 6jBUxgmebg1ts68TID0nVnur4Dnj/Shaz1yKOlKGfY3YiCNFbdhjPx3ELGwOv7+1YmYuDMiwg2o2 OgNLszuE209OlhrPkGwUsSFzDFXVKKOaZdNDTVQtJUCYkvPXcPuhAxb+Qs4HWc+BK+qOM+kGYZso 3J2fD52GsG4xklovHh3LlruwAyIf6EOlq2n9c6PBgmrLCEA1vC4GCzazzYNABlp44R5v3P6s98Wd v8FDLPZJHEikN8dtLKaqqpquMnO/6cs9+2GCXKc7dyfSMJA+R27mzv3JDvreHJp619Epbn0aaS4I t5Nv/i138d4L2tKXxRzxuTcLXdNmbhCermY4RrcK+rWB1hkOdwAug45hmatkw2GhveOSHW4EHAds Owt7TZOL0S2JZdW4cEyeq9RiSWQUCzZnEcOyIxn/RqNcwBsHgCzVxwqGF0jbBlV3HAnlaDpMSL9n rzFi1WnsBcFd5iYsYH7KafbsyQSBcdH1hsqpndEwnOSLr1iiI5Ktt4XxjzjU5jCZlmu7Qm3cHp03 eu5SVba9YF5oyn8itxw+elTJsIPS1LuGrShWxe3YHRluld7vCBkyv79R4EorWa/p1K6mdm2tAhM6 ztDWB5Dncp/J0FmqNjRXPoaAtMp2nKYTmzMDUzziyFfCQnyiC6aS/uoI8s5DMMcNX6XEi4NX6dOd lL3B0yx07yEpkVLVl6hmo0ZmYYpPvusD6aaSE6E4xw9dpErfV7X0DKo5QZr3SUqufFRyJB8nqB9D gsZP0fwVMaocH5VswuGm8lHOTlyaq1ypkOb65HshG4zS3EW660i06JH5wVbQqotF/9PLUp/qzapK Z7leZg7FJXBxxnIJeyVvUDvD2eWNm1Tdior9OeJsBOxdMg8xUx4tZFLNYGpZ5WM4csc25bO4omWy 8kg5z4N2rhQw0rhlLHWdOupoiGCpOYScnAbac2r2HMsxZWOEiMw5lrMWjlFUsajkGCqh3L01iHlE kRIFvKe0pa8oEXGDQBp4eVUI6kpF2EfTWmcmuT+QZbtP+UuOmXR4IXqny/L7qxyuKg91pp3ZI85i mwNTs010wYKIzGJza91adlBjy0W//g11Alhl2d1BvAslKqgtblOJiEftG1POy+tYaZ1gMjgeYsHu fAtOMYN630qX/FSCiaYSaqr2c6Wp56ZF3TTqvBeTV8pNZzNPiqMMtd0osJAWKSoipWiap0nh9mQR XL6N9oZbmGgQZbvj9Ad8gGRv8RT2cqNJxCrZUpq2wBgpaneFbwv0ce6Zbk0E6aKwFpg7L2U8Bfv0 Oo0Z/1qqmaebTj03V1nwIYqe6EAAiwqA9wiBsqRciNDfdevXD1EfNQS5e162hb++bMl8qKRk2o18 7JhAMwWQLcKO+wK7Kh/3xEx0RV3UUv2Us4kST/qS1zA0yVDBnKfgww0b74cSicyff9zf/vmHarW7 lia9C9w0K4+ySO4zUDzVoUvPvsu0wDQKgogON0jkoFxVmWcJ5VeuCwvcNbkutVLZhQHWRDV3Otdl jYHoGECKEzgvLy9t7TGO2SmZaRZf3sXeOL10k/HMf/YuVetXVHqingQ/EfXwgf8vgJ/av/uxsNkw lUvasC2uEZBTbH3vp7Ywj4ow1NL+/JxYneJJKMHMw3eKJsaLJAFQQATjxfVZXVNpdnEeCuCCIQcC FFM/gXyyAz6EKoozZ4QrqjTkGWzUAWjonBE0bK0FOyGP9W5HjgTdhgALyo+zCKGhFEfsECWaSOMo HAeLiQddBgzHoJooH/UOgWEOu6NutVAAzrhiaqgq4kndJFFlO85LEJv/pb2EetJq1sgxNbOSHNJN 3VCszgpSEo4o3KeSittCpmLZzl+atNDqp1CZ9bhhK8xu2qfzTdO5X6+XPd/ov3xoVMgnVH/1mzbD eWSvcUrfx64l3rPvvXiTrS5n7XRPSNYeKyzDId1pduF72fTivxf++CJDJi2NceKp+bTc0BgZq9r/ XHGdcq6VEzcV0DccaN1BXlJ57JBNPfM18p2iGd2uUPFxtIBGDya/CRbV8lDx8HyqQnqJFkHjPGVH 6cv5MYTvYMPOTbVe4D8BsEUSgmbPPsNuwMFLP7Q81dC00ecnIOJ/zecW+OMIZViwaQknFJMNQuum gMu4ESIhbRxJ986N9G48bUvjwF2k3p9/WG2jrdHUGSDgYgjkuswp6jHxMsQP0p+a1nVKNbhLrF/V hygvkimqz8X6a8sbKozPoXjxL39pqFmP4juOogwUFgLmqIiSSUc1nFXpFqH4gpFFFO/IxtCkszZ5 xTVHWrE5Iy0nCrVplL5SFA9V4orVA41C2IfWVVv+2B11EIrifWc6pI/mhSrOehttf27ot3ZQXx+U f7kgTJ01alwOpU+YE051ETiWnErI5c6kexRIkB8MYUZ2LFyGFeiOD2niT6cewhDUGmdkcFqMEh3Z zM3ypAX+krzGODtKgYgl8pFmngtHuyrje824Wh22DCMfTIwNOg6rdicTRFwoXxOxhcXuaxC5k/fS y8wfz4gCM1xXgcgMRWKeXdzUU4ZmmhU8rp7B1RVpW7oHtbzfULtBUdMiECx9tT9L774iicQuu6kC pLWquMfEnW8u0zuESew1iFQ7+KaKvAOG3rAln8GKSJq5YMOfpDQKFuw2oGI3YIxgVVKc+c+N0twF NIA1YkxNleTYRzJUOU/iPDJBK/xGzk8YZdIDWlI4m/aaO0iY8zdYmu5WYn3hrGGIE4cp5Aa7h+we GMCduDHyqPnXi/wfWIZkxE2fdokjaaqt6JZRPellOH1nhOL+Uv39iGryAEbYpkAP6Jqp1o2pTaYg /TwimGLbpSgmZkNcdY4tXyQeu5jrwc/eS5T8mmwV0y3ltAcspJfGfoiZVNTsmqyyGZxNWEsliRqL 6IWMxgUuEJsRUH+ADYGQFXTMjQ+ZDQgdzE+GKzogx4ELoaJf8YeJR2AzSnNdDFSZP6QmkOnKsit2 gQMEVf9oq5FkZhHXI2G+GDR9nc89zG4MHqCl7CLUpowDeKZZKZDVENN0NGXl9f9LqAtwd7Atb8RL m9PKtaxAVZWw7nQhFbQvK5l9RUl89EIQkgd5NuOPMt+iWO9zmwF5G/swGvmdddIkYmYGF9FQUAgs NH7yMimIYEc4lZLuwlY4AGAruEkCVoGD1IYuK6bTWRUO7xEYr4HUstxRUY1MoK0WUvMXopSlRPgs SXaMyiT+VHbHYIVTy0PZ9HteV1CB9G+9w2Q3yN+gpw8akED5FmfhhEPXiw3jn/yA816Q/b5ZNZ9w PfX4McLNmwyjwZyTT+PFMEgubPprCqBW2JUCvBHGlN557ce2NIXIU3YQqDB4L3nZuP0TkF/24gEG uvQHSiEmG+0QUdEeKpZh8Y7i8QKZLMTS+YCJAACXPsRoEY6Z5/Lum+1B78to09inJsnGqNJW+3Ko DNczHkMyLmGfyWIMVvkyel8CG/KaycMsuI8qArGNDH3O6SQjCgMZb8LtgZeJxAKF3MQMNs46EiBa ed1UFg6oAg+z7Jb1V1ic3P9p45gBONpNXgmL/ef9/c2lKtHtjBQHoNmRc4swH/VMEEjyEAAgJ2pK cIzNmsobgdCQlvFcVPzgtzgOCnMnAZyhLz+EQwxvt/ChS684B4G7WDp12O3oJu7ZESxdbQhOqzsw JUbfbrngUdH8W5q1KiB9E/OVAKQMTtEnWwyjVHkyQNdwr2cXl2hup9/xz+7/RYrF1bZkM2Wa7hI0 NvsjzdbZ8S0Omyn2QEM0uVIPstdldRzHbi7P5xHTee+x4RKKubYtRLAOQbyJ4Xc8pnMfNVriikI4 8RTzzDBp302m8MQT2GCPHummZGFK9epDtjRrMKpePySPhrLRscUKnP3URxHW2pAW2Y2/LUuDerta egT0++EeQVW/fmu+tp37j1+/rFXVJgUFb0/MSFs9BHEejo076/qHA95yF8g9IqAr8Cy3JVtclVMo mm+kZojTEQW/biEMmdmp71aiEfUSj9rWc5CO367mKw11XO1p5FGFo8AgYhD9zEusJ3UzoesuqTqK hdyPL54AFJC+aCIcB5SPtlPIiWzM5zFR/s7I1Eigk0IKXqKW95fh+jiWpqIMFzlo7gM8N5w0K+7w hHqIWFwCflueRGza32MVwHAz/a4EoxKshe/MvOFluLaJNjq8T+MI1VU/CG2EiHUTXUAVC5dWHIzp t9OFIgwIF7DiLjpM6TVNi7uL9liqqp6Vt9+VOxhqQMRnoNA7j+0a0mzNavxstKFyCeikZe5kPTe6 xKyk6pWOPhJraPYLjXKs1IsjqMBGA3OC7eltjDqe1qJV9JsYVTsRROaIXS8gosFE85rYlKwP+rZj VK5Rro3tNZnY0vHgYnti8x/AudxAIEd3rKFSyR7XEmg/73unUNJBmlQM2tAyawvpjoKAmc//IIpD PXdqbWngZqzC7QuutxGZtSIy266rPyJ5yIfB0ZRNFu7EHn49qaTivUU7xT4VhIpsE0e3hWhzx5b7 eJHT8r4L9raprmUYxiqCJKytRqLF5kyii0ccD9dkn4U7rjqKzCJDYMOy6W4RJnZPJjlY5U3g5cWZ 4JWzZJ2PKB9CmrsMq9CLqiSw3t+sztm4rzoRFmGiCb39rTj7IYbyyhLUdpz0bUGHzQ7MWvDYhusc 8zcJnXnffnSafYHDTFecrr+CiFP/glI62Ncp2Y3b0CXL33ph9F76+U4QPrKWTLsJGT1lKA/svlJB TR27bw0HDlWPri4mt01N7xJ6yB/ly6nYMw41iS8AZDqWK9EoDHepOLkKn3/p2NryMW6fly8DzHWs IWzzN2E49Xwog+n5H11f0Nva1O559+1Hp9nIe0gWVGCiyqp8XtJxsrfUsXdRPMNNNTYqbOIo8NP3 0uhWmFWpb1PUudwIMYodFOkdvkR+PnevZvx4Ry8dfcGlnIol51WL+Nno6qwMAO+Axp1J7PWmUPSP n10aMotias6uib1ir21b/ZrfuLj6nfTu6re8rOe6ZeKGPnQ0xTuQ6O2oHZOdHXhc0IkTTDDPjOJ6 MXohG6FfzIG+wpynjF7ydfOYu1A5GVila/5uWdCnfCN17/8FAAAA//8DAFBLAwQUAAYACAAAACEA uxq5zuYBAADsBQAAEQAAAHdvcmQvZW5kbm90ZXMueG1srJRdb5swFIbvJ+0/IN8nNmvUrCikqsY6 5XZdf4BrTLCKfSzbhObfz+YrWUFRP8YFoGPOe57Xh+PN7YusogM3VoBKUbwkKOKKQS7UPkWPf+4X 31FkHVU5rUDxFB25Rbfbr182TcJVrsBxG3kJZZNGsxSVzukEY8tKLqldSsEMWCjckoHEUBSCcdyA yfE3EpP2TRtg3Fpf7wdVB2pRLyenaqC58rUKMJI6uwSzx5Ka51ovvLqmTjyJSrij1ybXgwykqDYq 6YEWI1BISTqg/jFkmImLmbpdZgaslly5tiI2vPIMoGwp9MnGR9W8xXJAOlwycZDV8F2j49Wk3mj5 LT3IDG18K06CE7mZzci7JFl1+xD6e+rqa8WYXDLTdyRIjAxvQfi35kAiqVCjzMe25nxz/UR85v/+ ZaDWI44Wn1PbqedRKwzmO8jIdTt559bsuwQmo/tQUs1RJFmy2ysw9KnyRE28isIfibanwyJqEnfU ftFyTQ11YJAPiTxFi7j9Tkc+LQlrOx9c362yn1eZn+YQdfzFtdF1d4VUf3Dlv1NEyM1NfB/Gvg9l vKB15c5WAoUJt7E03m5wG/N33b73R9ocMAPlhKrbCX94DU9m2El2F8drcvVf2WcpLvjwzoZjevsX AAD//wMAUEsDBBQABgAIAAAAIQAsnYyD6QEAAPIFAAASAAAAd29yZC9mb290bm90ZXMueG1srJTd bqMwEIXvV9p3QL5PMFE3aVFIVS3KKrfb3QdwwQSr2GPZJjRvv2MCJC0o6s/mgqCx58x3PIzX9y+y Cg7cWAEqIdGckoCrDHKh9gn5+2c7uyWBdUzlrALFE3Lkltxvvn9bN3EB4BQ4bgPUUDZudJaQ0jkd h6HNSi6ZnUuRGbBQuHkGMoSiEBkPGzB5uKARbd+0gYxbiwV/MnVglnRycqwGmiusVYCRzNk5mH0o mXmu9QzVNXPiSVTCHVGbLnsZSEhtVNwBzQYgnxKfgLq/PsOMXEzUPWWmkNWSK9dWDA2vkAGULYU+ 2/isGlose6TDNRMHWfX7Gh3djOoNlt/Tg9SwBltxFhzJTRxGfkqS1ekcfH/PXX2rGNFrZrqOeImB 4T0Ir2v2JJIJNch87mguDxdH4ivf9y8DtR5wtPia2k49D1p+Mj9ARpft5F1asx8SGI3uY8k0J4HM 4t1egWFPFRI10U3gv0iyubgtgiZ2R42rlmtmmANDMCTyhMyidqMOMC/2azsM/lisblO62OImjDr+ 4nx01f18Kl5d+e+EUHp3F2393HehlBesrtzFiscw/jGUDjfrsI3hU7fv/aU2iZyBckLV7ZA/vsWn E/R09fCwWKZ4qf5H+kmKa07QXG/Lbv4BAAD//wMAUEsDBBQABgAIAAAAIQBCL5damAcAANIgAAAV AAAAd29yZC90aGVtZS90aGVtZTEueG1s7FnNixvJFb8H8j80fZf11a2PwfKiT8/aM7axZIc91kil 7vJUd4mq0ozFYgjeUy6BwCbkkIW97SGELOzCLrnkjzHYJJs/Iq+qW91VUsmeGRwwYUYwdJd+79Wv 3nv13lPV3c9eJtS7wFwQlvb8+p2a7+F0zhYkjXr+s9mk0vE9IVG6QJSluOdvsPA/u/frX91FRzLG CfZAPhVHqOfHUq6OqlUxh2Ek7rAVTuG7JeMJkvDKo+qCo0vQm9Bqo1ZrVRNEUt9LUQJqHy+XZI69 mVLp39sqH1N4TaVQA3PKp0o1tiQ0dnFeVwixEUPKvQtEez7Ms2CXM/xS+h5FQsIXPb+m//zqvbtV dJQLUXlA1pCb6L9cLhdYnDf0nDw6KyYNgjBo9Qv9GkDlPm7cHrfGrUKfBqD5HFaacbF1thvDIMca oOzRoXvUHjXrFt7Q39zj3A/Vx8JrUKY/2MNPJkOwooXXoAwf7uHDQXcwsvVrUIZv7eHbtf4oaFv6 NSimJD3fQ9fCVnO4XW0BWTJ67IR3w2DSbuTKSxREQxFdaoolS+WhWEvQC8YnAFBAiiRJPblZ4SWa QxQPESVnnHgnJIoh8FYoZQKGa43apNaE/+oT6CftUXSEkSGteAETsTek+HhizslK9vwHoNU3IG9/ /vnN6x/fvP7pzVdfvXn993xurcqSO0ZpZMr98t0f/vPNb71///DtL1//MZt6Fy9M/Lu//e7dP/75 PvWw4tIUb//0/bsfv3/759//669fO7T3OToz4TOSYOE9wpfeU5bAAh388Rm/nsQsRsSU6KeRQClS szj0j2VsoR9tEEUO3ADbdnzOIdW4gPfXLyzC05ivJXFofBgnFvCUMTpg3GmFh2ouw8yzdRq5J+dr E/cUoQvX3EOUWl4er1eQY4lL5TDGFs0nFKUSRTjF0lPfsXOMHav7ghDLrqdkzplgS+l9QbwBIk6T zMiZFU2l0DFJwC8bF0Hwt2Wb0+fegFHXqkf4wkbC3kDUQX6GqWXG+2gtUeJSOUMJNQ1+gmTsIjnd 8LmJGwsJno4wZd54gYVwyTzmsF7D6Q8hzbjdfko3iY3kkpy7dJ4gxkzkiJ0PY5SsXNgpSWMT+7k4 hxBF3hMmXfBTZu8Q9Q5+QOlBdz8n2HL3h7PBM8iwJqUyQNQ3a+7w5X3MrPidbugSYVeq6fPESrF9 TpzRMVhHVmifYEzRJVpg7D373MFgwFaWzUvSD2LIKsfYFVgPkB2r6j3FAnol1dzs58kTIqyQneKI HeBzutlJPBuUJogf0vwIvG7afAylLnEFwGM6PzeBjwj0gBAvTqM8FqDDCO6DWp/EyCpg6l2443XD Lf9dZY/Bvnxh0bjCvgQZfG0ZSOymzHttM0PUmqAMmBmCLsOVbkHEcn8pooqrFls75Zb2pi3dAN2R 1fQkJP1gB7TT+4T/u94HOoy3f/nGsQ8+Tr/jVmwlq2t2OoeSyfFOf3MIt9vVDBlfkE+/qRmhdfoE Qx3Zz1i3Pc1tT+P/3/c0h/bzbSdzqN+47WR86DBuO5n8cOXjdDJl8wJ9jTrwyA569LFPcvDUZ0ko ncoNxSdCH/wI+D2zmMCgktMnnrg4BVzF8KjKHExg4SKOtIzHmfwNkfE0Ris4Har7SkkkctWR8FZM wKGRHnbqVni6Tk7ZIjvsrNfVwWZWWQWS5XgtLMbhoEpm6Fa7PMAr1Gu2kT5o3RJQstchYUxmk2g6 SLS3g8pI+lgXjOYgoVf2UVh0HSw6Sv3WVXssgFrhFfjB7cHP9J4fBiACQnAeB835Qvkpc/XWu9qZ H9PTh4xpRQA02NsIKD3dVVwPLk+tLgu1K3jaImGEm01CW0Y3eCKGn8F5dKrRq9C4rq+7pUstesoU ej4IrZJGu/M+Fjf1Ncjt5gaampmCpt5lz281QwiZOVr1/CUcGsNjsoLYEeo3F6IR3LzMJc82/E0y y4oLOUIizgyuk06WDRIiMfcoSXq+Wn7hBprqHKK51RuQED5Zcl1IK58aOXC67WS8XOK5NN1ujChL Z6+Q4bNc4fxWi98crCTZGtw9jReX3hld86cIQixs15UBF0TA3UE9s+aCwGVYkcjK+NspTHnaNW+j dAxl44iuYpRXFDOZZ3Cdygs6+q2wgfGWrxkMapgkL4RnkSqwplGtalpUjYzDwar7YSFlOSNpljXT yiqqarqzmDXDtgzs2PJmRd5gtTUx5DSzwmepezfldre5bqdPKKoEGLywn6PqXqEgGNTKySxqivF+ GlY5Ox+1a8d2gR+gdpUiYWT91lbtjt2KGuGcDgZvVPlBbjdqYWi57Su1pfWtuXmxzc5eQPIYQZe7 plJoV8LJLkfQEE11T5KlDdgiL2W+NeDJW3PS87+shf1g2AiHlVonHFeCZlCrdMJ+s9IPw2Z9HNZr o0HjFRQWGSf1MLuxn8AFBt1k9/Y9388v8DVg7xI/2V7W3JmzpMr0JX1Vr0Bf4tcbhy/xPQLZ58tW Y9JtdgetSrfZn1SC0aBT6Q5bg8qoNWyPJqNh2OlOXvnehQYH/eYwaI07lVZ9OKwErZpaR6dbaQeN Rj9o9zvjoP8q72fABFkeyY0Cdta87v0XAAD//wMAUEsDBBQABgAIAAAAIQBZYImCMgYAAKUSAAAR AAAAd29yZC9zZXR0aW5ncy54bWy0WEuT2zYMvnem/8HjczemJOrZOBk9k02zTSZOeuiNlmibE0nU UPQ6m19fUI91vItNM830ZAogQADfJ4jw85dfmnpxy1UvZLteWs/IcsHbUlai3a+Xnz4WV8Fy0WvW VqyWLV8v73i/fPni11+en6Keaw3b+gW4aPuoKdfLg9ZdtFr15YE3rH8mO96CcidVwzQ8qv2qYerz sbsqZdMxLbaiFvpuZRPiLSc3cr08qjaaXFw1olSylzttTCK524mSTz+zhfqRc0fLTJbHhrd6OHGl eA0xyLY/iK6fvTX/1RukeJid3H4vidumnvedLPK9nVO6J6mqe4sfCc8YdEqWvO8BoKYe022YaO/d WPSRo/tSP4NSr8azV8YVmFtkWJ0j7+tH9gjaI4pvxVYxNcIMBDBRNGV0vW+lYtsaSHWy6PIFMOqr lM3iFHVclQAS0JGS5cooIBm522imOaj7jtf1wM+y5gycnaK9Yg0wa70cJYONVqz8/IHfCkPtfhBV fMeOtf7IthstO7C7ZZCGb0+nHO66A28HSvwNZJ/11HbHKCrRdzW7ey2V+CpbzepMsRME8kqJKod3 6G62mPxN+//iSovy33fLP6X+1PMbpvai7QupvnH/TgkQDkm08v2xLfVxiPMPrlqIYFCUBwYpa642 HStBmEKMStZzUJXxn8J7p4AWY0I7KXUrNX+vTJHnJzAQ1Xp5ZV1umsRDbqvz7tGWt9XZ0fTwwM+l dHZzYTh2BRPLuNqMHQYctawBnozSqWvcyIob7I9KPKLik1Q2BgPowLixaEMjeniQBDQBVA5MqflG 39W8gGJuxFcet9WbY68F9KEBgJ+I4HsBAA3h5HfQPz/edbzgTB8Btv/psIEZRS26G6GUVNdtBW/f zx4GFDnDCZ+Xqje4msUHYN0MAyGh7eR+OtbCaM8aQlz7CU3spkmG2qRWQnJUk1teWKCagubUwTSW bRdFjGocLwhsVOPSIsa9eSRI0AiszE7wCOzAoxZ6DljEIZqpndHY8bHYHOJmCVprx7Ydip7jhMTK p1ZwiY8Te8XcOh9ocsd30XOoTXIaYLFRCKBAq0M9x/OnFnx5Dg1c6qE1oFBPHDmaOraHx5Y6hYui TVOapWhscH6IR+0GNCFopm5I7RzVeMS3AzRTzyJPePN8mmW4twKM0Ki9wrIDVONblluEGD6g8fKp aV6i4NtekaKM9x3qh9PH8IGNa6U5ipzv0pQ8YeO5OAq+D0xA+4Hvu5aNvgugSYIEzTSx8vni8SBq iCz1UJvMd2L8nNwrPJRVgWOFOHsDF5oiGlsQeE6Bvo1B6HkeimmQEFqgFQ0SGgSoJiTUJ2gET/fr MCB+jGIahlYBN/zhg3tZ0TBx3RStTphbEB1qU3g5/pbEFokDFIUY+rWF8joGkgYod+LMDvA3OM4B OdxbAc7QdyFxrBivdUpcx0Y7Ukq83Ee7cuq7sY/yII3hy4AiB5oiQdHOXC/00Xyy0HN8tKJZ7kBj xvDJiWWHqE1OaIyjnROX4sjlNvEI2ndy+Jj4aKZ55gQZminQkIaoDXzK0gyNugCKJkNXhjuNoS/c ZJrIjHvm7juuzPVw0YxXy5Q1WyXY4sYMhMD5Jtqqz4loZ/2Ww0DMv9VsjttZeXU1KvqG1XUB9/lZ MaTTRGamyPhucFuPo8KDHQqVwujz5t6Xma64eqXksRtPOynWjde+2ZlFxxbYRKLVb0Uzy/vjdjNb tTDUfaM6ttW7W2Ucrs7lOUUa/gsYrs9vWbufb3e8vXo1wVDWamP+L4DBp+tgbIEt2721XtZif9CW ufJqeKrgf4PhYbu3J5096ODJ6IYHVprMYPe0MBvGJeyaFmeZM8ucswym4nEfPcvcWeaeZd4sg/8t ThEMjlzBSPoZBpF5aeQ7WdfyxKvXs3C9fCQy9TpFwxX8ui3rY8WBDZUs++vWDLzj4NofWMcBdjO9 AvtkNAimcbZf3Eb8C4zLvBIa/q3pRNWwLzA9E3voudNumFzlUV/sNZ7M5u5CuqiYZmA+IHlhDMjC +H0ZC8TOSwFs3dw12/O0+duYVy16veEdDKZaKqjIMHv9PugsClmX13Dhh9Ugd62MupQOzdgcNP2/ 9OIfAAAA//8DAFBLAwQUAAYACAAAACEAZb4HjDwQAAAscgAAGgAAAHdvcmQvc3R5bGVzV2l0aEVm ZmVjdHMueG1s1F3rcts2Fv6/M/sOHP2OY1GSdfHU8dhK3HjGddzImf1NUbTFmiJVXqykb9Tn6Iv1 4OBC8AIREClvu51Z2ySADziX7xyAAPLT5fdNYL16ceJH4UXPft/vWV7oRis/fL7ofXu8OZn2rCR1 wpUTRKF30fvhJb3LD//9z0+78yT9EXiJBQ2Eyflu61701mm6PT89Tdy1t3GS9xvfjaMkekrfu9Hm NHp68l3vdBfFq9NB3+7jb9s4cr0kAbS5E746SY81t6m2Fm29ELCeonjjpMn7KH4+3TjxS7Y9gda3 Tuov/cBPf0Db/TFvJrroZXF4zjp0IjpEqpzTDrEfvEZcGUUNLq35MXKzjRemiHgaewH0IQqTtb/N h3FoazDENe/S675BvG4CXm63tUcVPDFkHR18jJ0dqCJvsNJcjTBWtNImoHIg+s21Wm7R7u8bDNMI aUL0QacLRUzek43jh6KZw0QjCxf8oY19/xxH2VZ0Z+u3a+02fBFtEbc06Fl/jJ4nDy0xaqDiuou1 s/V61sY9v30Oo9hZBtCjnT2yiEX2PgBVrCL3o/fkZEGakD/jh5j9yf7CHzdRmCbW7txJXB/E8+hv gF3uvZ31Ndo4oMndueck6VXiO7Uv11dhUl/NhfGVWzslkIETPkOzr05w0fPCk5+viyDi0dJfQctO fLK46kHFUxwB/ymNZCvGRUuVhg0EAXSxoLQJQvGe7iL3xVstUnhx0QPqxYffbh9iP4qByy56sxl7 uPA2/md/tfIIS/OC4dpfef9be+G3xFvlz3+9QY5kLbpRFqYXvcF4gqoIktWn7663JVwFeKGzAeh7 UgGIBEhdwsEOZX7eG/qghIoPf+eQNhEQSLYOZe05JK5Y2P+9QDjqrDXQoHFEHQEN3wpo9FZAZ28F BLG6weo60tHkrYAgY3qbEaFgjulHaeRSZ5VJYDjb4+KkBnqdUQ10H6Ma6AdGNdCgjWqgZRrVQBMz qoG2YlSDeoNEynv1QSjXi4lByiD9PRp0HQwN5SpDlJ8WzT/6aQDpQIMP2C2DCQu71oMTO8+xs11b JH8od3tfOFpky1SvqxiwDg9HizSOSFbdIJEBdZyDo96nzXbtJD5MPpqAWor+kWR41s+xD1l6A9SZ grzVScJD4LjeOgrAbK1H7zvVaEUm6vr3kbXYOi5OYxo611Ktd/7zOrUg+SVJTaMkxgqhq0dC27/z E5TBXp4fK4bS1LiWDscKu1Q3/ou38rMNF41GvjemEcBAzSUI7OJ+EY2IiqpO3DgKogCdIdAAYz4E bF+j/zQcmbdPdKzTfxq8Dmxfo/801B3YfnOCPTZmmo+wemRpudfE2HfnURDFT1nAfaCRHibGHiwg 9IZg7MSifS2SmBh7cIE+rSvXhbmxjp0a6yLnUQMUY3VQFHQ2/bEYK6VEe7bBiIwVVMIaGGC141oD IGPS/eq9+mSt2zQYIEuLXLPRnYcKCUAI0sqhf82itDmHHig4TxflNoQFqcSz9NCGCs/TRWP2ROOd gY7bBT4DoHYR0ACoXSg0AFLYhzrnETFRH6R9cDTAMqZlEcXQ7LSZeWLMzALILAR0FDc18i+F96pt oRo3NVCMFVSNmxooxtopxTIRNzWwOoubGliKqKHWkcypJoMyjpsykMgENEbUDXlrAHVD3hpA3ZC3 BlB78m4G6Y68NbCMuUFwqkzeGkBYxGSqL4Bk8tYAMuYGynZszYjHPWxl/+JFB+StgWKsoCp5a6AY a0dF3hpYWMTEEkpYguo0sLohbw2gbshbA6gb8tYA6oa8NYC6IW8NoPbk3QzSHXlrYBlzg+BUmbw1 gIzpQQDJ5K0BhEVMuKGWvNHrj07eGijGCqqStwaKsXZKhCqSVA0sYwWVsAR5a2BhERNjYFho3CaD 6oa8NUbUDXlrAHVD3hpA3ZC3BlB78m4G6Y68NbCMuUFwqkzeGkDG9CCAZPLWADLmhlryRmc8Onlr oBgrqEreGijG2ikRquA5DSxjBZWwBHlrYKG9tCZvDSAsciiQyYi6IW+NEXVD3hpA3ZC3BlB78m4G 6Y68NbCMuUFwqkzeGkDG9CCAZPLWADLmhlryRh85OnlroBgrqEreGijG2ikRqiBvDSxjBZWwBNVp YHVD3hpAaJityVsDCIscAIReZKKmbshbY0TdkLcGUHvybgbpjrw1sIy5QXCqTN4aQMb0IIBk8tYA MuYGss8W9otqb0+1FUagu8+A72rQBhwolKQLyAb41XvyYjg86TXvDmkJyEdogKgwD90hXkfRi6W3 sXuoMBBtKH8Z+BFu6f6Bu3Tkve6TPTvXH7/Mrc/0iFGlHppUcecNnOKSD2SRU0t4ohX6mf7YwqGo Ld9ZTlqDw1rk+Bo7ZIUFb+HIFTs4RSqTk1RQEA+Tscf43Zah4u9w8E06d5YfZ4OTZt8WZGjS0TLE aOiV6AeoJvZsPOAl9yM/cYXwTuA7CRyqY738bL9bsw3yS3i++kIOhFX6H8Im7Lrn8rjg4Bvp6Yvn be+hOIIldBc2VHWeUg/O1Q5G7NyBH67gaeA9EXHOphiXY7KZGspMMR1Yw8E82FTNXmNzUZYGfujd vQa8M9gaCIyBM9nGpWOEV7FPT7ax84H0b2xySfv5B29wMGqtgoFSBQNquWUVDN6t2ZsjqIAKWhKt QpJoBP8wSQ6VkhzWS3L4bs3eHEGSVetDrVVklnRpTPTsbJ0/o6GCYxX9ec0eH2H8qbPEk7vwk3sL 8V/CjNsIjtcOxjPuPLyo7OWT/pQqrSpH1FlFjoZeDPXR/eGnOW2eKS3trNbS1uzxEcT8m8ulS3ZD w8EthcNyWf+TqG+sFOO4Xozs8RHEWLUyVFlbK9udu2RbP1fRvE/+o2Pr1O/pQe06v2fpzxFExr22 ewdHNXcs+j787+aGiL6V50+VJsvo6giCrqRF9mBPWqSVCKFVtJewZMM8uB1OqjOlaNnx4X+HaNEO OhUtp+4G0bprmH24JAQA3SgmHw9RADfqwDRlBXOTtCJwxQlZDCn5aWDOZmwikK+n0nKF81rU3xQR FpiDHvtV9PaRvHeyvTMmCwtRSq12ES7DwE419REmcMuAzkjgl1ucbezYbRh0arf67tCm4P3cC4Jf nJjMX9JoC+JQFCX5Dn1rQzYDv5WaWkZpGm3U9TENVzcARiZ3hv5JBgG/KSQeZpulF7PDpwqpX2Vu FnoBnGH0KgYCR2XJIlNbcas7WJhBi7nqp/AkrekNO6qOGt5DDiXlswwIjK+cn7IMCiSOGerIPmPT AygLD3GeizohusQi0yHcHEVtnLYHI8P2TUf44HtwU8vWea7K/CmCgz0sr/uXj3Iebcj1V44fV4fp hGEEt9qQO2ZScoi7SaswtX/hSpHanTtMVNpaL8xK7JHNArmk80KJ0XjSUOJsdoaUDe6Z202hDZjc 8DBBzQYcVrn2kWf4wBdrZm0HpvFgliZRRDjgfbaJI4V9EqO1KLHUKq0Uc6p8rOkrbpYAWy7IXUjl NbXr6joWPDKxoGt7DuGTVqlZppJnpmdwLRIYnsizyN8I9baKKjDlHtn0+9fR6gfei0ACljxH6Pct 8a5JWMzgqmZKc1HOe8y+4If+olo5i6zcsnXQQucekTiVuHZ5SVXIRrnzV9FuDpeDxFHD2mHpPjDo KZhG+1XaPZ2vrhdeXl7CDTp1CmQpi7weyx6xgUrLr200uERwSY+HpKyCbCC1+j3zVh7cuKgTLWLx EYX2QlxHhn8i3QG9ilU2mwfsBiLU9a+Pn+a3i9sv9xWbEi/qNCMv9zcZHThttqHJKfxyS1bCMRVB hgO1ibe5cy49uPSS0CR4JxRny+li3tglU+3OqfYLCx35bBsu0OD9JXd2Qr4P4oBOdyT9q/ljnezZ Y03JS15Av0jcwWeDBCsrmUASe0EpfHFSKGV7vYKUnM8UUHFMECCX5I+LHv2ACuGfhzWU5EXv5oZI kfo1m0k01MYPITW1xTyjoT5+Y6ypz+chDdXr4QmvcBHUpNwwwcMJK6bTQ7jyBsWuSpzs6YgLuJo4 caOn9+Ywm+ctyhEcWwHpixA+mzH+PLpj5ErtzgdWcM1uhX3wYZ39y67BmEfYasGSUSQyvQg14py3 wRhkW+r3py0sWa59iCXL9Q+w5Lz6fksG2YlpIbNjqMCtVDa/IXzVlK2P/A2aIs1Tlmcxq8SoXIZQ riPyvI/Sj3W2A88tfFFnP7lh7bUengEI2+KSkFxbFpltD/iKOy25XxwH+5HIMuZRvE1WHplrVr2H pMX0LrE6EcjBuzgNzZtUzUOZbvXSY7ASchOt9AG6YBPthUCmBZBpLbMA7uWucMi1EwQRzMdx8mAi iEKzQhJtlufgtnGR9/T7s8Hw02ROQ4VCoI/OGu4ARj9jt/yKB3i5L/0LB1XODUlYnostD7r5YmH5 dU/+XpFNeVaGBayVZ1GtWEJ+sqkVWqGC0Bbv/1uWlfkd3KIMimjmtYKIhSPf+V64hu03cVrryp/J KyK6JikVt1+iZTRKquCO3Sa9Yny4Uafim3RnVZNTyjM/FWth+8LIqlYE124ijLwsUhRM/2b0ieZl IoRVpyJkLw/w2b60bNLHrEGkZTZ5gNjVz7P1IfNQWl1SQc5p0v/ixWJf04Av1DXE3IJt7nF/OewQ oZe9H98T70drrnd+uQ0qn9Jip1o9Cras3/KkHX6ERx+08qEvOrEeUC858VolNlHgmFJDU2LrQkeV h3Dcsg3hi3oZ4Cs6erWnH24++XjLt+eThJcGYmFrpdSmyQfbGZnucs4iymLYj1sWKXtMaUK981Et OZYs57y4jwjZDsecCMkDwK7kxG34rjne6sqMrJTCl+eK0PjzOqmhIbLPJI1Sq5k7FL6nDAZjTtO8 qDzhYiv0aukVLLFDuXydR/AP5TzUfdWbf7XwJdxGDd/8UEJFMdz0x6MZJkY1QbW4oKceGPuHMYTL FVwQQdsQVcE+RL7yENN/cOfz4y93FZMgD60HWLLFf28C5h506Hu+a8pZr9z0noyFf/VvzOgmk7Pr aVHG3H7gJ1AWLnIUTG1G5wPqb3v2dIgrJ+oSg8kIrVVdYjgeM9dQdWN0Nm1YKjsbzXClW40yHtkN PZ0MafqjbmM6GDX0FATW0FO73580dNXuiyU6lURse8a3jCqLDKC71OCURYYTvudcWWQ0PuPfEKAM bCJo9L+Fv1lkpX+PJn/GnDJ/QOiI/YU+mk9QefflCSp/1vAp6o/1yfyeBZGOctmyO5aD5kP815/U 0f/600LPF05bcvi6b8Qqx6cKrGYv3OuLNCq7uCL5zQWfpy/5s3+tdtgn7bJSrm1rLj51yzLmX8yL 8rOH4+mU0YRCfm8aXb4sf/PSVab5bTDJoDhkJnUZiLRphL6XJ8uVl7Kkqn0Qdq02y9IUrTk2nY3m /PMPSx4p2xTI2C18P6ndvVIsUrt9pVikdv9KsYjOBhbG+vknFYyjoIlGulTPHcpvqF7p/+PkvTl5 051t1iu57E1YylpllmSQ+cyrxHKSUQmD2W9XTVxXMqqi604kCzJ33aUkVbOpF+gAk8Hkw98CAAAA //8DAFBLAwQUAAYACAAAACEARJBc0rQPAAA7bwAADwAAAHdvcmQvc3R5bGVzLnhtbNRd63LbNhb+ vzP7Dhz9bmpRknXx1PXESrzxjOu4kTP7m6Jgiw1FqiQVJ32jPkdfbA8OLgIvEACR8rbbmbVNAviA c/nOAQggP11928TeV5LlUZpc9vwf+z2PJGG6ipLny97nx5s3056XF0GyCuI0IZe97yTvXf3873/9 9HKRF99jknvQQJJfbMLL3roothdnZ3m4Jpsg/zHdkgRePqXZJijgz+z5bBNkX3bbN2G62QZFtIzi qPh+Nuj3xz3eTGbTSvr0FIXkXRruNiQpsP5ZRmJoMU3ydbTNRWsvNq29pNlqm6UhyXMY9CZm7W2C KJHN+KNaQ5sozNI8fSp+hMGcsR6d0aagut/H3zZxz9uEF7fPSZoFyxiE9+KPej+D5FZp+I48Bbu4 yOmf2UPG/+R/4Y+bNCly7+UiyMMouuw9RhsQ9j158T6lmwD69nJBgrx4m0dB48v12yRvrhbm9Qpn FDIOkmdo9msQX/ZI8uY/12UQ+WgZraDlIHuzeNuDimc4AvFTGclWjouVqgwbFAbqWzArAqGQp7s0 /EJWiwJeXPbAEvHh59uHLEozsJTL3mzGHy7IJvoQrVaEGq0omKyjFfnvmiSfc7LaP//1Bi2Qtxim u6S47A3GE1RFnK/efwvJltoO4CXBBqDvaQXQHti4goMd2kX73rAHFVR8+LuA9KmAQLJNKGsSUDfz sP8HgXDUu9ZAA+OIOgIavhbQ6LWAzl8LCJjQYHUd6WjyWkAQQF5nRCiYU/pRkYbMWVUSGM4OuDit gV7nVAPdx6kG+oFTDTRopxpomU410MScaqCtONVg3qCQ8kF9UMolGTVIFaR/QINhgKGhWmWI8rOi +ceoiInRB/yWwYSHXe8hyILnLNiuPZo/VLt9KBwtdsvCrqsYsI4PR4siS5Nno0QGzHGOjnrvN9t1 kEeQDBroZ9BS9I80ufP+k0UrI9S5hrz1ScJDHIRkncZgtt4j+cY0WpOJvv596i22QQh5hrFzLdV6 Fz2vC2+xxqTGCDbWCF0/Etb+XZSjDA7y/FgzFFPjVjoca+xS3/gvZBXtNkI0FvnemEUABzVXILCL h0U0oiqqO7FxFFQBNkNgAcZ9CNi+Rf9ZOHJvn+rYpv8seB3ZvkX/Wag7sn1zgj12Zpp3MDf3rNxr 4uy78zROs6ddLHzASA8TZw+WEHZDcHZi2b4VSUycPbhEn97bMIS5sY2dOutiz6MOKM7qYCjobPZj cVZKhfZ8hxE5K6iCNXDAase1DkDOpPuJfI3o0p9rMECWlrmm0Z2HGglACLLKoX/dpYU5hx5oOM8W 5TaBBamceHZoQ43n2aJxe2LxzkHH7QKfA1C7COgA1C4UOgBp7EOf88iYaA/SPjg6YDnTsoxiaHbW zDxxZmYJ5BYCOoqbFvmXxnv1tlCPmxYozgqqx00LFGftVGKZjJsWWJ3FTQssTdTQ60jlVJdBOcdN FUhmAhYj6oa8LYC6IW8LoG7I2wKoPXmbQbojbwssZ26QnKqStwUQFnGZ6ksglbwtgJy5gbEdXzMS cQ9bObx40QF5W6A4K6hO3hYoztrRkbcFFhZxsYQKlqQ6C6xuyNsCqBvytgDqhrwtgLohbwugbsjb Aqg9eZtBuiNvCyxnbpCcqpK3BZAzPUgglbwtgLCICzc0kjd6/cnJ2wLFWUF18rZAcdZOhVBlkmqB 5aygCpYkbwssLOJiDBwLjdtlUN2Qt8WIuiFvC6BuyNsCqBvytgBqT95mkO7I2wLLmRskp6rkbQHk TA8SSCVvCyBnbmgkb3TGk5O3BYqzgurkbYHirJ0KoUqes8ByVlAFS5K3BRbaS2vytgDCIscCuYyo G/K2GFE35G0B1A15WwC1J28zSHfkbYHlzA2SU1XytgBypgcJpJK3BZAzNzSSN/rIycnbAsVZQXXy tkBx1k6FUCV5W2A5K6iCJanOAqsb8rYAQsNsTd4WQFjkCCD0Ihc1dUPeFiPqhrwtgNqTtxmkO/K2 wHLmBsmpKnlbADnTgwRSydsCyJkb6D5b2C9qvT3V1xiB7T4DsavBGnCgUZItIB/gJ/JEMjhLRsy7 Q1oCihE6IGrMw3aI12n6xbPb2D3UGIg1VLSMoxS3dH/HXTrqXvfJgZ3rjx/n3gd2xKhWD02qvPMG TnGpB7LoqSU84Af9LL5v4VDUVuwsp63BYS16fI0fssKCt3Dkih+copXpSSooiIfJ+GP8bstR8Xc4 +KacO9sfZ4OTZp8XdGjK0TLEMPRK9gNUkxEfD3ip/difuEL4II6CHA7V8V5+8H9Y8w3yS3i++kgP hNX6n8Am7Kbn6rjg4Bvt6RdCtvdQHMFytgsbqgZPBYFzjoMRP3cQJSt4GpMnKs7ZFONyRjdTQ5kp pgNrOJiHBzLxNTaX7oo4Ssjd11h0BlsDgXFwLtuscozwbRaxk238fCD7G5tcsn7+IRocjFqrYKBV wYBZblUFgx/W/M0JVMAErYhWI0k0gr+ZJIdaSQ6bJTn8Yc3fnECSdetDrdVklndpTOzsbJM/o6GC Y5X9ec0fn2D8RbDEk7vwU3gL9V/KjNsUjtcOxjPhPKKo6uWT/pQprS5H1FlNjo5eDPXR/eGnO22e ay3tvNHS1vzxCcT8WyikS3dDw8EtjcMKWf+dqG+sFeO4WYz88QnEWLcyVFlbK3u5COm2fqGieZ/+ x8bWqd+zg9pNfs/TnxOITHht9w6Oau5Y9H34380NFX0rz59qTZbT1QkEXUuLfDiOh26uEqZIi6wS IbSK9hJWbFgEt+NJdaYVLT8+/M8QLdpBp6IV1G0QbbiG2UdIQwDQjWby8ZDGcC0ITFNWMDcpagLX nJBFW9ufBhZsxicC+/VUVq50Xov5mybCAnOwY7+a3j7S98Hu4IzJw0LMHepdhMswsFOmPsIEbhmz GQn8couzDbgZBffQsand6lvAmoL3cxLHvwQZnb8U6RbEoSlK8x321odsBn6rNLVMiyLd6OtjGq5v AIxM7Qz7kw4CftNIPNltliTjJ101Un+7C3cJieEMI6kZCByVpYtMbcWt72BpBi3nqu+TN0VDb/hR ddTwAXKoKJ9nQGB81fyUZ1AgccxQR/45nx5AWXiI81zUCdUlFpkO4V4eZuOsPRgZtu86woeIwE0t 2+C5LvOnFA728LzuHz7Kebqh1xEFUVYfZpAkKdxqQ++YKeghbpNWYWr/RShFaXcecFFZa700K/FH Pg/kis5LJUbjiaHE+ewcKRvcc283pTZgciPCBDMbcFjt2sc+wwe+WHNrOzKNB7N0iSLSAe93myzV 2Cc1Wo8RS6PSKjGnzseWvhLucmDLBb0Lqbqmdl1fx4JHLhZ07c8hfLIqDctUaqJ1DtcigeHJPIv+ jVCvq6gSUx6QTb9/na6+470INGCpc4R+35PvTMLiBlc3U5aLCt7j9gU/7BfVqllk7ZatoxY6D4gk qMW1qyumQj7Kl2iVvszhcpAsNawdVu4Dg56CabRfpT3Q+fp64dXVFdyg06RAnrKo67H8ER+osvza RoNLBFf0eEzKKskGUqvfd2RF4NY4m2iRyY8orBfyOjL8E+kO6FWusvkiYBuI0Na/3r2f3y5uP97X bEq+aNKMutxvMjpw2t2GJafwyy1dCcdUBBkO1Cbf7p1zSeBKQUqT7OIWvpwu541dMtXLBdN+aaFj P9uGCzREf+ndgZDvgzig0x1J/+38sUn2/LGl5BUvYF8k7uCzQY6VtUygiL2kFLE4KZWyvV5BSi5m Cqg4LgiQS/7HZY99QIXwL8IaSvKyd3NDpcj8ms8kDLXxQ0hDbTnPMNTHb4wN9cU8xFC9GZ7yihBB Q8oNEzycsGI6PYQrb1DsusTJn46EgOuJkzB6dm8Ot3nRohrBsRWQvgzhsxnnz5M7xl6p3fnACm4d rbEPPmyyf9U1OPNIWy1ZMopEpRepRpzzGoxBtaV+f9rCktXax1iyWv8IS95XP2zJIDs5LeR2DBWE larmN4Svmqr10b9BU7R5xvI8ZlUYVcgQynVEnvdp8a7JduC5hy+a7GdvWAetR2QA0raEJBTXVkXm +wOx4s5KHhbH0X4ks4x5mm3zFaFzzbr30LSY3SXWJAI1eJenofsmdfNQrlu79BishN5Eq3yALtlE eyHQaQFkWstdDNcU1zjkOojjFObjOHlwEUSpWSmJNstzcPmyzHv6/dlg+H4yZ6FCI9DHYA13AKOf 8Vt+5QO83Jf9hYOq5oY0LM/llgfbfLG0/Hogf6/JpjorwwLeinhMK56Un2pqpVaYIKzF+/+WZW1+ B7cogyLMvFYSsXTku4gka9h+kxWNrvyBvqKiM0mpvP0SLcMoqZI7dpv0yvHhRp2ab7KdVSanVGd+ OtbC9qWR1a0Irt1EGHVZpCyY/s3oPcvLZAirT0XoXh7gs0Np2aSPWYNMy3z6ALHrn2ebQ+axtLpk gpyzpP8LyeS+poFYqDPE3JJtHnB/NexQoVe9H99T70drbnZ+tQ0mn8pip149GrZs3vJkHX6kRx+1 8mEvOrke0Cw5+VonNlnglFJDU+LrQieVh3Tcqg3hi2YZ4Cs2er2nH28++/E23MVf2k5Xty2TD7Yz MtvlnEW6y2A/blWk/DGjCf3OR73keLK858VDRMh3OO6JkD4A7FpO3IbvzPHWVmZ0pRS+PNeEJp43 SQ0NkX8mMUqtYe5Q+p4yGIwFTYui6oSLr9DrpVdKsjuUy6d5Cv9uyEPTV735Jw9fwm3U8M0PJVQW w01/PJphYtQQVMsLevqB8X8Yo5neEbQNUZXsQ+YrDxn750w+PP5yVzMJ+tB7gCVb/PcmYO7Bhn7g u6aa9apNH8hYxFd/Y0Y3mZxfT8syFvYDP4GicJGjZGozNh/Qf9vzp0NcOdGXGExGaK36EsPxmLuG rhuj86lhqex8NMOVbj3KeOQbejoZsvRH38Z0MDL0FARm6Knf708MXfX7colOJxHfn4kto9oiA+gu MzhtkeFE7DnXFhmNz8U3BCgDmwiM/reINotd5d+j2T/jcXH/gNIR/wt9dD9BFd1XJ6jimeFT1B/r N/N7HkQ6ymWr7lgNmg/ZX38yR//rTw89XzptxeGbvhHrHJ8psJ69CK8v06jq4prkdy/4ffqyf/aP 1Q7/pF1VyrXvzeWnblXG4ot5WX7+cDydcprQyO9Vo8vH5W+kWO0svw3mOygOmUlTBqJsGmHv1cly 7aUqqXofpF3rzbIyRTPHpvPRXHz+4ckjY5sSGYel7yeNu1fKRRq3r5SLNO5fKRex2cDCWX//SQXj KGjCSJf6uUP1DdMr+3+cvJuTN9vZZrOSq96EpbzVzlMMcj/zqrCcYlTSYA7blYnrKkZVdt2JYkHu rrtUpOo29QIdYDKY//w/AAAA//8DAFBLAwQUAAYACAAAACEAWEFW1lsCAADtBQAAEAAIAWRvY1By b3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsVFFP2zAQfp+0 /2DlHZyGrmor1wzBNiYxqJQAz15yba05tmWbjvLrd07aNB0DsWl5Ot+dvnz+7vOx08dakTU4L42e JYPjNCGgS1NJvZwlt8Xno3FCfBC6EspomCUb8Mkpf/+OzZ2x4IIETxBC+1myCsFOKfXlCmrhj7Gs sbIwrhYBj25JzWIhS7gw5UMNOtAsTUcUHgPoCqoj2wEmLeJ0Hf4VtDJl5Ofvio1FwpwVUFslAvDr SEcx2iVYYYJQhayBZ5juDmwuluD5gNE2YPfGVZ4PBx8YbUN2vhJOlAHF41k2PmG0l2Bn1ipZioC6 8m+ydMabRSA3jQIkAjDab2GoSg7lg5Nhw1NG+0d2JXWkMmG0jZCbE0sn7MpzpNM7sbwUCs7x7nwh lAdG9wl2CSLOdS4kMmbrMF1DGYwjXj7hZIcJ+S48RMVmyVo4KXRA5WJbe2hiZX1wvJDBITbW2nMT 9tv6sRxGFbEXg1cbO2z1H7DjD9v74U8Pb47sFfibBeoW/iBE1hei4dTK0NK7yknYmomgt8k1zn2v Qxe93nZA7jc656a2Qm/4pyL/SnJjV1KQMx2kNUp69Ni2HE3xw9/awlxEX2+nfZjsOfRehlVuRYk+ ykaTA6/2SixHS0OF5tsB7hPssgF/bpxRX68XjYPDH6ejdJKN3+QFbMdX8AbT/E0jvpU3ICr7M3q8 FlIFMz35Mp9fSSG90R8heBkX2XbiTVsT9+3ej7dQL/cfGGEn8CU+QafieHGh6CVUu2E8L8Q1c9du bz4YHqf4NXtll8Pl0K1V/gsAAP//AwBQSwMEFAAGAAgAAAAhAEx39wSQAQAA7wIAABEACAFkb2NQ cm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJySUW/TMBSF 35H4D5bfU9spghGlnhjVEFLbTSwIxJtl37XWYieyL83673HcJgzBE4/WOf587rmur59dS44Qou38 iooFpwS87oz1+xX92twWV5REVN6otvOwoieI9Fq+flXrvtJdgPvQ9RDQQiSJ5GOl+xU9IPYVY1Ef wKm4SA6fxMcuOIXpGPasV/pJ7YGVnL9lDlAZhYqNwKKfifSCNHpG9j9DmwFGM2jBgcfIxEKw316E 4OI/L2TlhdNZPPVppkvcl2yjz+Lsfo52Ng7DsBiWOUbKL9j37eYhj1pYP3algcra6AottiA3DwTB 9a1CIKkCslvWbBZHmw6gsAtyrY7WkJsuDirgweqn7JvUsfBWRdym3TxaMDcnub378mG3Jpu0OmhJ 8+kzu9vsava3cbwb4GjHJcsyO+bjxL0P1iMYmSYqC/6mKJcNf1cJXnH+Y2ZOphQ7l3nODoakeqpz mZPybflx3dzSxBPvC8ELUTb8qirFmTe58nTp1RnoLuP9N3ECyBz6zy8qfwEAAP//AwBQSwMEFAAG AAgAAAAhAAiHxUb5AgAALw0AABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzclt1u0zAUx++ReIco91uc NP1YtW7aVyUk2AUtmsSdkzqtRWxHtrPQZ+CS9+ANeBt4D47tpN26FGUDDY1VU9Nj+9T+9f8/x8en n1nu3RKpqOATPzxEvkd4KhaULyf+h/n0YOR7SmO+wLngZOKvifJPT16/Oq7GmeBaebCeqzFLJ/5K 62IcBCpdEYbVoSgIh8FMSIY1fJTLgGH5qSwOUsEKrGlCc6rXQYTQwK/TyC5ZRJbRlFyKtGSEa7s+ kCSHjIKrFS1Uk63qkq0SclFIkRKl4Mwsd/kYpnyTJowfJGI0lUKJTB/CYQK3o8CkguUhsk8s9z2W jt8suZA4yYFdFcb+SQ3Oq8YcMwjO1iwRuY0XmAtFQhi6xfnER314hcgkHKIBvPfR0A9MgnSFpSJ6 MzFy4Qwzmq+bqBQMczdQUJ2umvgtltTsxw0puoSBUiUIvrD+810kBD3cj0QP5vTuR1KbZ3RnFUQg zyYzbD9wynkAYk4ZUd41qbz3dudmwi6RCCgMUA9IxPAfwVPcTgT9HSJXsPHoajrdErmAyHDUP68j WyJHdaSViD1/6PJ0J/JOcKHXBfFmQmplJYJzfQ2yaX7Lj7jILkG2CTisHUSrNHCphZv+IpRxQxJT jxyBXUn0QQTOJH10BOIYot4jSLw0k1yIUlIijU1aS0Zkzg8cjFGMQeJHGYSJBZFtNSOjn8nCYb1b MPbZI+49hz1uQBO/00VTdDbvj9DFC3PIGZT09h4SoXMwRWwFYUQBkmjH0FoxVUVVXVg6Vop/K4k5 XkHv2OMMB8I1DwPkiSCgJs9lSeZQmG0z7gimVmHjjLtN0bXbbSuBO5htyftbCUKhmdO9lcwom5W8 rYX8/Pblx/evThO7tdVcPQawcVNh61ereEYDF75/Adl66M+Q2aPCDcUgGyEjsAbQBlnYRPYhi5tV 3ZFd4Jwmknpv6XKl90hqCmhqV9mnJ0qqo4Sst852byNRPHyW20jNYy8J025sffn/SNRXVnXyCwAA //8DAFBLAwQUAAYACAAAACEArnTR7O0BAAC1DAAAFAAAAHdvcmQvd2ViU2V0dGluZ3MueG1s7FdL b9swDL4P2H8wdG8sJ36jSYGg6DCge2Brd5dlJREmiYakxEt//Ri77dJ2h/gQbAefTJHiZ1KfTNKX V7+0CnbCOglmTqIJJYEwHGpp1nNyf3dzkZPAeWZqpsCIOdkLR64W799dtmUrqu/Ce9zpAkQxrtR8 TjbeN2UYOr4RmrkJNMKgcQVWM49Luw41sz+3zQUH3TAvK6mk34dTSlPyCGNPQYHVSnJxDXyrhfGd f2iFQkQwbiMb94TWnoLWgq0bC1w4h/lo1eNpJs0zTBS/AdKSW3Cw8hNMJuwjCg9Q6B7RTtKKBJqX H9cGLKsUnmAbxWSBx1fLnXt8Bm0pazz9LKFpkaeduYJ6fy13aNoxhTYSHjbj2d2KlX/S0mftN7ne /EV9B83bvUvwHvQrPYazrO3hHf6Pj0HOCW50D3OCNwOFhnHMoZM5KECq2NZDH4Y6imyYZ/UiomG+ 9jjzIa5hx0GXdC++ZCOe5WmcpclIx6BLcC468igtojwev44hV7wtz0ZHnGZJRBM6FqshJfJcdBRF UiQpTfvWMvaOEzvWueiI4lkxTWhBx8/jv2geUTZLplmE49VYrv5VuepnrG7khcZLLR/EDdilhdYJ 2w23OL7vv5gfn267FVMK2q+fP+ACXY9+Nha/AQAA//8DAFBLAwQUAAYACAAAACEAgr8XO0EHAACo MgAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbMxbXW7jNhB+L9A7GAL8GFvUv4z1LmTZLlJ006JJsc+y rMTC6g+SbG/eiu0leoMCvUB7q71Ch6QkS9aPY0lGlYfYITlD8psfDmeYdx++uM7oYIWR7XtzBk1Y ZmR5pr+1vZc589vT+k5hRlFseFvD8T1rzrxaEfPh/fffvTvOvL27sUIYOAIeXjQ7Buac2cVxMJtO I3NnuUY0cW0z9CP/OZ6Yvjv1n59t05oe/XA75VjEkm9B6JtWFAEf3fAORsQk7NwyNz+wPJjr2Q9d I44mfvgydY3w8z64A+6BEdsb27HjV+DNSikbf87sQ2+WLOguWxAmmdEFJR8pRVjaRcW8lHLpm3vX 8mIy4zS0HFiD70U7Ozhtoy032OIuXdKhaRMH10nHHQMklObLtvwWGSxD4wiiODEssasAY0uJXIfi gOV7kuo5R8Q2bSaRCGaRreEtSyjOma7ENWwvY9MOmjy4YBJd9PuH0N8H2XICuxu3e+9zxgtb5hUr YyViefmtRVcxKJnu484ILGbkmrP7F88PjY0DKzoiYYQ1knkP3sLYRHFomPHD3h0V/rrfzhmWDPEi ewt9B8OZM2vyI+vMFBO7eye2f7IOlvP0GljpGOwzHIs002GxGzhppygJK4mXEgbOAXfY8JFOBk4t jNPBiNKDR1u7WePWMm3XcGgXUD5ZX7K+MZpk7T+aKRvHeo5pc/BLiNcdw66Tz3QMzMHA98AHxJGg cnj89DTS9jAEmFHSDX/tDO8FtjpneIlNhhP+QAbLIuQ5dC+CjerAXtK1twCbX8jKihcEymCgYHOs 2gQ27u4fbK4O7FVrsJeaoomaRlSBaACsemiarXJSA9a4t3+o+Tqo162hXsuCIOuKQhkMU68lgW+A Gvf2DzV16WV/rSRK2cKFcKDSMqsStWmn1Zu941iJ/z1z19++/pOJ8H9z18dZSE+FcO17cQRSMSLT hijg8dXd+BDDgafXANNCg+3BQbC1ng04ARMxEy4tfb9YYyNKcgK2EJyk86vVktUygGEf17mj2wuu m+sfguCkOsGRAKJVhCQvFE6Vlx0ipJsLrtMxMgSxyXViIz67ldiWMuIURRuyvXU6koYgNqVObEkk 0MJNLjRRUPXVoEOJ0/0ivbjkryO4t/9QQq2DmgTrrSxE45HCr/QOUN/csXVCeggWgspXdrRgNZRd AluYiM4K0lpEPR1IwWP86mS5ggc/XkICMwtS8pf5b7//m7W3jw7Tq3mV6SCZgzxq7iYPHjyJ5pJM QU1o+NH3/BinPB79MIacYhYiVnT0HCqicp5AQLrG6fRq18oykaKvltL6JhLW9Kf7nx8yQRYE/Mff WXt7Ad/GZj9ZG5xsz8u20NS3VMsJCUFdLLnlIrl5Vdvt7nUT2tuPOA3n4DQchTOfb0MLntMgDZQB nbsGwNc4cCCfjwR5pSxljfj8yxm4Bjd8l83TIND86SVzjadXrU99sl0rGj1Yx9GvvmtANvk4s4wo 1iLbmDMVnckVrqLHhIxfRfPukoSLt2GEV0DRZAVWZVmWXPBjqEJA8eEAaVdqt53Q9a9FFwlCO3h1 fx/aVogBznm3s1aM3FnTlahxJdRE0tIrat++/nUtbhxqDqpq1fIT+IyS3yi0XadWVImIkSZqRRWt Z4DelIbJmy0clO0Uq0tSpWhxQkl3hmBxcBq1A+bckGjK6ay1u8VR+8or1DAsTuBbHgR9WxxJgRcc +TAsTgT7J664pupU65L6szh5kBYnyi199ZltJRHCWWt3iyM3jIJCDcPiJKGlC+9ucZAlv6oyWi4h QdJGk9R1Y2mUhMw1YbGqabq4Ut5W1hBp+NBQhi5eard1N9pxks6HMkhDeJzeVOETYkpSdi9UpxFH FlRXncbdQJdVp9FpfM2l9sqg7a2B7IVC/ThJkXcCg+PEpuox6b4pGPTedjmqvwjGZJzknjvhwfMq YVOjHKT7pnhQU+0Hj8n49HKhvb0IIidjA66BhHTfFBJale0Nksk48UedFEWUJOKMalAh3TdFhZY8 +0RlMj658/bqIslqk3sl3TcFhpYUewZmMiY2QG5Q7bFROPqWqEZpSHcBG5x+oKbXz9FD63b9YzMZ nxJk7eFReZpnq4GHdN8UHlofuwk8k3FS+OnkdRArosandaS/Z4xAHFdFm+VXNPBgUWV1dUXjwOpU bOOrxwWEm2t1kTAACGGL7R9jFKPN5Uq/f6xPsf9JF91JbDdKsRfyYjTfUbxbXMqVlSULgTJAC7/x 81UaqOZkf48fcZKAGl6/Ur8EQ/HLzAIdjemq6dLoqoqOxj7VdOlhW0VXeombW2fqP6vo6BFaOV8a FFeR0QOmkiwNlKrIqO+tJCPnLgijioz6pEqy9JytIqP150qyJtEl9c9KurS0VzVdUlWrpGsSOXiz s4e9J9mljq5yviZdaVDN8qvt03xNqoIadCXzyKeF3m8/GqYW645lePsgNZoc8PQ/TN7/BwAA//8D AFBLAwQUAAYACAAAACEAfGyAIQ0CAADJCAAAFAAAAHdvcmQvY29tbWVudHNJZHMueG1spJbbctow EIbvO9N38OgeZJsAjgfIpKHtcN30ARRJYE2sw0gGw9t3BTamdZOxzQ2HWf+f/l3tylo8HWUeHLh1 QqslisYhCriimgm1W6Lfrz9GCQpcQRQjuVZ8iU7coafV1y+LMppRwVKqpeSqcBvmAkApl5aGLlFW FCbF2NGMS+LGUlCrnd4WY3ge6+1WUI5LbRmOwyg8/zJWU+4crPtC1IE4VOHosRuNWVKC2AMfMM2I LfixYUS9IVP8iJM2KB4AggzjqI2a9EbNsHfVAj0MAoGrFmk6jPSf5GbDSHGbNB9GmrRJyTBSq51k u8G14QqCW20lKeCv3WFJ7PvejABsSCHeRC6KEzDDWY0hQr0PcASqK0FOWG/CHEvNeD5hNUUv0d6q tNKPrnpvPb3oq69aYbvkf5GsNd37A+KcObY8h1po5TJhrhMuh9IgmNWQw2dJHGReP1eaqOO4fHQ8 rS+lbIBd7Ff1l/nF+efEKOywIx5xVXSx8PeatRMJXdgsPKg0N8WNOh4gNSBuAfxLpR/jUk3IB5Q3 HMf7YaY1xp1kM+ql2d3XLT+t3puGJu6jbZrZL/3buAer6rrbSXD3mfmVEQNHgqTpZqe0JW85OIIe CqANgvMO+E/YlcAPHVr9c2XYsCqcGmLJBnZ9nnxL1vEariBVgO3PVB8D/99f1s+PCK8WuH33WP0B AAD//wMAUEsDBBQABgAIAAAAIQDG4RhUBQIAAKwIAAAZAAAAd29yZC9jb21tZW50c0V4dGVuZGVk LnhtbKSW33KiMBTG73em78DkXgNYlWXEznTddrzu7gOkIUqm5M8kKPr2PREQO+x2AG9UhO+X75yc E87q6SRy78iM5UomKJj6yGOSqpTLfYL+/nmZRMizBZEpyZVkCTozi57WDz9WZTCPqRKCycL+PnmA kTYuNU1QVhQ6xtjSjAlip4JTo6zaFVN4HKvdjlOGS2VSHPqBf/mljaLMWljzF5FHYlGNo6d+tNSQ EsQO+IhpRkzBTi0jGAyZ45846oLCESCIMAy6qNlg1AI7Vx3Q4ygQuOqQ5uNI/whuMY4UdknLcaRZ lxSNI3XKSXQLXGkm4eZOGUEKuDR7LIj5OOgJgDUp+DvPeXEGpr9oMITLjxGOQHUliFk6mLDEQqUs n6UNRSXoYGRc6ydXvbMeV/r6q1GYPvFXko2iB3c+XCLHhuWQCyVtxvW1w8VYGtzMGsjxuyCOIm+e K3XQs13+dzxtqlS2wD726/yLvHL+PTHwe+yIQ1wVfSx8XbNxIqAK24VHpeYmuUHPA6QBhB3AgvKe Jd0wqmxCPKC84Vg2DDNvMPYs2lYv9f6+ank16qBbGr+Ptm17v3Rv4gGsuupuO8HeZ+YtIxqOBEHj 7V4qQ95zcAQ15EEZeJcdcJ+wK55rOrS+HRdgWnBXmhiyhf1eRs/RJtzA4OH+TS9Tho/weoW/jhjr TwAAAP//AwBQSwECLQAUAAYACAAAACEA7iLpPskBAAA3CAAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAekRq38wAAAE4CAAALAAAAAAAAAAAAAAAA AAIEAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDsxNKv9QEAAMsHAAAcAAAAAAAAAAAAAAAA ACYHAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAD4VBxiSFAAA 13oAABEAAAAAAAAAAAAAAAAAXQoAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhALsa uc7mAQAA7AUAABEAAAAAAAAAAAAAAAAAHh8AAHdvcmQvZW5kbm90ZXMueG1sUEsBAi0AFAAGAAgA AAAhACydjIPpAQAA8gUAABIAAAAAAAAAAAAAAAAAMyEAAHdvcmQvZm9vdG5vdGVzLnhtbFBLAQIt ABQABgAIAAAAIQBCL5damAcAANIgAAAVAAAAAAAAAAAAAAAAAEwjAAB3b3JkL3RoZW1lL3RoZW1l MS54bWxQSwECLQAUAAYACAAAACEAWWCJgjIGAAClEgAAEQAAAAAAAAAAAAAAAAAXKwAAd29yZC9z ZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAZb4HjDwQAAAscgAAGgAAAAAAAAAAAAAAAAB4MQAA d29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWxQSwECLQAUAAYACAAAACEARJBc0rQPAAA7bwAADwAA AAAAAAAAAAAAAADsQQAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAFhBVtZbAgAA7QUA ABAAAAAAAAAAAAAAAAAAzVEAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEATHf3BJAB AADvAgAAEQAAAAAAAAAAAAAAAABeVQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEA CIfFRvkCAAAvDQAAEgAAAAAAAAAAAAAAAAAlWAAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAG AAgAAAAhAK500eztAQAAtQwAABQAAAAAAAAAAAAAAAAATlsAAHdvcmQvd2ViU2V0dGluZ3MueG1s UEsBAi0AFAAGAAgAAAAhAIK/FztBBwAAqDIAABIAAAAAAAAAAAAAAAAAbV0AAHdvcmQvbnVtYmVy aW5nLnhtbFBLAQItABQABgAIAAAAIQB8bIAhDQIAAMkIAAAUAAAAAAAAAAAAAAAAAN5kAAB3b3Jk L2NvbW1lbnRzSWRzLnhtbFBLAQItABQABgAIAAAAIQDG4RhUBQIAAKwIAAAZAAAAAAAAAAAAAAAA AB1nAAB3b3JkL2NvbW1lbnRzRXh0ZW5kZWQueG1sUEsFBgAAAAARABEAUQQAAFlpAAAAAA== --_006_6B7134B31289DC4FAF731D844122B36E3A240FE0OPEXCAUBM41corp_-- From nobody Sat Oct 12 17:45:46 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2341200F1 for ; Sat, 12 Oct 2019 17:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=JJ4dtsiS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mmmCieq6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB5LnOSeiBGe for ; Sat, 12 Oct 2019 17:45:40 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C00C1200EF for ; Sat, 12 Oct 2019 17:45:40 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8B449223BE for ; Sat, 12 Oct 2019 20:45:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 12 Oct 2019 20:45:39 -0400 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= fm3; bh=SxrhJaMcj1HzojHw3OgQ9ZImCrH4+X3cH0255hBdMq8=; b=JJ4dtsiS RYeHChEJ4vP6Bw6WccwRjN5FdMI8jzhGIDFeGa+XjyWg8kJJF3TieaB0Wn2fa3Qw GI2U1UnWbDlDZ7FmDxRjSo6HEyqWvZaCwBpqI/IxitULds+tqu2cYuMl+Aow5kdr tHhm6cylzOW5SNWLAPTMk5SHegy1d/aaskcxCNppsLyR8d/3lq4DdDE0xGMP1E5V PT8CJ2aFyCSaVYDYibJQKklQe8CZ5gRZ1NHZXybPBE0q019jqi3vR95pp2pIz2CG UB2fsTUF18MhIjzm8R1qzToZliDMBj/mgoq+NsxZFcXi9EM4YMAsXLZmzbIMEC2/ IzMnDPwsc77TdQ== 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=SxrhJaMcj1HzojHw3OgQ9ZImCrH4+ X3cH0255hBdMq8=; b=mmmCieq6FuGwWXP0Xd9CWyCbvrmJ6PL1KsGkCzg3bb2TP PXglqZA99tlwJARHURm8ztEvHCvEYvbutCKEj65Gg2nVLgh2oDi1QLcFRPpPAjcy VDDmH9ShezhIZ2iPlGakOhhOyhBnCDVoVQKtAwZLKxwxdIZnZTQ3cMWt9V83GfNm r7ozjCprnhpQVnyDqOhLGrVYjoNGq5bzyD8i/9ypry4BRQ0loukDJfnyZGrYorjd hHd+thO12BZiW97QSqSihpB5KBTMPM61VCGC1TyhUl3E1EZGD+VGuc6XmV8vUZC0 gmBbwaylC0hix5Xo0vLOxjZWtwIFXDxvIHiJdP7xA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrieekgdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgspgfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc fkphepudduledrledrgeefrddvgedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 9CAA6D6005A for ; Sat, 12 Oct 2019 20:45:37 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 189C4C284F for ; Sun, 13 Oct 2019 00:45:31 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============0820865355536772609==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20191013004531.189C4C284F@cloud.mnot.net> Date: Sun, 13 Oct 2019 00:45:31 +0000 (UTC) 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, 13 Oct 2019 00:45:44 -0000 --===============0820865355536772609== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+4/-1/=F0=9F=92=AC39) 4 issues created: - Congestion control section in recovery migth be easier to understand if= it was self-contained (by jrudolph) https://github.com/quicwg/base-drafts/issues/3088 = - Add application parameters to QUIC handshake and use it for H3 SETTINGS= (by nharper) https://github.com/quicwg/base-drafts/issues/3086 = - Stateless reset detection should be datagram-based (by martinthomson) https://github.com/quicwg/base-drafts/issues/3085 [-transport] = - Insert Count Increment instruction description has race condition (by b= encebeky) https://github.com/quicwg/base-drafts/issues/3082 = 17 issues received 39 new comments: - #3053 Padding requirement seems to be incorrect. (8 by martinthomson, m= ikkelfj, ekr, MikeBishop) https://github.com/quicwg/base-drafts/issues/3053 [-transport] [design]= [proposal-ready] = - #3086 Add application parameters to QUIC handshake and use it for H3 SE= TTINGS (6 by mikkelfj, nharper, martinthomson, ianswett, MikeBishop) https://github.com/quicwg/base-drafts/issues/3086 [-http] [-transport] = - #3078 Lost Server Initial Takes Too Long to be Retransmitted (4 by kazu= ho, mikkelfj, ianswett) https://github.com/quicwg/base-drafts/issues/3078 [-recovery] = - #2928 Lift single-packet ClientHello requirement? (3 by martinthomson, = tatsuhiro-t, davidben) https://github.com/quicwg/base-drafts/issues/2928 [-tls] [design] = - #3034 Allow PING in Initial/Handshake? (3 by kazuho, janaiyengar, marti= nduke) https://github.com/quicwg/base-drafts/issues/3034 [-tls] [-transport] [= design] [proposal-ready] = - #2632 H3 GOAWAY should be symmetric and cover bidi and uni streams (2 b= y afrind, ianswett) https://github.com/quicwg/base-drafts/issues/2632 [-http] [design] = - #3082 Insert Count Increment instruction description has race condition= (2 by bencebeky, afrind) https://github.com/quicwg/base-drafts/issues/3082 [-qpack] = - #2152 Why does stateless reset have to be checked after MAC failure (2 = by martinthomson, janaiyengar) https://github.com/quicwg/base-drafts/issues/2152 [-transport] [design] = - #3075 Discussion in quic-recovery of delayed ack being 25ms does not se= em to relate to anything (1 by jrudolph) https://github.com/quicwg/base-drafts/issues/3075 [-recovery] [editoria= l] = - #3073 Boolean blocked streams setting (1 by dtikhonov) https://github.com/quicwg/base-drafts/issues/3073 [-qpack] [design] = - #2985 Changing protocol elements: Is this text strong enough? (1 by Mi= keBishop) https://github.com/quicwg/base-drafts/issues/2985 [-http] [editorial] = - #3085 Stateless reset detection should be datagram-based (1 by martinth= omson) https://github.com/quicwg/base-drafts/issues/3085 [-transport] = - #3088 Congestion control section in recovery migth be easier to underst= and if it was self-contained (1 by ianswett) https://github.com/quicwg/base-drafts/issues/3088 = - #2963 What if server does not send HTTP_EARLY_RESPONSE but starts sendi= ng response (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2963 [-http] = - #3061 Unclear what to do when QUIC Version Hints are missing (1 by Mike= Bishop) https://github.com/quicwg/base-drafts/issues/3061 [-http] = - #3071 Mention unidirectional Stream Types 2 and 3 (QPACK) in -http (1 b= y MikeBishop) https://github.com/quicwg/base-drafts/issues/3071 [-http] = - #3013 QUIC versions can no longer be greased (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/3013 [-transport] [editori= al] = 1 issues closed: - SRTT vs. smoothed_rtt in quic-recovery https://github.com/quicwg/base-d= rafts/issues/3076 [-recovery] [editorial] = Pull requests ------------- * quicwg/base-drafts (+6/-1/=F0=9F=92=AC4) 6 pull requests submitted: - Make transport parameters varint (by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/3087 = - Pseudo-header section reference (by MikeBishop) https://github.com/quicwg/base-drafts/pull/3084 [-http] = - Additional error cases for CANCEL_PUSH (by MikeBishop) https://github.com/quicwg/base-drafts/pull/3083 [-http] = - Mention QPACK streams (by MikeBishop) https://github.com/quicwg/base-drafts/pull/3081 [-http] [editorial] = - Retransmit server initial upon second Initial (by ianswett) https://github.com/quicwg/base-drafts/pull/3080 [-recovery] [design] = - Stop using SRTT (by ianswett) https://github.com/quicwg/base-drafts/pull/3079 = 3 pull requests received 4 new comments: - #3087 Make transport parameters varint (2 by DavidSchinazi, ekr) https://github.com/quicwg/base-drafts/pull/3087 = - #3077 Remove obsolete 'Discussion' section (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/3077 [-transport] [editorial= ] = - #3080 Retransmit server initial upon second Initial (1 by mikkelfj) https://github.com/quicwg/base-drafts/pull/3080 [-recovery] [design] = 1 pull requests merged: - Stop using SRTT https://github.com/quicwg/base-drafts/pull/3079 [-recovery] [editorial] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============0820865355536772609== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday October 13, 2019

Issues

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

4 issues created:

17 issues received 39 new comments:

1 issues closed:

Pull requests

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

6 pull requests submitted:

3 pull requests received 4 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============0820865355536772609==-- From nobody Sat Oct 12 20:41:06 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1032D12004F for ; Sat, 12 Oct 2019 20:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 I6pnUoXxOQqx for ; Sat, 12 Oct 2019 20:41:02 -0700 (PDT) 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 7A51E1200C1 for ; Sat, 12 Oct 2019 20:41:02 -0700 (PDT) Received: from xse424.mail2web.com ([66.113.197.170] helo=xse.mail2web.com) by mx61.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iJUkd-0003IF-3s for quic@ietf.org; Sun, 13 Oct 2019 05:41:00 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46rSC80lH3z9wL for ; Sat, 12 Oct 2019 20:40:52 -0700 (PDT) Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iJUkV-0003xK-Vh for quic@ietf.org; Sat, 12 Oct 2019 20:40:52 -0700 Received: (qmail 6287 invoked from network); 13 Oct 2019 03:40:51 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.46.167]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Oct 2019 03:40:51 -0000 To: lionel.morand@orange.com, "quic@ietf.org" , "ietf-http-wg@w3.org" Cc: "httpbis-chairs@ietf.org" , "allison.mankin@gmail.com" , "quic-chairs@ietf.org" , Gonzalo Camarillo , "httpbis-ads@ietf.org" , "quic-ads@ietf.org" , Magnus Westerlund , wes@mti-systems.com, "Gorry (erg)" , "Black, David" References: <20859_1570868686_5DA18DCE_20859_72_1_6B7134B31289DC4FAF731D844122B36E3A240FE0@OPEXCAUBM41.corporate.adroot.infra.ftgroup> 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: LS from 3GPP on QUIC network level troubleshooting capabilities Message-ID: <4f9136db-73f7-33a6-bd1e-b399bfa7bf7e@huitema.net> Date: Sat, 12 Oct 2019 20:40:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20859_1570868686_5DA18DCE_20859_72_1_6B7134B31289DC4FAF731D844122B36E3A240FE0@OPEXCAUBM41.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------CCC5555733DEA5A77C5E0C6D" Content-Language: en-US X-Originating-IP: 66.113.197.170 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/gcnlw0ezqdolHG91LK5q2HN6uCHCpSDasLI4SayDByyq9LIhVTKi82n41d7jG rcgZcglcH0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fvn5fhUOAgUCIF/AsWwq6GFU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+5aB4itzNZ07CdqP+KMfGjQTAas0edmB2q/yBRqnQY9Wo6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhMjx7v77N42Z/zX3DQBtZa/0j9rMdVQseW3F+doIupqmER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnJdoieX2NtRg +o3kI8QyLIsFNipas5GqVFZmFIt1Sjg0LKbq8lyGG1FfnJ0B4MBu+geYUOp7A73HI6oJg7w/VocK FIxNlsy2WJpil5s07kEDyBw3j/aBxjxoZyMqfIL/jJq7xqDoiTjjGpNS1XGXbXJWzE4wUuzMSGbD 6Ufjf/MBAztqzrCt4TZ/wLtujY/tpQOUv9644NuwDNvePHyvR7X3VylGNWWBbxVJZI1dMnXSPAlb DjazCbhs7qBpykynMha5/rijjcguRYfyvX/qs6DKrgysbQQzvYf503ssGH7I83g9ueTJOU6a76yp yxjdeg8YhWenlMfuvb1mNY5/IPiuedK/Z3MvnAyDmuOaA5CGZRWsGw8ac2InzcAP/gmxwNpms+rB 6wJM+NNhN3aT35NSU/fjw6KbqLw80r1gDO3m6U0LjBzYuQztdAThgtWSU3qCINKqlAdh+ePAcEwD s/8= X-Report-Abuse-To: spam@quarantine9.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: Sun, 13 Oct 2019 03:41:05 -0000 This is a multi-part message in MIME format. --------------CCC5555733DEA5A77C5E0C6D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This topic, troubleshooting capabilities supported by QUIC compared to the ones available with TCP, is currently being debated in the transport area working group (tsvwg). The TSVWG draft (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/) is a general discussion of "The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet". It might be a good idea for the IETF to have that discussion at just one place. -- Christian huitema On 10/12/2019 1:24 AM, lionel.morand@orange.com wrote: > > Hi, > > =A0 > > Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4). > > This WG is actually studying the introduction of QUIC as transport > protocol instead of HTTP/2 in the 5G core network. > > The WG has some questions regarding the troubleshooting capabilities > supported by QUIC compared to the ones available with TCP. > > =A0 > > The LS is officially addressed to the QUIC WG. However, it was > highlighted that httpbis WG could also be interested in. I will let > you decide if only QUIC or both are relevant in the discussion. > > =A0 > > Next CT4 WG meetings: > > 3GPP TSG CT4#95=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 11th =96 15th November 20= 19=A0=A0=A0=A0=A0=A0 Reno, US > > 3GPP TSG CT4#96=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 24th =96 28th February 20= 20=A0=A0=A0=A0=A0=A0=A0=A0=A0 Sophia > Antipolis, FR > > =A0 > > It would be good to receive an official feedback at the latest for the > February meeting, where the study will be concluded (at least for this > release). > > =A0 > > Regards, > > =A0 > > -----------------------------------------------------------------------= - > > http://www.orange.com/sirius/logos_mail/orange_logo.gif > > *Lionel=A0Morand* > Chair of 3GPP TSG CT > > 3GPP Liaison Person to IETF > > Chair of IETF Dime and Radext WGs > Core Network Senior Architect and Diameter expert > > Cell. +33 6 07 75 89 36 > > lionel.morand@orange.com > > =A0 > > =A0 > > =A0 > > =A0 > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. --------------CCC5555733DEA5A77C5E0C6D Content-Type: multipart/related; boundary="------------DE4ED289A0B9935653581995" --------------DE4ED289A0B9935653581995 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

This topic, troubleshooting capabilities supported by QUIC compared to the ones available with TCP, is currently being debated in the transport area working group (tsvwg). The TSVWG draft (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/) is a general discussion of "The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet".

It might be a good idea for the IETF to have that discussion at just one place.

-- Christian huitema

On 10/12/2019 1:24 AM, lionel.morand@orange.com wrote:

Hi,

 

Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4).

This WG is actually studying the introduction of QUIC as transport protocol instead of HTTP/2 in the 5G core network.

The WG has some questions regarding the troubleshooting capabilities supported by QUIC compared to the ones available with TCP.

 

The LS is officially addressed to the QUIC WG. However, it was highlighted that httpbis WG could also be interested in. I will let you decide if only QUIC or both are relevant in the discussion.

 

Next CT4 WG meetings:

3GPP TSG CT4#95           11th – 15th November 2019       Reno, US

3GPP TSG CT4#96           24th – 28th February 2020          Sophia Antipolis, FR

 

It would be good to receive an official feedback at the latest for the February meeting, where the study will be concluded (at least for this release).

 

Regards,

 

http://www.orange.com/sirius/logos_mail/orange_logo.gif

Lionel Morand
Chair of 3GPP TSG CT

3GPP Liaison Person to IETF

Chair of IETF Dime and Radext WGs
Core Network Senior Architect and Diameter expert

Cell. +33 6 07 75 89 36
lionel.morand@orange.com

 

 

 

 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--------------DE4ED289A0B9935653581995 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="image001.jpg" /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CAAyADIDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCxRRRX52fpgUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAWbXT7y+3fZbaSbZ97YOlEen3ksTypaytGhIdgvCkdc1s6PfWv9kpZy37WM kVyJy4H+sX0qXUdctbq0kSKWSNZb3fIi8Ex4xmu+OHo+zUnLX5HBLEV/aOCjpfz/AK1/4cw5 NLv4ljaS0lUSHCEr1NJPpt9bKjTWksYkbapZep9K63+2tKhTy47tGQXKSIApyFA7nuaq2mtQ NNIGdp5H1HzY0PUp6itJYSgnbn/Iyji8Q1fk/M52bStQt9vnWcybiFXK9Se1S/2W8LbL5jZu eV8xeCK7Bp4dEtIprmeWdDfM/wC8GCoPoPaub16+juIILeK6huER2ceXHt2596VbC0qMW29e 39foOji61aSilp31/r7zDf5XYD5gDgH1ooorzT0wooooAKMleQSCOhHaiinHcT2Hy3E9w486 aSTA43sTj86ZRRWlf+IzKh/DQUUUVkbH/9k= --------------DE4ED289A0B9935653581995-- --------------CCC5555733DEA5A77C5E0C6D-- From nobody Sat Oct 12 23:40:21 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C5B1200D6; Sat, 12 Oct 2019 23:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 CsB6OG7_ZyzI; Sat, 12 Oct 2019 23:40:17 -0700 (PDT) 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 DA914120025; Sat, 12 Oct 2019 23:40:16 -0700 (PDT) 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 x9D6bC52011537; Sun, 13 Oct 2019 07:40:02 +0100 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=90JW9YTElTdphPmuO37A2gZvVXxENkLlaqk9WoWcnHw=; b=Y7bCYtdP34YUQR6AYDCUMBdMV/ZPhZAoMYXjMnwXO4TIqeL2NvgEb/DYXeOYSrdG5YWS rCNU/m0c5HdjkQ65LRzs2D1TrNXuXPD9XBW/U7Xb6CbrMjcM3u4ks0qSuXKnzWsYGfqX p0ljLHKejjGKigkWIlpx6MzQ722VLWXnjaGz2hhwyTJRQs+f3ixX+r8JA4grOVF9AghB p+hrK/7+pTCUNCgFqIcPCkZ0HDIE7WBZWl0ZVz8C7rhGeUQLRuSFjuoV8TEemrCOZfTD c55vTg4RGiRwx9mVwXNXwn0c0zy1PcE8IxLXzCbALu0C0W3KsG5Lwy+8fy9NpuzPLl9c wQ== 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 2vk6fuv917-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 13 Oct 2019 07:40:02 +0100 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 x9D6W29x022288; Sun, 13 Oct 2019 02:40:01 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint3.akamai.com with ESMTP id 2vka5wapsy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 13 Oct 2019 02:40:00 -0400 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 13 Oct 2019 01:39:59 -0500 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.165.124]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.165.124]) with mapi id 15.00.1473.005; Sat, 12 Oct 2019 23:39:59 -0700 From: "Lubashev, Igor" To: Christian Huitema , "lionel.morand@orange.com" , "quic@ietf.org" , "ietf-http-wg@w3.org" CC: "httpbis-chairs@ietf.org" , Magnus Westerlund , "allison.mankin@gmail.com" , "quic-chairs@ietf.org" , "wes@mti-systems.com" , "Gorry (erg)" , Gonzalo Camarillo , "Black, David" , "httpbis-ads@ietf.org" , "quic-ads@ietf.org" Subject: RE: LS from 3GPP on QUIC network level troubleshooting capabilities Thread-Topic: LS from 3GPP on QUIC network level troubleshooting capabilities Thread-Index: AdWA0hpjWJ/tXLvVSCu8fqJq00l+9AA4JOQAAAlHYwA= Date: Sun, 13 Oct 2019 06:39:58 +0000 Message-ID: References: <20859_1570868686_5DA18DCE_20859_72_1_6B7134B31289DC4FAF731D844122B36E3A240FE0@OPEXCAUBM41.corporate.adroot.infra.ftgroup> <4f9136db-73f7-33a6-bd1e-b399bfa7bf7e@huitema.net> In-Reply-To: <4f9136db-73f7-33a6-bd1e-b399bfa7bf7e@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.113] Content-Type: multipart/related; boundary="_004_f083b00a0b374ab28c0db505ea61eaeeustx2exdag1mb6msgcorpak_"; type="multipart/alternative" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-13_03:, , 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-1908290000 definitions=main-1910130064 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-13_03:2019-10-10,2019-10-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 priorityscore=1501 phishscore=0 impostorscore=0 mlxscore=0 lowpriorityscore=0 malwarescore=0 suspectscore=0 mlxlogscore=999 adultscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910130065 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, 13 Oct 2019 06:40:19 -0000 --_004_f083b00a0b374ab28c0db505ea61eaeeustx2exdag1mb6msgcorpak_ Content-Type: multipart/alternative; boundary="_000_f083b00a0b374ab28c0db505ea61eaeeustx2exdag1mb6msgcorpak_" --_000_f083b00a0b374ab28c0db505ea61eaeeustx2exdag1mb6msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christian, do you believe that the outcome of the tsvwg discussion and the = contents of draft-ietf-Ztsvwg-transport-encrypt will be timely enough to af= fect QUIC v1? If not, a discussion in QUIC WG would have a better chance o= f being timely for QUIC v1. 3GPP consists of Internet players who are mostly absent from QUIC WG, and t= heir concerns should be taken seriously, since their networks carry a large= portion of QUIC traffic. It would require everyone's efforts to ensure th= at QUIC can grow from a single-digit percentage to the majority of Internet= traffic with QUIC v1. * Igor From: Christian Huitema Sent: Saturday, October 12, 2019 11:41 PM This topic, troubleshooting capabilities supported by QUIC compared to the = ones available with TCP, is currently being debated in the transport area w= orking group (tsvwg). The TSVWG draft (https://datatracker.ietf.org/doc/dra= ft-ietf-tsvwg-transport-encrypt/) is a general discussion of "T= he Impact of Transport Header Confidentiality on Network Operation and Evol= ution of the Internet". It might be a good idea for the IETF to have that discussion at just one pl= ace. -- Christian huitema On 10/12/2019 1:24 AM, lionel.morand@orange.com wrote: Hi, Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4). This WG is actually studying the introduction of QUIC as transport protocol= instead of HTTP/2 in the 5G core network. The WG has some questions regarding the troubleshooting capabilities suppor= ted by QUIC compared to the ones available with TCP. The LS is officially addressed to the QUIC WG. However, it was highlighted = that httpbis WG could also be interested in. I will let you decide if only = QUIC or both are relevant in the discussion. Next CT4 WG meetings: 3GPP TSG CT4#95 11th - 15th November 2019 Reno, US 3GPP TSG CT4#96 24th - 28th February 2020 Sophia Antipol= is, FR It would be good to receive an official feedback at the latest for the Febr= uary meeting, where the study will be concluded (at least for this release)= . Regards, ________________________________ [http://www.orange.com/sirius/logos_mail/orange_logo.gif] Lionel Morand Chair of 3GPP TSG CT 3GPP Liaison Person to IETF Chair of IETF Dime and Radext WGs Core Network Senior Architect and Diameter expert Cell. +33 6 07 75 89 36 lionel.morand@orange.com --_000_f083b00a0b374ab28c0db505ea61eaeeustx2exdag1mb6msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Christian, do you believe that the outcome of the ts= vwg discussion and the contents of draft-ietf-Ztsvwg-transport-encrypt will= be timely enough to affect QUIC v1?  If not, a discussion in QUIC WG = would have a better chance of being timely for QUIC v1.

 

3GPP consists of Internet players who are mostly abs= ent from QUIC WG, and their concerns should be taken seriously, since their= networks carry a large portion of QUIC traffic.  It would require eve= ryone’s efforts to ensure that QUIC can grow from a single-digit percentage to the majority of Internet traffic wi= th QUIC v1.

 

  • Igor

 

From: Christian Huitema <huitema@huitema.n= et>
Sent: Saturday, October 12, 2019 11:41 PM

This topic, troubleshooting capabilities supported by QUIC compared to t= he ones available with TCP, is currently being debated in the transport are= a working group (tsvwg). The TSVWG draft (https://datatracker.ietf.org/do= c/draft-ietf-tsvwg-transport-encrypt/) is a general discussion of "The Impact of Transport Header Confidenti= ality on Network Operation and Evolution of the Internet".

It might be a good idea for the IETF to have that discussion at just one= place.

-- Christian huitema

On 10/12/2019 1:24 AM, lionel.morand@orange.com wrote:

Hi,

 

Please find enclosed a liaison statement from the 3G= PP CT WG 4 (CT4).

This WG is actually studying the introduction of QUI= C as transport protocol instead of HTTP/2 in the 5G core network.

The WG has some questions regarding the troubleshoot= ing capabilities supported by QUIC compared to the ones available with TCP.=

 

The LS is officially addressed to the QUIC WG. Howev= er, it was highlighted that httpbis WG could also be interested in. I will = let you decide if only QUIC or both are relevant in the discussion.

 

Next CT4 WG meetings:

3GPP TSG CT4#95      &= nbsp;    11th – 15th November 2019   &n= bsp;   Reno, US

3GPP TSG CT4#96      &= nbsp;    24th – 28th February 2020   &n= bsp;      Sophia Antipolis, FR

 

It would be good to receive an official feedback at = the latest for the February meeting, where the study will be concluded (at = least for this release).

 

Regards,

 

3D"http://www.orange.com/sirius/logos_=

Lionel Morand
Chair of 3GPP TSG CT

3GPP Liaison Person to IETF=

Chair of IETF Dime and Radext WGs
Core Network Senior Architect and Diameter expert

Cell. +33 6 07 75 89 36 =
lione= l.morand@orange.com  

--_000_f083b00a0b374ab28c0db505ea61eaeeustx2exdag1mb6msgcorpak_-- --_004_f083b00a0b374ab28c0db505ea61eaeeustx2exdag1mb6msgcorpak_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=998; creation-date="Sun, 13 Oct 2019 06:39:58 GMT"; modification-date="Sun, 13 Oct 2019 06:39:58 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAyADIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCxRRRX 52fpgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAWbXT7y+3fZbaSbZ97YOlEen3ksTypaytGh IdgvCkdc1s6PfWv9kpZy37WMkVyJy4H+sX0qXUdctbq0kSKWSNZb3fIi8Ex4xmu+OHo+zUnLX5HB LEV/aOCjpfz/AK1/4cw5NLv4ljaS0lUSHCEr1NJPpt9bKjTWksYkbapZep9K63+2tKhTy47tGQXK SIApyFA7nuaq2mtQNNIGdp5H1HzY0PUp6itJYSgnbn/Iyji8Q1fk/M52bStQt9vnWcybiFXK9Se1 S/2W8LbL5jZueV8xeCK7Bp4dEtIprmeWdDfM/wC8GCoPoPaub16+juIILeK6huER2ceXHt2596Vb C0qMW29e39foOji61aSilp31/r7zDf5XYD5gDgH1ooorzT0wooooAKMleQSCOhHaiinHcT2Hy3E9 w486aSTA43sTj86ZRRWlf+IzKh/DQUUUVkbH/9k= --_004_f083b00a0b374ab28c0db505ea61eaeeustx2exdag1mb6msgcorpak_-- From nobody Sun Oct 13 01:34:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0260E12007A; Sun, 13 Oct 2019 01:34:32 -0700 (PDT) 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 nqD1BQ1TanOu; Sun, 13 Oct 2019 01:34:30 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042B812001E; Sun, 13 Oct 2019 01:34:30 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 41E8120044; Sun, 13 Oct 2019 11:34:23 +0300 (EEST) From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4B3E24BE-85F4-4D31-AA4A-0A78A63E0D40"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: LS from 3GPP on QUIC network level troubleshooting capabilities Date: Sun, 13 Oct 2019 11:33:56 +0300 In-Reply-To: <20859_1570868686_5DA18DCE_20859_72_1_6B7134B31289DC4FAF731D844122B36E3A240FE0@OPEXCAUBM41.corporate.adroot.infra.ftgroup> Cc: "quic@ietf.org" , "ietf-http-wg@w3.org" , "httpbis-chairs@ietf.org" , "allison.mankin@gmail.com" , "quic-chairs@ietf.org" , Gonzalo Camarillo , "httpbis-ads@ietf.org" , "quic-ads@ietf.org" To: lionel.morand@orange.com References: <20859_1570868686_5DA18DCE_20859_72_1_6B7134B31289DC4FAF731D844122B36E3A240FE0@OPEXCAUBM41.corporate.adroot.infra.ftgroup> X-MailScanner-ID: 70823844FB6.A3C32 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: Sun, 13 Oct 2019 08:34:32 -0000 --Apple-Mail=_4B3E24BE-85F4-4D31-AA4A-0A78A63E0D40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Lionel, On 2019-10-12, at 11:24, = wrote: > Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4). I do not see this liaison statement posted at = https://datatracker.ietf.org/liaison/. Please make sure to submit it via = the regular process, to keep all relevant entities in the loop. > This WG is actually studying the introduction of QUIC as transport = protocol instead of HTTP/2 in the 5G core network. > The WG has some questions regarding the troubleshooting capabilities = supported by QUIC compared to the ones available with TCP. Based on my (limited) understanding of the 5G architecture, this use of = QUIC would be as a protocol for carrying control information inside a 5G = network control plane. In other words, it is not about the end-to-end = use of QUIC over paths that traverse 5G networks. Is my understanding = correct? Thanks, Lars > The LS is officially addressed to the QUIC WG. However, it was = highlighted that httpbis WG could also be interested in. I will let you = decide if only QUIC or both are relevant in the discussion. >=20 > Next CT4 WG meetings: > 3GPP TSG CT4#95 11th =E2=80=93 15th November 2019 = Reno, US > 3GPP TSG CT4#96 24th =E2=80=93 28th February 2020 = Sophia Antipolis, FR >=20 > It would be good to receive an official feedback at the latest for the = February meeting, where the study will be concluded (at least for this = release). >=20 > Regards, >=20 > >=20 > Lionel Morand > Chair of 3GPP TSG CT > 3GPP Liaison Person to IETF > Chair of IETF Dime and Radext WGs > Core Network Senior Architect and Diameter expert > Cell. +33 6 07 75 89 36 > lionel.morand@orange.com >=20 >=20 >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > --Apple-Mail=_4B3E24BE-85F4-4D31-AA4A-0A78A63E0D40 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl2i4XQACgkQVLXDCb9w wVdPtA/9GHvFNdKTT1Z3umeMZMPxjt0tPxHm+T9+eRrWRgwtkDCmzJmumUzvZ1Gn o5Os6Kmz3lZNnqwgxyLrc9dzbxhW2dViT8KPbexBaH+z2MkyE4HfCfA7y3ARIUmG uhcyUgjeoSSLcatLtM8b7nVtEW/XIcg2y7WumOW5lbyyXLQ/guk/OJhNVd+281Mo +67riLRHGpDG3wpbWIRmuGbfSgkL56fm01lcSHdZrFGt/nhf4QYTz5rvAGl2Tdgs OwEGLa4Otcd0X2Khe1Phk1JTbVQbZ8m7AxHon63xjPGSasyaDBHu/k8mkg91JHPf lp8nhlIyzUVlufcuJoXXrjFBYRgJz3myboppNcnTYK/lpaNjzMJW0bbNbKjLrvIH VCk104/NYCW6nN6+u5Tk3x7OWKd9V/23u2p6hw7pfU90qFmIYVnaWeUG0Smcl1MR KYV7gLSa2NPL3u3HP0RA07BUy6q1tlVw+WR4Cp1L8wYCnTwhYQqP98kwQ0IqAzE6 P4FLcMBZycJB+fPqFijKhgMDhpy84YBEVsLwH4tJu5DxR0K0k32wsykLnEF5oXq7 VvInLsusHbUaZ6zJEUlzOCLMGQgxLf9Nk6aIe2g9CiXZ6GTSoSqvu9ceqUYAzZlt 1s1o4SOktD2O1fvuhPr3TW+EGaslgicsIYq/GZ6SjRHaOt43TF4= =/NJb -----END PGP SIGNATURE----- --Apple-Mail=_4B3E24BE-85F4-4D31-AA4A-0A78A63E0D40-- From nobody Sun Oct 13 15:35:37 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71268120088 for ; Sun, 13 Oct 2019 15:35:35 -0700 (PDT) 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=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 uUMGNvuwBaxS for ; Sun, 13 Oct 2019 15:35:33 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 10829120071 for ; Sun, 13 Oct 2019 15:35:32 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id j5so4437956uak.12 for ; Sun, 13 Oct 2019 15:35:32 -0700 (PDT) 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=yKmtOj4lVH11e43RAofdHSNusE7IA9ok/etsjUKj2LI=; b=iLYi6B3RXZIQwpNWHuXpnyCzkhpL63wA6IiHiHgh4AFBpqmgmEWvTUMjyZDhuSpMNN WMHQWTgoaCe8cTptlEH04D8KQLpo+xgkh5wQCv8nhiXkieg4MazCCmpTljkzbI6GZ0Ql dkoDGK0h0aKRfaORSbA6DxzPBhP1gccBcLothbM4i0l6Co9/IFzabPTT0WJCHts1tk9I ieYO62YcTyC/dbMOL1w7wyvvTMquzAuHm3FvdAXuikBq8zI2oMge3aIGsfn71mRfw1rG Wp43MWr8tYb0aE3xVJfgDjS1izYRAH6pD/5yS8O72Jmn4ReKardmIURnHCPGEfvmDVWg XRDg== 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=yKmtOj4lVH11e43RAofdHSNusE7IA9ok/etsjUKj2LI=; b=pPyi4XnqcCqFSXc9ZfbOa2nvRlvvgptrhw8ekYu6zyEKY6O86ozqLz8aSFIMWx0hqI NbV1EYmuQWvsKsfwSwRlJC8rHj8pffqRZtYSdBkT5fcDUlKwe7cVYPnJk57EwWadiFj+ Izhd4sRMWQf9hpYw2EenskU7bCv8ClVJqil/O2U5XXnp+Qkq5h0AqXPgyO1WfcRnUGiX DE7pPmh44mHQOvi/nq69moRPBOf1SkaDbixHERRyvJXIDAKi1NUenkSWxz8BcQ+WHg2d dxDYBZi9N1lfAQ90H1FHxEcdN7lokN6xnxDQ6owmYCLOZCs7xUTqpbsFQ5dfMi+vXbDW pzoA== X-Gm-Message-State: APjAAAXbutjh10x9cI3ZObf6g/gzSTGtlvdefHnx5NAY/HDNxYrE82mP Xq8etHkLpebCWESMyHjRSVFc0EIqCwJN5Bp4CPR8kg== X-Google-Smtp-Source: APXvYqxbqID/Hc3OR1Wa/M+dtGMWfGHsdpUIzonp4/ahmQCJ/IlWZxxOgSd4yMx6l2PMLH7Ujp6+t/uHJliKTYZ/1So= X-Received: by 2002:ab0:3018:: with SMTP id f24mr10214851ual.24.1571006131616; Sun, 13 Oct 2019 15:35:31 -0700 (PDT) MIME-Version: 1.0 References: <20859_1570868686_5DA18DCE_20859_72_1_6B7134B31289DC4FAF731D844122B36E3A240FE0@OPEXCAUBM41.corporate.adroot.infra.ftgroup> In-Reply-To: From: Ian Swett Date: Sun, 13 Oct 2019 18:35:20 -0400 Message-ID: Subject: Re: LS from 3GPP on QUIC network level troubleshooting capabilities To: Lars Eggert Cc: lionel.morand@orange.com, "httpbis-chairs@ietf.org" , "allison.mankin@gmail.com" , "quic-chairs@ietf.org" , Gonzalo Camarillo , "ietf-http-wg@w3.org" , "quic@ietf.org" , "quic-ads@ietf.org" , "httpbis-ads@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006ac17a0594d25e63" 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, 13 Oct 2019 22:35:36 -0000 --0000000000006ac17a0594d25e63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If the main concern is inability to passively measure packet loss and as Lars said this is not for end-to-end user traffic(so support for certain extensions could be assumed), then this could be a good test case for draft-ferrieuxhamchaoui-quic-lossbits to prove it works as intended and see if the mechanism needs any changes. On Sun, Oct 13, 2019 at 4:34 AM Lars Eggert wrote: > Hi Lionel, > > On 2019-10-12, at 11:24, < > lionel.morand@orange.com> wrote: > > Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4). > > I do not see this liaison statement posted at > https://datatracker.ietf.org/liaison/. Please make sure to submit it via > the regular process, to keep all relevant entities in the loop. > > > This WG is actually studying the introduction of QUIC as transport > protocol instead of HTTP/2 in the 5G core network. > > The WG has some questions regarding the troubleshooting capabilities > supported by QUIC compared to the ones available with TCP. > > Based on my (limited) understanding of the 5G architecture, this use of > QUIC would be as a protocol for carrying control information inside a 5G > network control plane. In other words, it is not about the end-to-end use > of QUIC over paths that traverse 5G networks. Is my understanding correct= ? > > Thanks, > Lars > > > The LS is officially addressed to the QUIC WG. However, it was > highlighted that httpbis WG could also be interested in. I will let you > decide if only QUIC or both are relevant in the discussion. > > > > Next CT4 WG meetings: > > 3GPP TSG CT4#95 11th =E2=80=93 15th November 2019 Reno,= US > > 3GPP TSG CT4#96 24th =E2=80=93 28th February 2020 So= phia > Antipolis, FR > > > > It would be good to receive an official feedback at the latest for the > February meeting, where the study will be concluded (at least for this > release). > > > > Regards, > > > > > > > > Lionel Morand > > Chair of 3GPP TSG CT > > 3GPP Liaison Person to IETF > > Chair of IETF Dime and Radext WGs > > Core Network Senior Architect and Diameter expert > > Cell. +33 6 07 75 89 36 <+33%206%2007%2075%2089%2036> > > lionel.morand@orange.com > > > > > > > > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > > Thank you. > > > > capabilities.docx> > > --0000000000006ac17a0594d25e63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the main concern is inability to passively measure pack= et loss and as Lars said this is not for end-to-end user traffic(so support= for certain extensions could be assumed), then=C2=A0this could be a good t= est case for=C2=A0draft-ferrieuxhamchaoui-quic-lossbits to prove = it works as intended and see if the mechanism needs any changes.

<= div class=3D"gmail_quote">
On Sun, Oct= 13, 2019 at 4:34 AM Lars Eggert <lar= s@eggert.org> wrote:
Hi Lionel,

On 2019-10-12, at 11:24, <lionel.morand@orange.com> <lionel.morand@orange.com> wr= ote:
> Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4).<= br>
I do not see this liaison statement posted at https://datatrack= er.ietf.org/liaison/. Please make sure to submit it via the regular pro= cess, to keep all relevant entities in the loop.

> This WG is actually studying the introduction of QUIC as transport pro= tocol instead of HTTP/2 in the 5G core network.
> The WG has some questions regarding the troubleshooting capabilities s= upported by QUIC compared to the ones available with TCP.

Based on my (limited) understanding of the 5G architecture, this use of QUI= C would be as a protocol for carrying control information inside a 5G netwo= rk control plane. In other words, it is not about the end-to-end use of QUI= C over paths that traverse 5G networks. Is my understanding correct?

Thanks,
Lars

>=C2=A0 The LS is officially addressed to the QUIC WG. However, it was h= ighlighted that httpbis WG could also be interested in. I will let you deci= de if only QUIC or both are relevant in the discussion.
>
> Next CT4 WG meetings:
> 3GPP TSG CT4#95=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A011th =E2=80=93= 15th November 2019=C2=A0 =C2=A0 =C2=A0 =C2=A0Reno, US
> 3GPP TSG CT4#96=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A024th =E2=80=93= 28th February 2020=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sophia Antipolis, FR<= br> >
> It would be good to receive an official feedback at the latest for the= February meeting, where the study will be concluded (at least for this rel= ease).
>
> Regards,
>
> <image001.jpg>
>
> Lionel Morand
> Chair of 3GPP TSG CT
> 3GPP Liaison Person to IETF
> Chair of IETF Dime and Radext WGs
> Core Network Senior Architect and Diameter expert
> Cell. +33 6 07 75 89 36
> lionel.m= orand@orange.com
>
>
>
>
> ______________________________________________________________________= ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez= recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les me= ssages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privilege= d information that may be protected by law;
> they should not be distributed, used or copied without authorisation.<= br> > If you have received this email in error, please notify the sender and= delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified.
> Thank you.
>
> <Liaison Statement on QUIC network level troubleshooting capabiliti= es.docx>

--0000000000006ac17a0594d25e63-- From nobody Sun Oct 13 17:57:27 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A382112006B; Sun, 13 Oct 2019 17:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=dell.com header.b=Ndz47pGw; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=iQkVXptX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqgHQxYkTm5K; Sun, 13 Oct 2019 17:57:23 -0700 (PDT) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 0172F12001A; Sun, 13 Oct 2019 17:57:22 -0700 (PDT) Received: from pps.filterd (m0170398.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9E0t0SF020731; Sun, 13 Oct 2019 20:57:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=Af2nq1mXPIBRewaHDg2dokg4QohGEwYLTHBf2ofcP1A=; b=Ndz47pGwDj3Lw1OSVSuIz9S29NYYWipytjCR88oCTQ6oP5BPQEVB55MbN3xuCMRQBDXc ZU8C6/n4B+FrQ4LSHYt8kep6CDMnPZWqbABN1U300bETc6BAR2RR/hfS+3h1hcaRvrBh wWtJYmg3tVwCbluibiLkkcK3t0/6ti471HMUVDTrQclI1SQ2cq9kQaPBdggV1gfIcLk2 uhru8T/NXOimIws6Db8/aALJga47n1S3Fx2m4ueXsajbWE/6VN+Gswtn27lLFF6FKW7+ 5LPp4+Umhkjbgx5um5QKOf0I8XrhBJV5HjFqwggHaASvboHCYd3CqwqFuNouv3SPzoom Wg== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2vka28dcay-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 13 Oct 2019 20:57:05 -0400 Received: from pps.filterd (m0144103.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9E0qlwP116505; Sun, 13 Oct 2019 20:57:05 -0400 Received: from mailuogwhop.emc.com (mailuogwhop-nat.lss.emc.com [168.159.213.141] (may be forged)) by mx0b-00154901.pphosted.com with ESMTP id 2vkbk19j1g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 13 Oct 2019 20:57:04 -0400 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x9E0tMRZ027867 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Oct 2019 20:57:02 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com x9E0tMRZ027867 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1571014623; bh=b1vGfCifQbDuil4f0rigvszi9EI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=iQkVXptX4J4sKrFCVv3peRBaRjvkLgkKCRvxkGbzLu4tJKyVPD7Ak9gtXCSaNPBOB 16k6w3rN66pmIvRj2Qj//lCsbPucCOU96TNCrH01PPeuT3g/Ofzy/+EntwheMAjuSM B08pFNwOHtg0rYqk5GJn00vQdPhilxJbVJ0NQcuI= Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd02.lss.emc.com (RSA Interceptor); Sun, 13 Oct 2019 20:50:54 -0400 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x9E0oqnR017546 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sun, 13 Oct 2019 20:50:52 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0439.000; Sun, 13 Oct 2019 20:50:52 -0400 From: "Black, David" To: "Lubashev, Igor" , Christian Huitema , "lionel.morand@orange.com" , "quic@ietf.org" , "ietf-http-wg@w3.org" CC: "httpbis-chairs@ietf.org" , Magnus Westerlund , "allison.mankin@gmail.com" , "quic-chairs@ietf.org" , "wes@mti-systems.com" , "Gorry (erg)" , Gonzalo Camarillo , "httpbis-ads@ietf.org" , "quic-ads@ietf.org" , "Black, David" Subject: RE: LS from 3GPP on QUIC network level troubleshooting capabilities Thread-Topic: LS from 3GPP on QUIC network level troubleshooting capabilities Thread-Index: AQHVgXgUCEbHP7uci0COdxrFHPHjKqdYYi0AgADnzNA= Date: Mon, 14 Oct 2019 00:50:51 +0000 Message-ID: References: <20859_1570868686_5DA18DCE_20859_72_1_6B7134B31289DC4FAF731D844122B36E3A240FE0@OPEXCAUBM41.corporate.adroot.infra.ftgroup> <4f9136db-73f7-33a6-bd1e-b399bfa7bf7e@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-10-14T00:50:51.1586618Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public x-originating-ip: [10.105.8.135] Content-Type: multipart/related; boundary="_004_CE03DB3D7B45C245BCA0D24327794936307746ABMX307CL04corpem_"; type="multipart/alternative" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: DLM_1, public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-14_01:2019-10-10,2019-10-14 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 mlxlogscore=999 mlxscore=0 spamscore=0 priorityscore=1501 impostorscore=0 adultscore=0 clxscore=1011 lowpriorityscore=0 suspectscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910140006 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 mlxscore=0 malwarescore=0 clxscore=1011 lowpriorityscore=0 mlxlogscore=999 phishscore=0 priorityscore=1501 suspectscore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910140006 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, 14 Oct 2019 00:57:26 -0000 --_004_CE03DB3D7B45C245BCA0D24327794936307746ABMX307CL04corpem_ Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936307746ABMX307CL04corpem_" --_000_CE03DB3D7B45C245BCA0D24327794936307746ABMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Everyone, I write as a TSVWG WG chair and as the shepherd for the TSVWG draft that Ch= ristian mentioned. Going back to the beginning of this thread, Lionel wrot= e: > Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4). I could not find that in the liaison statement area of the IETF datatracker= . Would someone please forward a copy to tsvwg-chairs@ietf.org ? Thanks in advance. Moving onward ... > This topic, troubleshooting capabilities supported by QUIC compared to th= e ones available with TCP, is currently being debated in the transport area= working group (tsvwg). > The TSVWG draft (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transp= ort-encrypt/) is a general discussion of "The Impact of Transp= ort Header Confidentiality on Network Operation and Evolution of the Intern= et". The latter sentence is correct, but the first sentence is mistaken. Troub= leshooting capabilities supported by QUIC are a matter for the QUIC WG, and= discussion should occur there - in this regard, I'm reminded of a statemen= t posted on the cash register of a pizza place that I frequented back when = I was an undergrad: "The bank doesn't make pizza - We don't cash checks." T= here is a TSVWG discussion on the general matter of transport header confid= entiality impacts that we (TSVWG chairs) hope to see conclude in the near f= uture, as that draft (draft-ietf-tsvwg-transport-encrypt) is currently in W= G Last Call in TSVWG. If that discussion does conclude in the next several= weeks, the resulting revised draft would make a fine input to a QUIC WG di= scussion of troubleshooting, so: > It might be a good idea for the IETF to have that discussion at just one = place. I would agree and suggest the QUIC WG as the appropriate place for a discus= sion of QUIC troubleshooting. Thanks, --David From: Lubashev, Igor Sent: Sunday, October 13, 2019 2:40 AM To: Christian Huitema; lionel.morand@orange.com; quic@ietf.org; ietf-http-w= g@w3.org Cc: httpbis-chairs@ietf.org; Magnus Westerlund; allison.mankin@gmail.com; q= uic-chairs@ietf.org; wes@mti-systems.com; Gorry (erg); Gonzalo Camarillo; B= lack, David; httpbis-ads@ietf.org; quic-ads@ietf.org Subject: RE: LS from 3GPP on QUIC network level troubleshooting capabilitie= s [EXTERNAL EMAIL] Christian, do you believe that the outcome of the tsvwg discussion and the = contents of draft-ietf-Ztsvwg-transport-encrypt will be timely enough to af= fect QUIC v1? If not, a discussion in QUIC WG would have a better chance o= f being timely for QUIC v1. 3GPP consists of Internet players who are mostly absent from QUIC WG, and t= heir concerns should be taken seriously, since their networks carry a large= portion of QUIC traffic. It would require everyone's efforts to ensure th= at QUIC can grow from a single-digit percentage to the majority of Internet= traffic with QUIC v1. * Igor From: Christian Huitema > Sent: Saturday, October 12, 2019 11:41 PM This topic, troubleshooting capabilities supported by QUIC compared to the = ones available with TCP, is currently being debated in the transport area w= orking group (tsvwg). The TSVWG draft (https://datatracker.ietf.org/doc/dra= ft-ietf-tsvwg-transport-encrypt/) is a general discussion of "T= he Impact of Transport Header Confidentiality on Network Operation and Evol= ution of the Internet". It might be a good idea for the IETF to have that discussion at just one pl= ace. -- Christian huitema On 10/12/2019 1:24 AM, lionel.morand@orange.com wrote: Hi, Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4). This WG is actually studying the introduction of QUIC as transport protocol= instead of HTTP/2 in the 5G core network. The WG has some questions regarding the troubleshooting capabilities suppor= ted by QUIC compared to the ones available with TCP. The LS is officially addressed to the QUIC WG. However, it was highlighted = that httpbis WG could also be interested in. I will let you decide if only = QUIC or both are relevant in the discussion. Next CT4 WG meetings: 3GPP TSG CT4#95 11th - 15th November 2019 Reno, US 3GPP TSG CT4#96 24th - 28th February 2020 Sophia Antipol= is, FR It would be good to receive an official feedback at the latest for the Febr= uary meeting, where the study will be concluded (at least for this release)= . Regards, ________________________________ [http://www.orange.com/sirius/logos_mail/orange_logo.gif] Lionel Morand Chair of 3GPP TSG CT 3GPP Liaison Person to IETF Chair of IETF Dime and Radext WGs Core Network Senior Architect and Diameter expert Cell. +33 6 07 75 89 36 lionel.morand@orange.com --_000_CE03DB3D7B45C245BCA0D24327794936307746ABMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Everyone,

 

I write as a TSVWG WG = chair and as the shepherd for the TSVWG draft that Christian mentioned.&nbs= p; Going back to the beginning of this thread, Lionel wrote:

 

> Please find enclosed a liaison statement from t= he 3GPP CT WG 4 (CT4).

 

I could not find that = in the liaison statement area of the IETF datatracker.  Would someone = please forward a copy to tsvwg-chairs@ietf.org ?  = Thanks in advance.

 

Moving onward …<= o:p>

> This topic, troubleshooting capabilities supported by QUIC compared= to the ones available with TCP, is currently being debated in the transpor= t area working group (tsvwg).
> The TSVWG draft (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-t= ransport-encrypt/) is a general discussion of "The Impact of Transport Header Confidenti= ality on Network Operation and Evolution of the Internet".

The latter sentence is= correct, but the first sentence is mistaken.   Troubleshooting c= apabilities supported by QUIC are a matter for the QUIC WG, and discussion = should occur there – in this regard, I’m reminded of a statement posted on the cash register of a pizza place that I frequen= ted back when I was an undergrad: “The bank doesn’t make pizza = – We don’t cash checks.” There is a TSVWG discussion on t= he general matter of transport header confidentiality impacts that we (TSVWG chairs) hope to see conclude in the near future, as that dr= aft (draft-ietf-tsvwg-transport-encrypt) is currently in WG Last Call in TS= VWG.  If that discussion does conclude in the next several weeks, the = resulting revised draft would make a fine input to a QUIC WG discussion of troubleshooting, so:

> It might be a good idea for the IETF to have that discussion at jus= t one place.

I would agree and sugg= est the QUIC WG as the appropriate place for a discussion of QUIC troublesh= ooting.

 

Thanks, --David

 

From: Lubashev, Igor <ilubashe@akamai.com&= gt;
Sent: Sunday, October 13, 2019 2:40 AM
To: Christian Huitema; lionel.morand@orange.com; quic@ietf.org; ietf= -http-wg@w3.org
Cc: httpbis-chairs@ietf.org; Magnus Westerlund; allison.mankin@gmail= .com; quic-chairs@ietf.org; wes@mti-systems.com; Gorry (erg); Gonzalo Camar= illo; Black, David; httpbis-ads@ietf.org; quic-ads@ietf.org
Subject: RE: LS from 3GPP on QUIC network level troubleshooting capa= bilities

 

[EXTERNAL EMAIL]

Christian, do you believe that the outcome of the ts= vwg discussion and the contents of draft-ietf-Ztsvwg-transport-encrypt will= be timely enough to affect QUIC v1?  If not, a discussion in QUIC WG = would have a better chance of being timely for QUIC v1.

 

3GPP consists of Internet players who are mostly abs= ent from QUIC WG, and their concerns should be taken seriously, since their= networks carry a large portion of QUIC traffic.  It would require eve= ryone’s efforts to ensure that QUIC can grow from a single-digit percentage to the majority of Internet traffic wi= th QUIC v1.

 

  • Igor

 

From: Christian Huitema <huitema@huitema.net>
Sent: Saturday, October 12, 2019 11:41 PM

This topic, troubleshooting capabilities supported by QUIC compared to t= he ones available with TCP, is currently being debated in the transport are= a working group (tsvwg). The TSVWG draft (https://datatracker.ietf.org/do= c/draft-ietf-tsvwg-transport-encrypt/) is a general discussion of "The Impact of Transport Header Confidenti= ality on Network Operation and Evolution of the Internet".

It might be a good idea for the IETF to have that discussion at just one= place.

-- Christian huitema

On 10/12/2019 1:24 AM, lionel.morand@orange.com wrote:

Hi,

 

Please find enclosed a liaison statement from the 3G= PP CT WG 4 (CT4).

This WG is actually studying the introduction of QUI= C as transport protocol instead of HTTP/2 in the 5G core network.

The WG has some questions regarding the troubleshoot= ing capabilities supported by QUIC compared to the ones available with TCP.=

 

The LS is officially addressed to the QUIC WG. Howev= er, it was highlighted that httpbis WG could also be interested in. I will = let you decide if only QUIC or both are relevant in the discussion.

 

Next CT4 WG meetings:

3GPP TSG CT4#95      &= nbsp;    11th – 15th November 2019   &n= bsp;   Reno, US

3GPP TSG CT4#96      &= nbsp;    24th – 28th February 2020   &n= bsp;      Sophia Antipolis, FR

 

It would be good to receive an official feedback at = the latest for the February meeting, where the study will be concluded (at = least for this release).

 

Regards,

 

3D"http://www.orange.com/sirius/logos_=

Lionel Morand
Chair of 3GPP TSG CT

3GPP Liaison Person to IETF=

Chair of IETF Dime and Radext WGs
Core Network Senior Architect and Diameter expert

Cell. +33 6 07 75 89 36 =
lione= l.morand@orange.com  

--_000_CE03DB3D7B45C245BCA0D24327794936307746ABMX307CL04corpem_-- --_004_CE03DB3D7B45C245BCA0D24327794936307746ABMX307CL04corpem_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=998; creation-date="Mon, 14 Oct 2019 00:50:51 GMT"; modification-date="Mon, 14 Oct 2019 00:50:51 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAyADIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCxRRRX 52fpgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAWbXT7y+3fZbaSbZ97YOlEen3ksTypaytGh IdgvCkdc1s6PfWv9kpZy37WMkVyJy4H+sX0qXUdctbq0kSKWSNZb3fIi8Ex4xmu+OHo+zUnLX5HB LEV/aOCjpfz/AK1/4cw5NLv4ljaS0lUSHCEr1NJPpt9bKjTWksYkbapZep9K63+2tKhTy47tGQXK SIApyFA7nuaq2mtQNNIGdp5H1HzY0PUp6itJYSgnbn/Iyji8Q1fk/M52bStQt9vnWcybiFXK9Se1 S/2W8LbL5jZueV8xeCK7Bp4dEtIprmeWdDfM/wC8GCoPoPaub16+juIILeK6huER2ceXHt2596Vb C0qMW29e39foOji61aSilp31/r7zDf5XYD5gDgH1ooorzT0wooooAKMleQSCOhHaiinHcT2Hy3E9 w486aSTA43sTj86ZRRWlf+IzKh/DQUUUVkbH/9k= --_004_CE03DB3D7B45C245BCA0D24327794936307746ABMX307CL04corpem_-- From nobody Mon Oct 14 02:45:25 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA55012016E; Mon, 14 Oct 2019 02:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 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, UNPARSEABLE_RELAY=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 tUYbwG2e7N4B; Mon, 14 Oct 2019 02:45:19 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A30120143; Mon, 14 Oct 2019 02:45:18 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 46sDF90nQyzCrLV; Mon, 14 Oct 2019 11:45:17 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 46sDF86JSQz1xpF; Mon, 14 Oct 2019 11:45:16 +0200 (CEST) Received: from OPEXCAUBM41.corporate.adroot.infra.ftgroup ([fe80::857d:4f67:b0a7:10d7]) by OPEXCAUBM23.corporate.adroot.infra.ftgroup ([fe80::9108:27dc:3496:8db3%21]) with mapi id 14.03.0468.000; Mon, 14 Oct 2019 11:45:16 +0200 From: To: "quic@ietf.org" , "ietf-http-wg@w3.org" , "tsvwg@ietf.org" CC: "quic-chairs@ietf.org" , "httpbis-chairs@ietf.org" , "quic-ads@ietf.org" , "httpbis-ads@ietf.org" , "allison.mankin@gmail.com" , Gonzalo Camarillo , "statements@ietf.org" , "tsvwg-chairs@ietf.org" Subject: LS from 3GPP on QUIC network level troubleshooting capabilities Thread-Topic: LS from 3GPP on QUIC network level troubleshooting capabilities Thread-Index: AdWA0hpjWJ/tXLvVSCu8fqJq00l+9ABoMxcg Date: Mon, 14 Oct 2019 09:45:16 +0000 Message-ID: <5634_1571046317_5DA443AC_5634_110_18_6B7134B31289DC4FAF731D844122B36E3A242ED0@OPEXCAUBM41.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/mixed; boundary="_006_6B7134B31289DC4FAF731D844122B36E3A242ED0OPEXCAUBM41corp_" MIME-Version: 1.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: Mon, 14 Oct 2019 09:45:21 -0000 --_006_6B7134B31289DC4FAF731D844122B36E3A242ED0OPEXCAUBM41corp_ Content-Type: multipart/related; boundary="_005_6B7134B31289DC4FAF731D844122B36E3A242ED0OPEXCAUBM41corp_"; type="multipart/alternative" --_005_6B7134B31289DC4FAF731D844122B36E3A242ED0OPEXCAUBM41corp_ Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E3A242ED0OPEXCAUBM41corp_" --_000_6B7134B31289DC4FAF731D844122B36E3A242ED0OPEXCAUBM41corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Resending to include TSVWG chairs and ensure that the LS will be listed on = the IETF datatracker. Regards, Lionel De : MORAND Lionel TGI/OLN Envoy=E9 : samedi 12 octobre 2019 10:25 =C0 : 'quic@ietf.org'; 'ietf-http-wg@w3.org' Cc : 'quic-chairs@ietf.org'; 'httpbis-chairs@ietf.org'; 'quic-ads@ietf.org'= ; 'httpbis-ads@ietf.org'; 'allison.mankin@gmail.com'; Gonzalo Camarillo Objet : LS from 3GPP on QUIC network level troubleshooting capabilities Hi, Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4). This WG is actually studying the introduction of QUIC as transport protocol= instead of HTTP/2 in the 5G core network. The WG has some questions regarding the troubleshooting capabilities suppor= ted by QUIC compared to the ones available with TCP. The LS is officially addressed to the QUIC WG. However, it was highlighted = that httpbis WG could also be interested in. I will let you decide if only = QUIC or both are relevant in the discussion. Next CT4 WG meetings: 3GPP TSG CT4#95 11th - 15th November 2019 Reno, US 3GPP TSG CT4#96 24th - 28th February 2020 Sophia Antipol= is, FR It would be good to receive an official feedback at the latest for the Febr= uary meeting, where the study will be concluded (at least for this release). Regards, ________________________________ [http://www.orange.com/sirius/logos_mail/orange_logo.gif] Lionel Morand Chair of 3GPP TSG CT 3GPP Liaison Person to IETF Chair of IETF Dime and Radext WGs Core Network Senior Architect and Diameter expert Cell. +33 6 07 75 89 36 lionel.morand@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E3A242ED0OPEXCAUBM41corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Resendi= ng to include TSVWG chairs and ensure that the LS will be listed on the IET= F datatracker.

&n= bsp;

Regards= ,

&n= bsp;

Lionel<= o:p>

&n= bsp;

De : MORAND Lionel TGI/OLN
Envoy=E9 : samedi 12 octobre 2019 10:25
=C0 : 'quic@ietf.org'; 'ietf-http-wg@w3.org'
Cc : 'quic-chairs@ietf.org'; 'httpbis-chairs@ietf.org'; 'quic-a= ds@ietf.org'; 'httpbis-ads@ietf.org'; 'allison.mankin@gmail.com'; Gonzalo C= amarillo
Objet : LS from 3GPP on QUIC network level troubleshooting capa= bilities

 

Hi,

 

Please find enclosed a liaison = statement from the 3GPP CT WG 4 (CT4).

This WG is actually studying th= e introduction of QUIC as transport protocol instead of HTTP/2 in the 5G co= re network.

The WG has some questions regar= ding the troubleshooting capabilities supported by QUIC compared to the one= s available with TCP.

 

The LS is officially addressed = to the QUIC WG. However, it was highlighted that httpbis WG could also be i= nterested in. I will let you decide if only QUIC or both are relevant in th= e discussion.

 

Next CT4 WG meetings:

3GPP TSG CT4#95  &nbs= p;        11th – 15th November 201= 9       Reno, US

3GPP TSG CT4#96  &nbs= p;        24th – 28th February 202= 0          Sophia Antipolis, F= R

 

It would be good to receive an = official feedback at the latest for the February meeting, where the study w= ill be concluded (at least for this release).

 

Regards,

 

3D"==

Lion= el Morand
Chair of 3GPP TSG CT

3GPP Li= aison Person to IETF

Chair o= f IETF Dime and Radext WGs
Core Network Senior Architect and Diameter expert

Cell. +33 6 07 75 89 36
lionel.morand@orange.com

 

 

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E3A242ED0OPEXCAUBM41corp_-- --_005_6B7134B31289DC4FAF731D844122B36E3A242ED0OPEXCAUBM41corp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=998; creation-date="Mon, 14 Oct 2019 09:45:16 GMT"; modification-date="Mon, 14 Oct 2019 09:45:16 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAyADIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCxRRRX 52fpgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAWbXT7y+3fZbaSbZ97YOlEen3ksTypaytGh IdgvCkdc1s6PfWv9kpZy37WMkVyJy4H+sX0qXUdctbq0kSKWSNZb3fIi8Ex4xmu+OHo+zUnLX5HB LEV/aOCjpfz/AK1/4cw5NLv4ljaS0lUSHCEr1NJPpt9bKjTWksYkbapZep9K63+2tKhTy47tGQXK SIApyFA7nuaq2mtQNNIGdp5H1HzY0PUp6itJYSgnbn/Iyji8Q1fk/M52bStQt9vnWcybiFXK9Se1 S/2W8LbL5jZueV8xeCK7Bp4dEtIprmeWdDfM/wC8GCoPoPaub16+juIILeK6huER2ceXHt2596Vb C0qMW29e39foOji61aSilp31/r7zDf5XYD5gDgH1ooorzT0wooooAKMleQSCOhHaiinHcT2Hy3E9 w486aSTA43sTj86ZRRWlf+IzKh/DQUUUVkbH/9k= --_005_6B7134B31289DC4FAF731D844122B36E3A242ED0OPEXCAUBM41corp_-- --_006_6B7134B31289DC4FAF731D844122B36E3A242ED0OPEXCAUBM41corp_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="Liaison Statement on QUIC network level troubleshooting capabilities.docx" Content-Description: Liaison Statement on QUIC network level troubleshooting capabilities.docx Content-Disposition: attachment; filename="Liaison Statement on QUIC network level troubleshooting capabilities.docx"; size=28096; creation-date="Sat, 12 Oct 2019 08:21:04 GMT"; modification-date="Sat, 12 Oct 2019 08:21:04 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDuIuk+yQEAADcIAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lU+P0zAQxe9IfIfIV5S4ywEh1HQPyyJxgZUo4uzak9ba+I88093tt2eSNlEXunWh20ul1Jn3fh47 b6bXT64tHiChDb4WV9VEFOB1MNYva/Fz/qX8KAok5Y1qg4dabADF9eztm+l8EwELrvZYixVR/CQl 6hU4hVWI4HmlCckp4se0lFHpe7UE+X4y+SB18ASeSuo0xGz6GRq1bqm4feK/tyQJWhTFzfbFzqsW KsbWakVMKh+8+cOl3DlUXNm/gysb8R1jCHnQoVt52WBX951bk6yB4k4l+qYcY8jHkIw0Qa8d76E6 LnOAMzSN1TDWd2oxBQ2I3HPXVuOKU9YP/C9y+LVbQOLK1wcZpbMQSJsW8PUJtron2v+ytLptGtB8 4/KH4rDsOl9tLfZq825AxP0+xeT5d1DmTh53ylmER1j8uBjFnngWpAmBfKBLnP0onYUAby7EMChn ERrOqblatHDCzfvHSzFKZyGIwxdk/3t1Nkcvc8ySY+ouhYgc5uk/tj2kdVddcv5FSGRhzOtDeTc6 8iA4e3/QjRoD5kTvPvN1cF3k41dzgY9/T/xY25+B9POSN3F2N/4aQgPN4DAgyX7sz34DAAD//wMA UEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbv Bd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2Jtg R99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+R zBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9Swa bDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4B AAD//wMAUEsDBBQABgAIAAAAIQDsxNKv9QEAAMsHAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54 bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyVTW/bMAyG7wP2HwLd a9nJljZFne6wbgiwAUWbYcdBkWlbqC0JEts0+/VjEjhxPqxihS+2Rcl8H7yUxJvb17oavIDzyuiU JVHMBqClyZQuUvZr/u3iig08Cp2JymhI2Qo8u51+/HDzAJVA+smXyvoBZdE+ZSWivebcyxJq4SNj QdNMblwtkIau4FbIJ1EAH8bxmLt2DjY9yDmYZSlzs4z05ytLym/nNnmuJHw18rkGjWckeEmZXKX0 EyUVrgBMWS1UheZ69P3+/ocSyhv9BdCrNWyz6KfJSP/uFcFpUTF+HjQZdZDWSjrjTY6RNDXfQhJc Mubx5NACTgvW6H6W+UY8Za1gRG526f+nfHx5pO1xVYH/rbC8y3OQ2CI4mQpxXHbYcGYzvF0w0Jk2 SHtuV68mEkJIhh0MXaVIjrxoLF/XXGeQ7eWPZ0IYXRTvcmJbgz3IdhySTzpMeJe8fq4X4OhW2BPs QiGIcZ8QuTF4tB12oRBE0qsVSJcb7G3YDPnmmYQgPvfpxBIWj4BI9WgdjVYwBJLQHd/flZobjXOx qFqO7EIhik99QvgTL5pICGHSJ8KZ1rLuWJ7a4XK5jEaFtZsGmKPljxak58LJUr1QK5z88XS0wNNX dDUZ0YueF8kwjv4qS4ybTnXahPhBC57+AwAA//8DAFBLAwQUAAYACAAAACEAPhUHGJIUAADXegAA EQAAAHdvcmQvZG9jdW1lbnQueG1s7F3bcqPIln2fiPkHQuelOqIscxMIz7HOQUiqqYi6eGx39GMH lpBFGAEDyG730/zD/Eh/Q3/KfMmsnYCUiRCSdauqjlMPJRun8rJzX9a+ZPL3f/w2D6RnL0n9KLxu KW25JXnhOJr44eN16+f70UW3JaWZG07cIAq969arl7b+0fv3f/v7y9UkGi/mXphJ6CJMr17i8XVr lmXx1eVlOp55czdtz/1xEqXRNGuPo/llNJ36Y+/yJUoml6qsyOynOInGXppiPMcNn920VXQ3X+8t ir0QY02jZO5maTtKHi/nbvK0iC/Qe+xm/oMf+Nkr+paNspvourVIwqtiQhfLCdFXrvIJFR/lN5K1 VdSMm39zUFCAjXiZeAHmEIXpzI9Xy9i3NyxxVk7puWkRz/OgbPcSK/raeMsl77IHg8R9wVasOlzr roYYk/xL8yCnA+3valerPSpy02KKHaEulnPYZQrimOVM5q4fLrvZjzQ8cSERh/D3hyRaxMvpxP5h vX0Mn5Z9kWC+YWaywSSPX1r6pg7WRPdu5sZeS5qPrz4+hlHiPgSY0YuiS8SRrR6UxUM0eaXPWMLj q9hN3I+T65Zq2orTHaot9jTzfsvoqaF0lE7X0fD0CoppcnvdkmXNkpWhsnx0AzGVZdPs9Lv95cOB N3UXQbbe/IZ7xGZxk7CPu+w18DDKsxtct5xbJ4ImvHEfvdYl/TlzH9Lis2yT+I+zjMaLI5DMMjSL ml6u2qaxO4YAoYU7zTyaZN5Xko/4wDr22f9hdJNE0ZT9nP5ejqB2ix7ZN9BznH8zQQNGDGHlND2h 6w2d6nynmG1P+3BzI93ffbhw7qVfPujSZ8/LaN5/s3S2HLYoRqQdB959TYxYOdXeMsCuK3P0i00r YCyjKJ2RtWSZ41BT2Uw1bsy9N0u3LGFJxBXUmShMsm7r+qAzwNogYqUwmcW/5Yo5UahlqfLhkYUp WmSBH3qfnoOS0+skY5dNPplM3ERJFiXR7++luwCaIPTd/5BkU6A8pK2kz/6cA33jJZkd+I9hSYt0 EQODjRM/zqqSms2OPwOQsNAaDL1dkdaCxo4TL/WSZ6/Vk/7vf/5XUpTjj/wjrP3rOIsevEQCRt1F 7hRFcUxzpO8gd7qhGWZnKYoCC5V8xcmd2JwZMXmkD3WNmdTCMMSCERuGF1lW2K+4P2EK9iHKsmi+ ZDWo+QDG+uUq/f26RbMut59Z13EURDBb7iKLCk4su6kxh+PAcxPqgZlDXelo9B2m4MvhxCZdDdC8 2mSrUS14NRlFYZaiYzcd+4BPduK7wL4vVzM7TPnfx7DN+R/ZUA/5/07KPjlTy6wi0cGhXhkIUAVL WaqaDQrX0VTLVB1MYZvCFXfydseNZzq+MP/Fx14kKMV9y3L6g6FqyyNxObrjdEcD3SY6L8HYfssp etiJj+/9LGFsXM65SfNmPTQPvKud1RVYGbxAZGE2mV/aSDZ0awUphZ1irN37tPsw5MuW0rVSrndS FEqbOiHzPJQVMBYT8g36mcG3pi7Uvm5bw7yLnnPf1HT7aECITR3wY9WvWG9crgr20hqXO/W8yYM7 fmruJl9yuZn5ztkDtSt3m0iJvfivnz86jV1X/Ixduw69DI7pkxR4z14gZfD/4BilsyhiUHtXkvbG buyy0IbvpcKXSDaYjhCcKtNSFa1jV5wqXVVVuFCiU/XdyfEvRK6PmTc/iizXblvxMJfl0d2vtPk7 UFW2FbigDuJjp1f2a06kUWBlP5yAvQNvCh9XsboMSczc8BEmvXjATNwR7CXpRjI5pfqtZzW1b+uO NqB5cBZQ66q2IXNKlHTa6VntLlok4zfYjLz9cRitozsysQbvonf7sj6Sm1TPVi1ey8B8v1tUu7nf vLboe95g9MRwQT2bGPbIshS54plqfatrmQpCtQXZvk82uY+OwyJiqCo3IcJWfhzej5gp2kUbadrQ 6jBUxgmebg1ts68TID0nVnur4Dnj/Shaz1yKOlKGfY3YiCNFbdhjPx3ELGwOv7+1YmYuDMiwg2o2 OgNLszuE209OlhrPkGwUsSFzDFXVKKOaZdNDTVQtJUCYkvPXcPuhAxb+Qs4HWc+BK+qOM+kGYZso 3J2fD52GsG4xklovHh3LlruwAyIf6EOlq2n9c6PBgmrLCEA1vC4GCzazzYNABlp44R5v3P6s98Wd v8FDLPZJHEikN8dtLKaqqpquMnO/6cs9+2GCXKc7dyfSMJA+R27mzv3JDvreHJp619Epbn0aaS4I t5Nv/i138d4L2tKXxRzxuTcLXdNmbhCermY4RrcK+rWB1hkOdwAug45hmatkw2GhveOSHW4EHAds Owt7TZOL0S2JZdW4cEyeq9RiSWQUCzZnEcOyIxn/RqNcwBsHgCzVxwqGF0jbBlV3HAnlaDpMSL9n rzFi1WnsBcFd5iYsYH7KafbsyQSBcdH1hsqpndEwnOSLr1iiI5Ktt4XxjzjU5jCZlmu7Qm3cHp03 eu5SVba9YF5oyn8itxw+elTJsIPS1LuGrShWxe3YHRluld7vCBkyv79R4EorWa/p1K6mdm2tAhM6 ztDWB5Dncp/J0FmqNjRXPoaAtMp2nKYTmzMDUzziyFfCQnyiC6aS/uoI8s5DMMcNX6XEi4NX6dOd lL3B0yx07yEpkVLVl6hmo0ZmYYpPvusD6aaSE6E4xw9dpErfV7X0DKo5QZr3SUqufFRyJB8nqB9D gsZP0fwVMaocH5VswuGm8lHOTlyaq1ypkOb65HshG4zS3EW660i06JH5wVbQqotF/9PLUp/qzapK Z7leZg7FJXBxxnIJeyVvUDvD2eWNm1Tdior9OeJsBOxdMg8xUx4tZFLNYGpZ5WM4csc25bO4omWy 8kg5z4N2rhQw0rhlLHWdOupoiGCpOYScnAbac2r2HMsxZWOEiMw5lrMWjlFUsajkGCqh3L01iHlE kRIFvKe0pa8oEXGDQBp4eVUI6kpF2EfTWmcmuT+QZbtP+UuOmXR4IXqny/L7qxyuKg91pp3ZI85i mwNTs010wYKIzGJza91adlBjy0W//g11Alhl2d1BvAslKqgtblOJiEftG1POy+tYaZ1gMjgeYsHu fAtOMYN630qX/FSCiaYSaqr2c6Wp56ZF3TTqvBeTV8pNZzNPiqMMtd0osJAWKSoipWiap0nh9mQR XL6N9oZbmGgQZbvj9Ad8gGRv8RT2cqNJxCrZUpq2wBgpaneFbwv0ce6Zbk0E6aKwFpg7L2U8Bfv0 Oo0Z/1qqmaebTj03V1nwIYqe6EAAiwqA9wiBsqRciNDfdevXD1EfNQS5e162hb++bMl8qKRk2o18 7JhAMwWQLcKO+wK7Kh/3xEx0RV3UUv2Us4kST/qS1zA0yVDBnKfgww0b74cSicyff9zf/vmHarW7 lia9C9w0K4+ySO4zUDzVoUvPvsu0wDQKgogON0jkoFxVmWcJ5VeuCwvcNbkutVLZhQHWRDV3Otdl jYHoGECKEzgvLy9t7TGO2SmZaRZf3sXeOL10k/HMf/YuVetXVHqingQ/EfXwgf8vgJ/av/uxsNkw lUvasC2uEZBTbH3vp7Ywj4ow1NL+/JxYneJJKMHMw3eKJsaLJAFQQATjxfVZXVNpdnEeCuCCIQcC FFM/gXyyAz6EKoozZ4QrqjTkGWzUAWjonBE0bK0FOyGP9W5HjgTdhgALyo+zCKGhFEfsECWaSOMo HAeLiQddBgzHoJooH/UOgWEOu6NutVAAzrhiaqgq4kndJFFlO85LEJv/pb2EetJq1sgxNbOSHNJN 3VCszgpSEo4o3KeSittCpmLZzl+atNDqp1CZ9bhhK8xu2qfzTdO5X6+XPd/ov3xoVMgnVH/1mzbD eWSvcUrfx64l3rPvvXiTrS5n7XRPSNYeKyzDId1pduF72fTivxf++CJDJi2NceKp+bTc0BgZq9r/ XHGdcq6VEzcV0DccaN1BXlJ57JBNPfM18p2iGd2uUPFxtIBGDya/CRbV8lDx8HyqQnqJFkHjPGVH 6cv5MYTvYMPOTbVe4D8BsEUSgmbPPsNuwMFLP7Q81dC00ecnIOJ/zecW+OMIZViwaQknFJMNQuum gMu4ESIhbRxJ986N9G48bUvjwF2k3p9/WG2jrdHUGSDgYgjkuswp6jHxMsQP0p+a1nVKNbhLrF/V hygvkimqz8X6a8sbKozPoXjxL39pqFmP4juOogwUFgLmqIiSSUc1nFXpFqH4gpFFFO/IxtCkszZ5 xTVHWrE5Iy0nCrVplL5SFA9V4orVA41C2IfWVVv+2B11EIrifWc6pI/mhSrOehttf27ot3ZQXx+U f7kgTJ01alwOpU+YE051ETiWnErI5c6kexRIkB8MYUZ2LFyGFeiOD2niT6cewhDUGmdkcFqMEh3Z zM3ypAX+krzGODtKgYgl8pFmngtHuyrje824Wh22DCMfTIwNOg6rdicTRFwoXxOxhcXuaxC5k/fS y8wfz4gCM1xXgcgMRWKeXdzUU4ZmmhU8rp7B1RVpW7oHtbzfULtBUdMiECx9tT9L774iicQuu6kC pLWquMfEnW8u0zuESew1iFQ7+KaKvAOG3rAln8GKSJq5YMOfpDQKFuw2oGI3YIxgVVKc+c+N0twF NIA1YkxNleTYRzJUOU/iPDJBK/xGzk8YZdIDWlI4m/aaO0iY8zdYmu5WYn3hrGGIE4cp5Aa7h+we GMCduDHyqPnXi/wfWIZkxE2fdokjaaqt6JZRPellOH1nhOL+Uv39iGryAEbYpkAP6Jqp1o2pTaYg /TwimGLbpSgmZkNcdY4tXyQeu5jrwc/eS5T8mmwV0y3ltAcspJfGfoiZVNTsmqyyGZxNWEsliRqL 6IWMxgUuEJsRUH+ADYGQFXTMjQ+ZDQgdzE+GKzogx4ELoaJf8YeJR2AzSnNdDFSZP6QmkOnKsit2 gQMEVf9oq5FkZhHXI2G+GDR9nc89zG4MHqCl7CLUpowDeKZZKZDVENN0NGXl9f9LqAtwd7Atb8RL m9PKtaxAVZWw7nQhFbQvK5l9RUl89EIQkgd5NuOPMt+iWO9zmwF5G/swGvmdddIkYmYGF9FQUAgs NH7yMimIYEc4lZLuwlY4AGAruEkCVoGD1IYuK6bTWRUO7xEYr4HUstxRUY1MoK0WUvMXopSlRPgs SXaMyiT+VHbHYIVTy0PZ9HteV1CB9G+9w2Q3yN+gpw8akED5FmfhhEPXiw3jn/yA816Q/b5ZNZ9w PfX4McLNmwyjwZyTT+PFMEgubPprCqBW2JUCvBHGlN557ce2NIXIU3YQqDB4L3nZuP0TkF/24gEG uvQHSiEmG+0QUdEeKpZh8Y7i8QKZLMTS+YCJAACXPsRoEY6Z5/Lum+1B78to09inJsnGqNJW+3Ko DNczHkMyLmGfyWIMVvkyel8CG/KaycMsuI8qArGNDH3O6SQjCgMZb8LtgZeJxAKF3MQMNs46EiBa ed1UFg6oAg+z7Jb1V1ic3P9p45gBONpNXgmL/ef9/c2lKtHtjBQHoNmRc4swH/VMEEjyEAAgJ2pK cIzNmsobgdCQlvFcVPzgtzgOCnMnAZyhLz+EQwxvt/ChS684B4G7WDp12O3oJu7ZESxdbQhOqzsw JUbfbrngUdH8W5q1KiB9E/OVAKQMTtEnWwyjVHkyQNdwr2cXl2hup9/xz+7/RYrF1bZkM2Wa7hI0 NvsjzdbZ8S0Omyn2QEM0uVIPstdldRzHbi7P5xHTee+x4RKKubYtRLAOQbyJ4Xc8pnMfNVriikI4 8RTzzDBp302m8MQT2GCPHummZGFK9epDtjRrMKpePySPhrLRscUKnP3URxHW2pAW2Y2/LUuDerta egT0++EeQVW/fmu+tp37j1+/rFXVJgUFb0/MSFs9BHEejo076/qHA95yF8g9IqAr8Cy3JVtclVMo mm+kZojTEQW/biEMmdmp71aiEfUSj9rWc5CO367mKw11XO1p5FGFo8AgYhD9zEusJ3UzoesuqTqK hdyPL54AFJC+aCIcB5SPtlPIiWzM5zFR/s7I1Eigk0IKXqKW95fh+jiWpqIMFzlo7gM8N5w0K+7w hHqIWFwCflueRGza32MVwHAz/a4EoxKshe/MvOFluLaJNjq8T+MI1VU/CG2EiHUTXUAVC5dWHIzp t9OFIgwIF7DiLjpM6TVNi7uL9liqqp6Vt9+VOxhqQMRnoNA7j+0a0mzNavxstKFyCeikZe5kPTe6 xKyk6pWOPhJraPYLjXKs1IsjqMBGA3OC7eltjDqe1qJV9JsYVTsRROaIXS8gosFE85rYlKwP+rZj VK5Rro3tNZnY0vHgYnti8x/AudxAIEd3rKFSyR7XEmg/73unUNJBmlQM2tAyawvpjoKAmc//IIpD PXdqbWngZqzC7QuutxGZtSIy266rPyJ5yIfB0ZRNFu7EHn49qaTivUU7xT4VhIpsE0e3hWhzx5b7 eJHT8r4L9raprmUYxiqCJKytRqLF5kyii0ccD9dkn4U7rjqKzCJDYMOy6W4RJnZPJjlY5U3g5cWZ 4JWzZJ2PKB9CmrsMq9CLqiSw3t+sztm4rzoRFmGiCb39rTj7IYbyyhLUdpz0bUGHzQ7MWvDYhusc 8zcJnXnffnSafYHDTFecrr+CiFP/glI62Ncp2Y3b0CXL33ph9F76+U4QPrKWTLsJGT1lKA/svlJB TR27bw0HDlWPri4mt01N7xJ6yB/ly6nYMw41iS8AZDqWK9EoDHepOLkKn3/p2NryMW6fly8DzHWs IWzzN2E49Xwog+n5H11f0Nva1O559+1Hp9nIe0gWVGCiyqp8XtJxsrfUsXdRPMNNNTYqbOIo8NP3 0uhWmFWpb1PUudwIMYodFOkdvkR+PnevZvx4Ry8dfcGlnIol51WL+Nno6qwMAO+Axp1J7PWmUPSP n10aMotias6uib1ir21b/ZrfuLj6nfTu6re8rOe6ZeKGPnQ0xTuQ6O2oHZOdHXhc0IkTTDDPjOJ6 MXohG6FfzIG+wpynjF7ydfOYu1A5GVila/5uWdCnfCN17/8FAAAA//8DAFBLAwQUAAYACAAAACEA uxq5zuYBAADsBQAAEQAAAHdvcmQvZW5kbm90ZXMueG1srJRdb5swFIbvJ+0/IN8nNmvUrCikqsY6 5XZdf4BrTLCKfSzbhObfz+YrWUFRP8YFoGPOe57Xh+PN7YusogM3VoBKUbwkKOKKQS7UPkWPf+4X 31FkHVU5rUDxFB25Rbfbr182TcJVrsBxG3kJZZNGsxSVzukEY8tKLqldSsEMWCjckoHEUBSCcdyA yfE3EpP2TRtg3Fpf7wdVB2pRLyenaqC58rUKMJI6uwSzx5Ka51ovvLqmTjyJSrij1ybXgwykqDYq 6YEWI1BISTqg/jFkmImLmbpdZgaslly5tiI2vPIMoGwp9MnGR9W8xXJAOlwycZDV8F2j49Wk3mj5 LT3IDG18K06CE7mZzci7JFl1+xD6e+rqa8WYXDLTdyRIjAxvQfi35kAiqVCjzMe25nxz/UR85v/+ ZaDWI44Wn1PbqedRKwzmO8jIdTt559bsuwQmo/tQUs1RJFmy2ysw9KnyRE28isIfibanwyJqEnfU ftFyTQ11YJAPiTxFi7j9Tkc+LQlrOx9c362yn1eZn+YQdfzFtdF1d4VUf3Dlv1NEyM1NfB/Gvg9l vKB15c5WAoUJt7E03m5wG/N33b73R9ocMAPlhKrbCX94DU9m2El2F8drcvVf2WcpLvjwzoZjevsX AAD//wMAUEsDBBQABgAIAAAAIQAsnYyD6QEAAPIFAAASAAAAd29yZC9mb290bm90ZXMueG1srJTd bqMwEIXvV9p3QL5PMFE3aVFIVS3KKrfb3QdwwQSr2GPZJjRvv2MCJC0o6s/mgqCx58x3PIzX9y+y Cg7cWAEqIdGckoCrDHKh9gn5+2c7uyWBdUzlrALFE3Lkltxvvn9bN3EB4BQ4bgPUUDZudJaQ0jkd h6HNSi6ZnUuRGbBQuHkGMoSiEBkPGzB5uKARbd+0gYxbiwV/MnVglnRycqwGmiusVYCRzNk5mH0o mXmu9QzVNXPiSVTCHVGbLnsZSEhtVNwBzQYgnxKfgLq/PsOMXEzUPWWmkNWSK9dWDA2vkAGULYU+ 2/isGlose6TDNRMHWfX7Gh3djOoNlt/Tg9SwBltxFhzJTRxGfkqS1ekcfH/PXX2rGNFrZrqOeImB 4T0Ir2v2JJIJNch87mguDxdH4ivf9y8DtR5wtPia2k49D1p+Mj9ARpft5F1asx8SGI3uY8k0J4HM 4t1egWFPFRI10U3gv0iyubgtgiZ2R42rlmtmmANDMCTyhMyidqMOMC/2azsM/lisblO62OImjDr+ 4nx01f18Kl5d+e+EUHp3F2393HehlBesrtzFiscw/jGUDjfrsI3hU7fv/aU2iZyBckLV7ZA/vsWn E/R09fCwWKZ4qf5H+kmKa07QXG/Lbv4BAAD//wMAUEsDBBQABgAIAAAAIQBCL5damAcAANIgAAAV AAAAd29yZC90aGVtZS90aGVtZTEueG1s7FnNixvJFb8H8j80fZf11a2PwfKiT8/aM7axZIc91kil 7vJUd4mq0ozFYgjeUy6BwCbkkIW97SGELOzCLrnkjzHYJJs/Iq+qW91VUsmeGRwwYUYwdJd+79Wv 3nv13lPV3c9eJtS7wFwQlvb8+p2a7+F0zhYkjXr+s9mk0vE9IVG6QJSluOdvsPA/u/frX91FRzLG CfZAPhVHqOfHUq6OqlUxh2Ek7rAVTuG7JeMJkvDKo+qCo0vQm9Bqo1ZrVRNEUt9LUQJqHy+XZI69 mVLp39sqH1N4TaVQA3PKp0o1tiQ0dnFeVwixEUPKvQtEez7Ms2CXM/xS+h5FQsIXPb+m//zqvbtV dJQLUXlA1pCb6L9cLhdYnDf0nDw6KyYNgjBo9Qv9GkDlPm7cHrfGrUKfBqD5HFaacbF1thvDIMca oOzRoXvUHjXrFt7Q39zj3A/Vx8JrUKY/2MNPJkOwooXXoAwf7uHDQXcwsvVrUIZv7eHbtf4oaFv6 NSimJD3fQ9fCVnO4XW0BWTJ67IR3w2DSbuTKSxREQxFdaoolS+WhWEvQC8YnAFBAiiRJPblZ4SWa QxQPESVnnHgnJIoh8FYoZQKGa43apNaE/+oT6CftUXSEkSGteAETsTek+HhizslK9vwHoNU3IG9/ /vnN6x/fvP7pzVdfvXn993xurcqSO0ZpZMr98t0f/vPNb71///DtL1//MZt6Fy9M/Lu//e7dP/75 PvWw4tIUb//0/bsfv3/759//669fO7T3OToz4TOSYOE9wpfeU5bAAh388Rm/nsQsRsSU6KeRQClS szj0j2VsoR9tEEUO3ADbdnzOIdW4gPfXLyzC05ivJXFofBgnFvCUMTpg3GmFh2ouw8yzdRq5J+dr E/cUoQvX3EOUWl4er1eQY4lL5TDGFs0nFKUSRTjF0lPfsXOMHav7ghDLrqdkzplgS+l9QbwBIk6T zMiZFU2l0DFJwC8bF0Hwt2Wb0+fegFHXqkf4wkbC3kDUQX6GqWXG+2gtUeJSOUMJNQ1+gmTsIjnd 8LmJGwsJno4wZd54gYVwyTzmsF7D6Q8hzbjdfko3iY3kkpy7dJ4gxkzkiJ0PY5SsXNgpSWMT+7k4 hxBF3hMmXfBTZu8Q9Q5+QOlBdz8n2HL3h7PBM8iwJqUyQNQ3a+7w5X3MrPidbugSYVeq6fPESrF9 TpzRMVhHVmifYEzRJVpg7D373MFgwFaWzUvSD2LIKsfYFVgPkB2r6j3FAnol1dzs58kTIqyQneKI HeBzutlJPBuUJogf0vwIvG7afAylLnEFwGM6PzeBjwj0gBAvTqM8FqDDCO6DWp/EyCpg6l2443XD Lf9dZY/Bvnxh0bjCvgQZfG0ZSOymzHttM0PUmqAMmBmCLsOVbkHEcn8pooqrFls75Zb2pi3dAN2R 1fQkJP1gB7TT+4T/u94HOoy3f/nGsQ8+Tr/jVmwlq2t2OoeSyfFOf3MIt9vVDBlfkE+/qRmhdfoE Qx3Zz1i3Pc1tT+P/3/c0h/bzbSdzqN+47WR86DBuO5n8cOXjdDJl8wJ9jTrwyA569LFPcvDUZ0ko ncoNxSdCH/wI+D2zmMCgktMnnrg4BVzF8KjKHExg4SKOtIzHmfwNkfE0Ris4Har7SkkkctWR8FZM wKGRHnbqVni6Tk7ZIjvsrNfVwWZWWQWS5XgtLMbhoEpm6Fa7PMAr1Gu2kT5o3RJQstchYUxmk2g6 SLS3g8pI+lgXjOYgoVf2UVh0HSw6Sv3WVXssgFrhFfjB7cHP9J4fBiACQnAeB835Qvkpc/XWu9qZ H9PTh4xpRQA02NsIKD3dVVwPLk+tLgu1K3jaImGEm01CW0Y3eCKGn8F5dKrRq9C4rq+7pUstesoU ej4IrZJGu/M+Fjf1Ncjt5gaampmCpt5lz281QwiZOVr1/CUcGsNjsoLYEeo3F6IR3LzMJc82/E0y y4oLOUIizgyuk06WDRIiMfcoSXq+Wn7hBprqHKK51RuQED5Zcl1IK58aOXC67WS8XOK5NN1ujChL Z6+Q4bNc4fxWi98crCTZGtw9jReX3hld86cIQixs15UBF0TA3UE9s+aCwGVYkcjK+NspTHnaNW+j dAxl44iuYpRXFDOZZ3Cdygs6+q2wgfGWrxkMapgkL4RnkSqwplGtalpUjYzDwar7YSFlOSNpljXT yiqqarqzmDXDtgzs2PJmRd5gtTUx5DSzwmepezfldre5bqdPKKoEGLywn6PqXqEgGNTKySxqivF+ GlY5Ox+1a8d2gR+gdpUiYWT91lbtjt2KGuGcDgZvVPlBbjdqYWi57Su1pfWtuXmxzc5eQPIYQZe7 plJoV8LJLkfQEE11T5KlDdgiL2W+NeDJW3PS87+shf1g2AiHlVonHFeCZlCrdMJ+s9IPw2Z9HNZr o0HjFRQWGSf1MLuxn8AFBt1k9/Y9388v8DVg7xI/2V7W3JmzpMr0JX1Vr0Bf4tcbhy/xPQLZ58tW Y9JtdgetSrfZn1SC0aBT6Q5bg8qoNWyPJqNh2OlOXvnehQYH/eYwaI07lVZ9OKwErZpaR6dbaQeN Rj9o9zvjoP8q72fABFkeyY0Cdta87v0XAAD//wMAUEsDBBQABgAIAAAAIQBZYImCMgYAAKUSAAAR AAAAd29yZC9zZXR0aW5ncy54bWy0WEuT2zYMvnem/8HjczemJOrZOBk9k02zTSZOeuiNlmibE0nU UPQ6m19fUI91vItNM830ZAogQADfJ4jw85dfmnpxy1UvZLteWs/IcsHbUlai3a+Xnz4WV8Fy0WvW VqyWLV8v73i/fPni11+en6Keaw3b+gW4aPuoKdfLg9ZdtFr15YE3rH8mO96CcidVwzQ8qv2qYerz sbsqZdMxLbaiFvpuZRPiLSc3cr08qjaaXFw1olSylzttTCK524mSTz+zhfqRc0fLTJbHhrd6OHGl eA0xyLY/iK6fvTX/1RukeJid3H4vidumnvedLPK9nVO6J6mqe4sfCc8YdEqWvO8BoKYe022YaO/d WPSRo/tSP4NSr8azV8YVmFtkWJ0j7+tH9gjaI4pvxVYxNcIMBDBRNGV0vW+lYtsaSHWy6PIFMOqr lM3iFHVclQAS0JGS5cooIBm522imOaj7jtf1wM+y5gycnaK9Yg0wa70cJYONVqz8/IHfCkPtfhBV fMeOtf7IthstO7C7ZZCGb0+nHO66A28HSvwNZJ/11HbHKCrRdzW7ey2V+CpbzepMsRME8kqJKod3 6G62mPxN+//iSovy33fLP6X+1PMbpvai7QupvnH/TgkQDkm08v2xLfVxiPMPrlqIYFCUBwYpa642 HStBmEKMStZzUJXxn8J7p4AWY0I7KXUrNX+vTJHnJzAQ1Xp5ZV1umsRDbqvz7tGWt9XZ0fTwwM+l dHZzYTh2BRPLuNqMHQYctawBnozSqWvcyIob7I9KPKLik1Q2BgPowLixaEMjeniQBDQBVA5MqflG 39W8gGJuxFcet9WbY68F9KEBgJ+I4HsBAA3h5HfQPz/edbzgTB8Btv/psIEZRS26G6GUVNdtBW/f zx4GFDnDCZ+Xqje4msUHYN0MAyGh7eR+OtbCaM8aQlz7CU3spkmG2qRWQnJUk1teWKCagubUwTSW bRdFjGocLwhsVOPSIsa9eSRI0AiszE7wCOzAoxZ6DljEIZqpndHY8bHYHOJmCVprx7Ydip7jhMTK p1ZwiY8Te8XcOh9ocsd30XOoTXIaYLFRCKBAq0M9x/OnFnx5Dg1c6qE1oFBPHDmaOraHx5Y6hYui TVOapWhscH6IR+0GNCFopm5I7RzVeMS3AzRTzyJPePN8mmW4twKM0Ki9wrIDVONblluEGD6g8fKp aV6i4NtekaKM9x3qh9PH8IGNa6U5ipzv0pQ8YeO5OAq+D0xA+4Hvu5aNvgugSYIEzTSx8vni8SBq iCz1UJvMd2L8nNwrPJRVgWOFOHsDF5oiGlsQeE6Bvo1B6HkeimmQEFqgFQ0SGgSoJiTUJ2gET/fr MCB+jGIahlYBN/zhg3tZ0TBx3RStTphbEB1qU3g5/pbEFokDFIUY+rWF8joGkgYod+LMDvA3OM4B OdxbAc7QdyFxrBivdUpcx0Y7Ukq83Ee7cuq7sY/yII3hy4AiB5oiQdHOXC/00Xyy0HN8tKJZ7kBj xvDJiWWHqE1OaIyjnROX4sjlNvEI2ndy+Jj4aKZ55gQZminQkIaoDXzK0gyNugCKJkNXhjuNoS/c ZJrIjHvm7juuzPVw0YxXy5Q1WyXY4sYMhMD5Jtqqz4loZ/2Ww0DMv9VsjttZeXU1KvqG1XUB9/lZ MaTTRGamyPhucFuPo8KDHQqVwujz5t6Xma64eqXksRtPOynWjde+2ZlFxxbYRKLVb0Uzy/vjdjNb tTDUfaM6ttW7W2Ucrs7lOUUa/gsYrs9vWbufb3e8vXo1wVDWamP+L4DBp+tgbIEt2721XtZif9CW ufJqeKrgf4PhYbu3J5096ODJ6IYHVprMYPe0MBvGJeyaFmeZM8ucswym4nEfPcvcWeaeZd4sg/8t ThEMjlzBSPoZBpF5aeQ7WdfyxKvXs3C9fCQy9TpFwxX8ui3rY8WBDZUs++vWDLzj4NofWMcBdjO9 AvtkNAimcbZf3Eb8C4zLvBIa/q3pRNWwLzA9E3voudNumFzlUV/sNZ7M5u5CuqiYZmA+IHlhDMjC +H0ZC8TOSwFs3dw12/O0+duYVy16veEdDKZaKqjIMHv9PugsClmX13Dhh9Ugd62MupQOzdgcNP2/ 9OIfAAAA//8DAFBLAwQUAAYACAAAACEAZb4HjDwQAAAscgAAGgAAAHdvcmQvc3R5bGVzV2l0aEVm ZmVjdHMueG1s1F3rcts2Fv6/M/sOHP2OY1GSdfHU8dhK3HjGddzImf1NUbTFmiJVXqykb9Tn6Iv1 4OBC8AIREClvu51Z2ySADziX7xyAAPLT5fdNYL16ceJH4UXPft/vWV7oRis/fL7ofXu8OZn2rCR1 wpUTRKF30fvhJb3LD//9z0+78yT9EXiJBQ2Eyflu61701mm6PT89Tdy1t3GS9xvfjaMkekrfu9Hm NHp68l3vdBfFq9NB3+7jb9s4cr0kAbS5E746SY81t6m2Fm29ELCeonjjpMn7KH4+3TjxS7Y9gda3 Tuov/cBPf0Db/TFvJrroZXF4zjp0IjpEqpzTDrEfvEZcGUUNLq35MXKzjRemiHgaewH0IQqTtb/N h3FoazDENe/S675BvG4CXm63tUcVPDFkHR18jJ0dqCJvsNJcjTBWtNImoHIg+s21Wm7R7u8bDNMI aUL0QacLRUzek43jh6KZw0QjCxf8oY19/xxH2VZ0Z+u3a+02fBFtEbc06Fl/jJ4nDy0xaqDiuou1 s/V61sY9v30Oo9hZBtCjnT2yiEX2PgBVrCL3o/fkZEGakD/jh5j9yf7CHzdRmCbW7txJXB/E8+hv gF3uvZ31Ndo4oMndueck6VXiO7Uv11dhUl/NhfGVWzslkIETPkOzr05w0fPCk5+viyDi0dJfQctO fLK46kHFUxwB/ymNZCvGRUuVhg0EAXSxoLQJQvGe7iL3xVstUnhx0QPqxYffbh9iP4qByy56sxl7 uPA2/md/tfIIS/OC4dpfef9be+G3xFvlz3+9QY5kLbpRFqYXvcF4gqoIktWn7663JVwFeKGzAeh7 UgGIBEhdwsEOZX7eG/qghIoPf+eQNhEQSLYOZe05JK5Y2P+9QDjqrDXQoHFEHQEN3wpo9FZAZ28F BLG6weo60tHkrYAgY3qbEaFgjulHaeRSZ5VJYDjb4+KkBnqdUQ10H6Ma6AdGNdCgjWqgZRrVQBMz qoG2YlSDeoNEynv1QSjXi4lByiD9PRp0HQwN5SpDlJ8WzT/6aQDpQIMP2C2DCQu71oMTO8+xs11b JH8od3tfOFpky1SvqxiwDg9HizSOSFbdIJEBdZyDo96nzXbtJD5MPpqAWor+kWR41s+xD1l6A9SZ grzVScJD4LjeOgrAbK1H7zvVaEUm6vr3kbXYOi5OYxo611Ktd/7zOrUg+SVJTaMkxgqhq0dC27/z E5TBXp4fK4bS1LiWDscKu1Q3/ou38rMNF41GvjemEcBAzSUI7OJ+EY2IiqpO3DgKogCdIdAAYz4E bF+j/zQcmbdPdKzTfxq8Dmxfo/801B3YfnOCPTZmmo+wemRpudfE2HfnURDFT1nAfaCRHibGHiwg 9IZg7MSifS2SmBh7cIE+rSvXhbmxjp0a6yLnUQMUY3VQFHQ2/bEYK6VEe7bBiIwVVMIaGGC141oD IGPS/eq9+mSt2zQYIEuLXLPRnYcKCUAI0sqhf82itDmHHig4TxflNoQFqcSz9NCGCs/TRWP2ROOd gY7bBT4DoHYR0ACoXSg0AFLYhzrnETFRH6R9cDTAMqZlEcXQ7LSZeWLMzALILAR0FDc18i+F96pt oRo3NVCMFVSNmxooxtopxTIRNzWwOoubGliKqKHWkcypJoMyjpsykMgENEbUDXlrAHVD3hpA3ZC3 BlB78m4G6Y68NbCMuUFwqkzeGkBYxGSqL4Bk8tYAMuYGynZszYjHPWxl/+JFB+StgWKsoCp5a6AY a0dF3hpYWMTEEkpYguo0sLohbw2gbshbA6gb8tYA6oa8NYC6IW8NoPbk3QzSHXlrYBlzg+BUmbw1 gIzpQQDJ5K0BhEVMuKGWvNHrj07eGijGCqqStwaKsXZKhCqSVA0sYwWVsAR5a2BhERNjYFho3CaD 6oa8NUbUDXlrAHVD3hpA3ZC3BlB78m4G6Y68NbCMuUFwqkzeGkDG9CCAZPLWADLmhlryRmc8Onlr oBgrqEreGijG2ikRquA5DSxjBZWwBHlrYKG9tCZvDSAsciiQyYi6IW+NEXVD3hpA3ZC3BlB78m4G 6Y68NbCMuUFwqkzeGkDG9CCAZPLWADLmhlryRh85OnlroBgrqEreGijG2ikRqiBvDSxjBZWwBNVp YHVD3hpAaJityVsDCIscAIReZKKmbshbY0TdkLcGUHvybgbpjrw1sIy5QXCqTN4aQMb0IIBk8tYA MuYGss8W9otqb0+1FUagu8+A72rQBhwolKQLyAb41XvyYjg86TXvDmkJyEdogKgwD90hXkfRi6W3 sXuoMBBtKH8Z+BFu6f6Bu3Tkve6TPTvXH7/Mrc/0iFGlHppUcecNnOKSD2SRU0t4ohX6mf7YwqGo Ld9ZTlqDw1rk+Bo7ZIUFb+HIFTs4RSqTk1RQEA+Tscf43Zah4u9w8E06d5YfZ4OTZt8WZGjS0TLE aOiV6AeoJvZsPOAl9yM/cYXwTuA7CRyqY738bL9bsw3yS3i++kIOhFX6H8Im7Lrn8rjg4Bvp6Yvn be+hOIIldBc2VHWeUg/O1Q5G7NyBH67gaeA9EXHOphiXY7KZGspMMR1Yw8E82FTNXmNzUZYGfujd vQa8M9gaCIyBM9nGpWOEV7FPT7ax84H0b2xySfv5B29wMGqtgoFSBQNquWUVDN6t2ZsjqIAKWhKt QpJoBP8wSQ6VkhzWS3L4bs3eHEGSVetDrVVklnRpTPTsbJ0/o6GCYxX9ec0eH2H8qbPEk7vwk3sL 8V/CjNsIjtcOxjPuPLyo7OWT/pQqrSpH1FlFjoZeDPXR/eGnOW2eKS3trNbS1uzxEcT8m8ulS3ZD w8EthcNyWf+TqG+sFOO4Xozs8RHEWLUyVFlbK9udu2RbP1fRvE/+o2Pr1O/pQe06v2fpzxFExr22 ewdHNXcs+j787+aGiL6V50+VJsvo6giCrqRF9mBPWqSVCKFVtJewZMM8uB1OqjOlaNnx4X+HaNEO OhUtp+4G0bprmH24JAQA3SgmHw9RADfqwDRlBXOTtCJwxQlZDCn5aWDOZmwikK+n0nKF81rU3xQR FpiDHvtV9PaRvHeyvTMmCwtRSq12ES7DwE419REmcMuAzkjgl1ucbezYbRh0arf67tCm4P3cC4Jf nJjMX9JoC+JQFCX5Dn1rQzYDv5WaWkZpGm3U9TENVzcARiZ3hv5JBgG/KSQeZpulF7PDpwqpX2Vu FnoBnGH0KgYCR2XJIlNbcas7WJhBi7nqp/AkrekNO6qOGt5DDiXlswwIjK+cn7IMCiSOGerIPmPT AygLD3GeizohusQi0yHcHEVtnLYHI8P2TUf44HtwU8vWea7K/CmCgz0sr/uXj3Iebcj1V44fV4fp hGEEt9qQO2ZScoi7SaswtX/hSpHanTtMVNpaL8xK7JHNArmk80KJ0XjSUOJsdoaUDe6Z202hDZjc 8DBBzQYcVrn2kWf4wBdrZm0HpvFgliZRRDjgfbaJI4V9EqO1KLHUKq0Uc6p8rOkrbpYAWy7IXUjl NbXr6joWPDKxoGt7DuGTVqlZppJnpmdwLRIYnsizyN8I9baKKjDlHtn0+9fR6gfei0ACljxH6Pct 8a5JWMzgqmZKc1HOe8y+4If+olo5i6zcsnXQQucekTiVuHZ5SVXIRrnzV9FuDpeDxFHD2mHpPjDo KZhG+1XaPZ2vrhdeXl7CDTp1CmQpi7weyx6xgUrLr200uERwSY+HpKyCbCC1+j3zVh7cuKgTLWLx EYX2QlxHhn8i3QG9ilU2mwfsBiLU9a+Pn+a3i9sv9xWbEi/qNCMv9zcZHThttqHJKfxyS1bCMRVB hgO1ibe5cy49uPSS0CR4JxRny+li3tglU+3OqfYLCx35bBsu0OD9JXd2Qr4P4oBOdyT9q/ljnezZ Y03JS15Av0jcwWeDBCsrmUASe0EpfHFSKGV7vYKUnM8UUHFMECCX5I+LHv2ACuGfhzWU5EXv5oZI kfo1m0k01MYPITW1xTyjoT5+Y6ypz+chDdXr4QmvcBHUpNwwwcMJK6bTQ7jyBsWuSpzs6YgLuJo4 caOn9+Ywm+ctyhEcWwHpixA+mzH+PLpj5ErtzgdWcM1uhX3wYZ39y67BmEfYasGSUSQyvQg14py3 wRhkW+r3py0sWa59iCXL9Q+w5Lz6fksG2YlpIbNjqMCtVDa/IXzVlK2P/A2aIs1Tlmcxq8SoXIZQ riPyvI/Sj3W2A88tfFFnP7lh7bUengEI2+KSkFxbFpltD/iKOy25XxwH+5HIMuZRvE1WHplrVr2H pMX0LrE6EcjBuzgNzZtUzUOZbvXSY7ASchOt9AG6YBPthUCmBZBpLbMA7uWucMi1EwQRzMdx8mAi iEKzQhJtlufgtnGR9/T7s8Hw02ROQ4VCoI/OGu4ARj9jt/yKB3i5L/0LB1XODUlYnostD7r5YmH5 dU/+XpFNeVaGBayVZ1GtWEJ+sqkVWqGC0Bbv/1uWlfkd3KIMimjmtYKIhSPf+V64hu03cVrryp/J KyK6JikVt1+iZTRKquCO3Sa9Yny4Uafim3RnVZNTyjM/FWth+8LIqlYE124ijLwsUhRM/2b0ieZl IoRVpyJkLw/w2b60bNLHrEGkZTZ5gNjVz7P1IfNQWl1SQc5p0v/ixWJf04Av1DXE3IJt7nF/OewQ oZe9H98T70drrnd+uQ0qn9Jip1o9Cras3/KkHX6ERx+08qEvOrEeUC858VolNlHgmFJDU2LrQkeV h3Dcsg3hi3oZ4Cs6erWnH24++XjLt+eThJcGYmFrpdSmyQfbGZnucs4iymLYj1sWKXtMaUK981Et OZYs57y4jwjZDsecCMkDwK7kxG34rjne6sqMrJTCl+eK0PjzOqmhIbLPJI1Sq5k7FL6nDAZjTtO8 qDzhYiv0aukVLLFDuXydR/AP5TzUfdWbf7XwJdxGDd/8UEJFMdz0x6MZJkY1QbW4oKceGPuHMYTL FVwQQdsQVcE+RL7yENN/cOfz4y93FZMgD60HWLLFf28C5h506Hu+a8pZr9z0noyFf/VvzOgmk7Pr aVHG3H7gJ1AWLnIUTG1G5wPqb3v2dIgrJ+oSg8kIrVVdYjgeM9dQdWN0Nm1YKjsbzXClW40yHtkN PZ0MafqjbmM6GDX0FATW0FO73580dNXuiyU6lURse8a3jCqLDKC71OCURYYTvudcWWQ0PuPfEKAM bCJo9L+Fv1lkpX+PJn/GnDJ/QOiI/YU+mk9QefflCSp/1vAp6o/1yfyeBZGOctmyO5aD5kP815/U 0f/600LPF05bcvi6b8Qqx6cKrGYv3OuLNCq7uCL5zQWfpy/5s3+tdtgn7bJSrm1rLj51yzLmX8yL 8rOH4+mU0YRCfm8aXb4sf/PSVab5bTDJoDhkJnUZiLRphL6XJ8uVl7Kkqn0Qdq02y9IUrTk2nY3m /PMPSx4p2xTI2C18P6ndvVIsUrt9pVikdv9KsYjOBhbG+vknFYyjoIlGulTPHcpvqF7p/+PkvTl5 051t1iu57E1YylpllmSQ+cyrxHKSUQmD2W9XTVxXMqqi604kCzJ33aUkVbOpF+gAk8Hkw98CAAAA //8DAFBLAwQUAAYACAAAACEARJBc0rQPAAA7bwAADwAAAHdvcmQvc3R5bGVzLnhtbNRd63LbNhb+ vzP7Dhz9bmpRknXx1PXESrzxjOu4kTP7m6Jgiw1FqiQVJ32jPkdfbA8OLgIvEACR8rbbmbVNAviA c/nOAQggP11928TeV5LlUZpc9vwf+z2PJGG6ipLny97nx5s3056XF0GyCuI0IZe97yTvXf3873/9 9HKRF99jknvQQJJfbMLL3roothdnZ3m4Jpsg/zHdkgRePqXZJijgz+z5bBNkX3bbN2G62QZFtIzi qPh+Nuj3xz3eTGbTSvr0FIXkXRruNiQpsP5ZRmJoMU3ydbTNRWsvNq29pNlqm6UhyXMY9CZm7W2C KJHN+KNaQ5sozNI8fSp+hMGcsR6d0aagut/H3zZxz9uEF7fPSZoFyxiE9+KPej+D5FZp+I48Bbu4 yOmf2UPG/+R/4Y+bNCly7+UiyMMouuw9RhsQ9j158T6lmwD69nJBgrx4m0dB48v12yRvrhbm9Qpn FDIOkmdo9msQX/ZI8uY/12UQ+WgZraDlIHuzeNuDimc4AvFTGclWjouVqgwbFAbqWzArAqGQp7s0 /EJWiwJeXPbAEvHh59uHLEozsJTL3mzGHy7IJvoQrVaEGq0omKyjFfnvmiSfc7LaP//1Bi2Qtxim u6S47A3GE1RFnK/efwvJltoO4CXBBqDvaQXQHti4goMd2kX73rAHFVR8+LuA9KmAQLJNKGsSUDfz sP8HgXDUu9ZAA+OIOgIavhbQ6LWAzl8LCJjQYHUd6WjyWkAQQF5nRCiYU/pRkYbMWVUSGM4OuDit gV7nVAPdx6kG+oFTDTRopxpomU410MScaqCtONVg3qCQ8kF9UMolGTVIFaR/QINhgKGhWmWI8rOi +ceoiInRB/yWwYSHXe8hyILnLNiuPZo/VLt9KBwtdsvCrqsYsI4PR4siS5Nno0QGzHGOjnrvN9t1 kEeQDBroZ9BS9I80ufP+k0UrI9S5hrz1ScJDHIRkncZgtt4j+cY0WpOJvv596i22QQh5hrFzLdV6 Fz2vC2+xxqTGCDbWCF0/Etb+XZSjDA7y/FgzFFPjVjoca+xS3/gvZBXtNkI0FvnemEUABzVXILCL h0U0oiqqO7FxFFQBNkNgAcZ9CNi+Rf9ZOHJvn+rYpv8seB3ZvkX/Wag7sn1zgj12Zpp3MDf3rNxr 4uy78zROs6ddLHzASA8TZw+WEHZDcHZi2b4VSUycPbhEn97bMIS5sY2dOutiz6MOKM7qYCjobPZj cVZKhfZ8hxE5K6iCNXDAase1DkDOpPuJfI3o0p9rMECWlrmm0Z2HGglACLLKoX/dpYU5hx5oOM8W 5TaBBamceHZoQ43n2aJxe2LxzkHH7QKfA1C7COgA1C4UOgBp7EOf88iYaA/SPjg6YDnTsoxiaHbW zDxxZmYJ5BYCOoqbFvmXxnv1tlCPmxYozgqqx00LFGftVGKZjJsWWJ3FTQssTdTQ60jlVJdBOcdN FUhmAhYj6oa8LYC6IW8LoG7I2wKoPXmbQbojbwssZ26QnKqStwUQFnGZ6ksglbwtgJy5gbEdXzMS cQ9bObx40QF5W6A4K6hO3hYoztrRkbcFFhZxsYQKlqQ6C6xuyNsCqBvytgDqhrwtgLohbwugbsjb Aqg9eZtBuiNvCyxnbpCcqpK3BZAzPUgglbwtgLCICzc0kjd6/cnJ2wLFWUF18rZAcdZOhVBlkmqB 5aygCpYkbwssLOJiDBwLjdtlUN2Qt8WIuiFvC6BuyNsCqBvytgBqT95mkO7I2wLLmRskp6rkbQHk TA8SSCVvCyBnbmgkb3TGk5O3BYqzgurkbYHirJ0KoUqes8ByVlAFS5K3BRbaS2vytgDCIscCuYyo G/K2GFE35G0B1A15WwC1J28zSHfkbYHlzA2SU1XytgBypgcJpJK3BZAzNzSSN/rIycnbAsVZQXXy tkBx1k6FUCV5W2A5K6iCJanOAqsb8rYAQsNsTd4WQFjkCCD0Ihc1dUPeFiPqhrwtgNqTtxmkO/K2 wHLmBsmpKnlbADnTgwRSydsCyJkb6D5b2C9qvT3V1xiB7T4DsavBGnCgUZItIB/gJ/JEMjhLRsy7 Q1oCihE6IGrMw3aI12n6xbPb2D3UGIg1VLSMoxS3dH/HXTrqXvfJgZ3rjx/n3gd2xKhWD02qvPMG TnGpB7LoqSU84Af9LL5v4VDUVuwsp63BYS16fI0fssKCt3Dkih+copXpSSooiIfJ+GP8bstR8Xc4 +KacO9sfZ4OTZp8XdGjK0TLEMPRK9gNUkxEfD3ip/difuEL4II6CHA7V8V5+8H9Y8w3yS3i++kgP hNX6n8Am7Kbn6rjg4Bvt6RdCtvdQHMFytgsbqgZPBYFzjoMRP3cQJSt4GpMnKs7ZFONyRjdTQ5kp pgNrOJiHBzLxNTaX7oo4Ssjd11h0BlsDgXFwLtuscozwbRaxk238fCD7G5tcsn7+IRocjFqrYKBV wYBZblUFgx/W/M0JVMAErYhWI0k0gr+ZJIdaSQ6bJTn8Yc3fnECSdetDrdVklndpTOzsbJM/o6GC Y5X9ec0fn2D8RbDEk7vwU3gL9V/KjNsUjtcOxjPhPKKo6uWT/pQprS5H1FlNjo5eDPXR/eGnO22e ay3tvNHS1vzxCcT8WyikS3dDw8EtjcMKWf+dqG+sFeO4WYz88QnEWLcyVFlbK3u5COm2fqGieZ/+ x8bWqd+zg9pNfs/TnxOITHht9w6Oau5Y9H34380NFX0rz59qTZbT1QkEXUuLfDiOh26uEqZIi6wS IbSK9hJWbFgEt+NJdaYVLT8+/M8QLdpBp6IV1G0QbbiG2UdIQwDQjWby8ZDGcC0ITFNWMDcpagLX nJBFW9ufBhZsxicC+/VUVq50Xov5mybCAnOwY7+a3j7S98Hu4IzJw0LMHepdhMswsFOmPsIEbhmz GQn8couzDbgZBffQsand6lvAmoL3cxLHvwQZnb8U6RbEoSlK8x321odsBn6rNLVMiyLd6OtjGq5v AIxM7Qz7kw4CftNIPNltliTjJ101Un+7C3cJieEMI6kZCByVpYtMbcWt72BpBi3nqu+TN0VDb/hR ddTwAXKoKJ9nQGB81fyUZ1AgccxQR/45nx5AWXiI81zUCdUlFpkO4V4eZuOsPRgZtu86woeIwE0t 2+C5LvOnFA728LzuHz7Kebqh1xEFUVYfZpAkKdxqQ++YKeghbpNWYWr/RShFaXcecFFZa700K/FH Pg/kis5LJUbjiaHE+ewcKRvcc283pTZgciPCBDMbcFjt2sc+wwe+WHNrOzKNB7N0iSLSAe93myzV 2Cc1Wo8RS6PSKjGnzseWvhLucmDLBb0Lqbqmdl1fx4JHLhZ07c8hfLIqDctUaqJ1DtcigeHJPIv+ jVCvq6gSUx6QTb9/na6+470INGCpc4R+35PvTMLiBlc3U5aLCt7j9gU/7BfVqllk7ZatoxY6D4gk qMW1qyumQj7Kl2iVvszhcpAsNawdVu4Dg56CabRfpT3Q+fp64dXVFdyg06RAnrKo67H8ER+osvza RoNLBFf0eEzKKskGUqvfd2RF4NY4m2iRyY8orBfyOjL8E+kO6FWusvkiYBuI0Na/3r2f3y5uP97X bEq+aNKMutxvMjpw2t2GJafwyy1dCcdUBBkO1Cbf7p1zSeBKQUqT7OIWvpwu541dMtXLBdN+aaFj P9uGCzREf+ndgZDvgzig0x1J/+38sUn2/LGl5BUvYF8k7uCzQY6VtUygiL2kFLE4KZWyvV5BSi5m Cqg4LgiQS/7HZY99QIXwL8IaSvKyd3NDpcj8ms8kDLXxQ0hDbTnPMNTHb4wN9cU8xFC9GZ7yihBB Q8oNEzycsGI6PYQrb1DsusTJn46EgOuJkzB6dm8Ot3nRohrBsRWQvgzhsxnnz5M7xl6p3fnACm4d rbEPPmyyf9U1OPNIWy1ZMopEpRepRpzzGoxBtaV+f9rCktXax1iyWv8IS95XP2zJIDs5LeR2DBWE larmN4Svmqr10b9BU7R5xvI8ZlUYVcgQynVEnvdp8a7JduC5hy+a7GdvWAetR2QA0raEJBTXVkXm +wOx4s5KHhbH0X4ks4x5mm3zFaFzzbr30LSY3SXWJAI1eJenofsmdfNQrlu79BishN5Eq3yALtlE eyHQaQFkWstdDNcU1zjkOojjFObjOHlwEUSpWSmJNstzcPmyzHv6/dlg+H4yZ6FCI9DHYA13AKOf 8Vt+5QO83Jf9hYOq5oY0LM/llgfbfLG0/Hogf6/JpjorwwLeinhMK56Un2pqpVaYIKzF+/+WZW1+ B7cogyLMvFYSsXTku4gka9h+kxWNrvyBvqKiM0mpvP0SLcMoqZI7dpv0yvHhRp2ab7KdVSanVGd+ OtbC9qWR1a0Irt1EGHVZpCyY/s3oPcvLZAirT0XoXh7gs0Np2aSPWYNMy3z6ALHrn2ebQ+axtLpk gpyzpP8LyeS+poFYqDPE3JJtHnB/NexQoVe9H99T70drbnZ+tQ0mn8pip149GrZs3vJkHX6kRx+1 8mEvOrke0Cw5+VonNlnglFJDU+LrQieVh3Tcqg3hi2YZ4Cs2er2nH28++/E23MVf2k5Xty2TD7Yz MtvlnEW6y2A/blWk/DGjCf3OR73keLK858VDRMh3OO6JkD4A7FpO3IbvzPHWVmZ0pRS+PNeEJp43 SQ0NkX8mMUqtYe5Q+p4yGIwFTYui6oSLr9DrpVdKsjuUy6d5Cv9uyEPTV735Jw9fwm3U8M0PJVQW w01/PJphYtQQVMsLevqB8X8Yo5neEbQNUZXsQ+YrDxn750w+PP5yVzMJ+tB7gCVb/PcmYO7Bhn7g u6aa9apNH8hYxFd/Y0Y3mZxfT8syFvYDP4GicJGjZGozNh/Qf9vzp0NcOdGXGExGaK36EsPxmLuG rhuj86lhqex8NMOVbj3KeOQbejoZsvRH38Z0MDL0FARm6Knf708MXfX7colOJxHfn4kto9oiA+gu MzhtkeFE7DnXFhmNz8U3BCgDmwiM/reINotd5d+j2T/jcXH/gNIR/wt9dD9BFd1XJ6jimeFT1B/r N/N7HkQ6ymWr7lgNmg/ZX38yR//rTw89XzptxeGbvhHrHJ8psJ69CK8v06jq4prkdy/4ffqyf/aP 1Q7/pF1VyrXvzeWnblXG4ot5WX7+cDydcprQyO9Vo8vH5W+kWO0svw3mOygOmUlTBqJsGmHv1cly 7aUqqXofpF3rzbIyRTPHpvPRXHz+4ckjY5sSGYel7yeNu1fKRRq3r5SLNO5fKRex2cDCWX//SQXj KGjCSJf6uUP1DdMr+3+cvJuTN9vZZrOSq96EpbzVzlMMcj/zqrCcYlTSYA7blYnrKkZVdt2JYkHu rrtUpOo29QIdYDKY//w/AAAA//8DAFBLAwQUAAYACAAAACEAWEFW1lsCAADtBQAAEAAIAWRvY1By b3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsVFFP2zAQfp+0 /2DlHZyGrmor1wzBNiYxqJQAz15yba05tmWbjvLrd07aNB0DsWl5Ot+dvnz+7vOx08dakTU4L42e JYPjNCGgS1NJvZwlt8Xno3FCfBC6EspomCUb8Mkpf/+OzZ2x4IIETxBC+1myCsFOKfXlCmrhj7Gs sbIwrhYBj25JzWIhS7gw5UMNOtAsTUcUHgPoCqoj2wEmLeJ0Hf4VtDJl5Ofvio1FwpwVUFslAvDr SEcx2iVYYYJQhayBZ5juDmwuluD5gNE2YPfGVZ4PBx8YbUN2vhJOlAHF41k2PmG0l2Bn1ipZioC6 8m+ydMabRSA3jQIkAjDab2GoSg7lg5Nhw1NG+0d2JXWkMmG0jZCbE0sn7MpzpNM7sbwUCs7x7nwh lAdG9wl2CSLOdS4kMmbrMF1DGYwjXj7hZIcJ+S48RMVmyVo4KXRA5WJbe2hiZX1wvJDBITbW2nMT 9tv6sRxGFbEXg1cbO2z1H7DjD9v74U8Pb47sFfibBeoW/iBE1hei4dTK0NK7yknYmomgt8k1zn2v Qxe93nZA7jc656a2Qm/4pyL/SnJjV1KQMx2kNUp69Ni2HE3xw9/awlxEX2+nfZjsOfRehlVuRYk+ ykaTA6/2SixHS0OF5tsB7hPssgF/bpxRX68XjYPDH6ejdJKN3+QFbMdX8AbT/E0jvpU3ICr7M3q8 FlIFMz35Mp9fSSG90R8heBkX2XbiTVsT9+3ej7dQL/cfGGEn8CU+QafieHGh6CVUu2E8L8Q1c9du bz4YHqf4NXtll8Pl0K1V/gsAAP//AwBQSwMEFAAGAAgAAAAhAEx39wSQAQAA7wIAABEACAFkb2NQ cm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJySUW/TMBSF 35H4D5bfU9spghGlnhjVEFLbTSwIxJtl37XWYieyL83673HcJgzBE4/WOf587rmur59dS44Qou38 iooFpwS87oz1+xX92twWV5REVN6otvOwoieI9Fq+flXrvtJdgPvQ9RDQQiSJ5GOl+xU9IPYVY1Ef wKm4SA6fxMcuOIXpGPasV/pJ7YGVnL9lDlAZhYqNwKKfifSCNHpG9j9DmwFGM2jBgcfIxEKw316E 4OI/L2TlhdNZPPVppkvcl2yjz+Lsfo52Ng7DsBiWOUbKL9j37eYhj1pYP3algcra6AottiA3DwTB 9a1CIKkCslvWbBZHmw6gsAtyrY7WkJsuDirgweqn7JvUsfBWRdym3TxaMDcnub378mG3Jpu0OmhJ 8+kzu9vsava3cbwb4GjHJcsyO+bjxL0P1iMYmSYqC/6mKJcNf1cJXnH+Y2ZOphQ7l3nODoakeqpz mZPybflx3dzSxBPvC8ELUTb8qirFmTe58nTp1RnoLuP9N3ECyBz6zy8qfwEAAP//AwBQSwMEFAAG AAgAAAAhAAiHxUb5AgAALw0AABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzclt1u0zAUx++ReIco91uc NP1YtW7aVyUk2AUtmsSdkzqtRWxHtrPQZ+CS9+ANeBt4D47tpN26FGUDDY1VU9Nj+9T+9f8/x8en n1nu3RKpqOATPzxEvkd4KhaULyf+h/n0YOR7SmO+wLngZOKvifJPT16/Oq7GmeBaebCeqzFLJ/5K 62IcBCpdEYbVoSgIh8FMSIY1fJTLgGH5qSwOUsEKrGlCc6rXQYTQwK/TyC5ZRJbRlFyKtGSEa7s+ kCSHjIKrFS1Uk63qkq0SclFIkRKl4Mwsd/kYpnyTJowfJGI0lUKJTB/CYQK3o8CkguUhsk8s9z2W jt8suZA4yYFdFcb+SQ3Oq8YcMwjO1iwRuY0XmAtFQhi6xfnER314hcgkHKIBvPfR0A9MgnSFpSJ6 MzFy4Qwzmq+bqBQMczdQUJ2umvgtltTsxw0puoSBUiUIvrD+810kBD3cj0QP5vTuR1KbZ3RnFUQg zyYzbD9wynkAYk4ZUd41qbz3dudmwi6RCCgMUA9IxPAfwVPcTgT9HSJXsPHoajrdErmAyHDUP68j WyJHdaSViD1/6PJ0J/JOcKHXBfFmQmplJYJzfQ2yaX7Lj7jILkG2CTisHUSrNHCphZv+IpRxQxJT jxyBXUn0QQTOJH10BOIYot4jSLw0k1yIUlIijU1aS0Zkzg8cjFGMQeJHGYSJBZFtNSOjn8nCYb1b MPbZI+49hz1uQBO/00VTdDbvj9DFC3PIGZT09h4SoXMwRWwFYUQBkmjH0FoxVUVVXVg6Vop/K4k5 XkHv2OMMB8I1DwPkiSCgJs9lSeZQmG0z7gimVmHjjLtN0bXbbSuBO5htyftbCUKhmdO9lcwom5W8 rYX8/Pblx/evThO7tdVcPQawcVNh61ereEYDF75/Adl66M+Q2aPCDcUgGyEjsAbQBlnYRPYhi5tV 3ZFd4Jwmknpv6XKl90hqCmhqV9mnJ0qqo4Sst852byNRPHyW20jNYy8J025sffn/SNRXVnXyCwAA //8DAFBLAwQUAAYACAAAACEArnTR7O0BAAC1DAAAFAAAAHdvcmQvd2ViU2V0dGluZ3MueG1s7FdL b9swDL4P2H8wdG8sJ36jSYGg6DCge2Brd5dlJREmiYakxEt//Ri77dJ2h/gQbAefTJHiZ1KfTNKX V7+0CnbCOglmTqIJJYEwHGpp1nNyf3dzkZPAeWZqpsCIOdkLR64W799dtmUrqu/Ce9zpAkQxrtR8 TjbeN2UYOr4RmrkJNMKgcQVWM49Luw41sz+3zQUH3TAvK6mk34dTSlPyCGNPQYHVSnJxDXyrhfGd f2iFQkQwbiMb94TWnoLWgq0bC1w4h/lo1eNpJs0zTBS/AdKSW3Cw8hNMJuwjCg9Q6B7RTtKKBJqX H9cGLKsUnmAbxWSBx1fLnXt8Bm0pazz9LKFpkaeduYJ6fy13aNoxhTYSHjbj2d2KlX/S0mftN7ne /EV9B83bvUvwHvQrPYazrO3hHf6Pj0HOCW50D3OCNwOFhnHMoZM5KECq2NZDH4Y6imyYZ/UiomG+ 9jjzIa5hx0GXdC++ZCOe5WmcpclIx6BLcC468igtojwev44hV7wtz0ZHnGZJRBM6FqshJfJcdBRF UiQpTfvWMvaOEzvWueiI4lkxTWhBx8/jv2geUTZLplmE49VYrv5VuepnrG7khcZLLR/EDdilhdYJ 2w23OL7vv5gfn267FVMK2q+fP+ACXY9+Nha/AQAA//8DAFBLAwQUAAYACAAAACEAgr8XO0EHAACo MgAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbMxbXW7jNhB+L9A7GAL8GFvUv4z1LmTZLlJ006JJsc+y rMTC6g+SbG/eiu0leoMCvUB7q71Ch6QkS9aPY0lGlYfYITlD8psfDmeYdx++uM7oYIWR7XtzBk1Y ZmR5pr+1vZc589vT+k5hRlFseFvD8T1rzrxaEfPh/fffvTvOvL27sUIYOAIeXjQ7Buac2cVxMJtO I3NnuUY0cW0z9CP/OZ6Yvjv1n59t05oe/XA75VjEkm9B6JtWFAEf3fAORsQk7NwyNz+wPJjr2Q9d I44mfvgydY3w8z64A+6BEdsb27HjV+DNSikbf87sQ2+WLOguWxAmmdEFJR8pRVjaRcW8lHLpm3vX 8mIy4zS0HFiD70U7Ozhtoy032OIuXdKhaRMH10nHHQMklObLtvwWGSxD4wiiODEssasAY0uJXIfi gOV7kuo5R8Q2bSaRCGaRreEtSyjOma7ENWwvY9MOmjy4YBJd9PuH0N8H2XICuxu3e+9zxgtb5hUr YyViefmtRVcxKJnu484ILGbkmrP7F88PjY0DKzoiYYQ1knkP3sLYRHFomPHD3h0V/rrfzhmWDPEi ewt9B8OZM2vyI+vMFBO7eye2f7IOlvP0GljpGOwzHIs002GxGzhppygJK4mXEgbOAXfY8JFOBk4t jNPBiNKDR1u7WePWMm3XcGgXUD5ZX7K+MZpk7T+aKRvHeo5pc/BLiNcdw66Tz3QMzMHA98AHxJGg cnj89DTS9jAEmFHSDX/tDO8FtjpneIlNhhP+QAbLIuQ5dC+CjerAXtK1twCbX8jKihcEymCgYHOs 2gQ27u4fbK4O7FVrsJeaoomaRlSBaACsemiarXJSA9a4t3+o+Tqo162hXsuCIOuKQhkMU68lgW+A Gvf2DzV16WV/rSRK2cKFcKDSMqsStWmn1Zu941iJ/z1z19++/pOJ8H9z18dZSE+FcO17cQRSMSLT hijg8dXd+BDDgafXANNCg+3BQbC1ng04ARMxEy4tfb9YYyNKcgK2EJyk86vVktUygGEf17mj2wuu m+sfguCkOsGRAKJVhCQvFE6Vlx0ipJsLrtMxMgSxyXViIz67ldiWMuIURRuyvXU6koYgNqVObEkk 0MJNLjRRUPXVoEOJ0/0ivbjkryO4t/9QQq2DmgTrrSxE45HCr/QOUN/csXVCeggWgspXdrRgNZRd AluYiM4K0lpEPR1IwWP86mS5ggc/XkICMwtS8pf5b7//m7W3jw7Tq3mV6SCZgzxq7iYPHjyJ5pJM QU1o+NH3/BinPB79MIacYhYiVnT0HCqicp5AQLrG6fRq18oykaKvltL6JhLW9Kf7nx8yQRYE/Mff WXt7Ad/GZj9ZG5xsz8u20NS3VMsJCUFdLLnlIrl5Vdvt7nUT2tuPOA3n4DQchTOfb0MLntMgDZQB nbsGwNc4cCCfjwR5pSxljfj8yxm4Bjd8l83TIND86SVzjadXrU99sl0rGj1Yx9GvvmtANvk4s4wo 1iLbmDMVnckVrqLHhIxfRfPukoSLt2GEV0DRZAVWZVmWXPBjqEJA8eEAaVdqt53Q9a9FFwlCO3h1 fx/aVogBznm3s1aM3FnTlahxJdRE0tIrat++/nUtbhxqDqpq1fIT+IyS3yi0XadWVImIkSZqRRWt Z4DelIbJmy0clO0Uq0tSpWhxQkl3hmBxcBq1A+bckGjK6ay1u8VR+8or1DAsTuBbHgR9WxxJgRcc +TAsTgT7J664pupU65L6szh5kBYnyi199ZltJRHCWWt3iyM3jIJCDcPiJKGlC+9ucZAlv6oyWi4h QdJGk9R1Y2mUhMw1YbGqabq4Ut5W1hBp+NBQhi5eard1N9pxks6HMkhDeJzeVOETYkpSdi9UpxFH FlRXncbdQJdVp9FpfM2l9sqg7a2B7IVC/ThJkXcCg+PEpuox6b4pGPTedjmqvwjGZJzknjvhwfMq YVOjHKT7pnhQU+0Hj8n49HKhvb0IIidjA66BhHTfFBJale0Nksk48UedFEWUJOKMalAh3TdFhZY8 +0RlMj658/bqIslqk3sl3TcFhpYUewZmMiY2QG5Q7bFROPqWqEZpSHcBG5x+oKbXz9FD63b9YzMZ nxJk7eFReZpnq4GHdN8UHlofuwk8k3FS+OnkdRArosandaS/Z4xAHFdFm+VXNPBgUWV1dUXjwOpU bOOrxwWEm2t1kTAACGGL7R9jFKPN5Uq/f6xPsf9JF91JbDdKsRfyYjTfUbxbXMqVlSULgTJAC7/x 81UaqOZkf48fcZKAGl6/Ur8EQ/HLzAIdjemq6dLoqoqOxj7VdOlhW0VXeombW2fqP6vo6BFaOV8a FFeR0QOmkiwNlKrIqO+tJCPnLgijioz6pEqy9JytIqP150qyJtEl9c9KurS0VzVdUlWrpGsSOXiz s4e9J9mljq5yviZdaVDN8qvt03xNqoIadCXzyKeF3m8/GqYW645lePsgNZoc8PQ/TN7/BwAA//8D AFBLAwQUAAYACAAAACEAfGyAIQ0CAADJCAAAFAAAAHdvcmQvY29tbWVudHNJZHMueG1spJbbctow EIbvO9N38OgeZJsAjgfIpKHtcN30ARRJYE2sw0gGw9t3BTamdZOxzQ2HWf+f/l3tylo8HWUeHLh1 QqslisYhCriimgm1W6Lfrz9GCQpcQRQjuVZ8iU7coafV1y+LMppRwVKqpeSqcBvmAkApl5aGLlFW FCbF2NGMS+LGUlCrnd4WY3ge6+1WUI5LbRmOwyg8/zJWU+4crPtC1IE4VOHosRuNWVKC2AMfMM2I LfixYUS9IVP8iJM2KB4AggzjqI2a9EbNsHfVAj0MAoGrFmk6jPSf5GbDSHGbNB9GmrRJyTBSq51k u8G14QqCW20lKeCv3WFJ7PvejABsSCHeRC6KEzDDWY0hQr0PcASqK0FOWG/CHEvNeD5hNUUv0d6q tNKPrnpvPb3oq69aYbvkf5GsNd37A+KcObY8h1po5TJhrhMuh9IgmNWQw2dJHGReP1eaqOO4fHQ8 rS+lbIBd7Ff1l/nF+efEKOywIx5xVXSx8PeatRMJXdgsPKg0N8WNOh4gNSBuAfxLpR/jUk3IB5Q3 HMf7YaY1xp1kM+ql2d3XLT+t3puGJu6jbZrZL/3buAer6rrbSXD3mfmVEQNHgqTpZqe0JW85OIIe CqANgvMO+E/YlcAPHVr9c2XYsCqcGmLJBnZ9nnxL1vEariBVgO3PVB8D/99f1s+PCK8WuH33WP0B AAD//wMAUEsDBBQABgAIAAAAIQDG4RhUBQIAAKwIAAAZAAAAd29yZC9jb21tZW50c0V4dGVuZGVk LnhtbKSW33KiMBTG73em78DkXgNYlWXEznTddrzu7gOkIUqm5M8kKPr2PREQO+x2AG9UhO+X75yc E87q6SRy78iM5UomKJj6yGOSqpTLfYL+/nmZRMizBZEpyZVkCTozi57WDz9WZTCPqRKCycL+PnmA kTYuNU1QVhQ6xtjSjAlip4JTo6zaFVN4HKvdjlOGS2VSHPqBf/mljaLMWljzF5FHYlGNo6d+tNSQ EsQO+IhpRkzBTi0jGAyZ45846oLCESCIMAy6qNlg1AI7Vx3Q4ygQuOqQ5uNI/whuMY4UdknLcaRZ lxSNI3XKSXQLXGkm4eZOGUEKuDR7LIj5OOgJgDUp+DvPeXEGpr9oMITLjxGOQHUliFk6mLDEQqUs n6UNRSXoYGRc6ydXvbMeV/r6q1GYPvFXko2iB3c+XCLHhuWQCyVtxvW1w8VYGtzMGsjxuyCOIm+e K3XQs13+dzxtqlS2wD726/yLvHL+PTHwe+yIQ1wVfSx8XbNxIqAK24VHpeYmuUHPA6QBhB3AgvKe Jd0wqmxCPKC84Vg2DDNvMPYs2lYv9f6+ank16qBbGr+Ptm17v3Rv4gGsuupuO8HeZ+YtIxqOBEHj 7V4qQ95zcAQ15EEZeJcdcJ+wK55rOrS+HRdgWnBXmhiyhf1eRs/RJtzA4OH+TS9Tho/weoW/jhjr TwAAAP//AwBQSwECLQAUAAYACAAAACEA7iLpPskBAAA3CAAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAekRq38wAAAE4CAAALAAAAAAAAAAAAAAAA AAIEAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDsxNKv9QEAAMsHAAAcAAAAAAAAAAAAAAAA ACYHAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAD4VBxiSFAAA 13oAABEAAAAAAAAAAAAAAAAAXQoAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhALsa uc7mAQAA7AUAABEAAAAAAAAAAAAAAAAAHh8AAHdvcmQvZW5kbm90ZXMueG1sUEsBAi0AFAAGAAgA AAAhACydjIPpAQAA8gUAABIAAAAAAAAAAAAAAAAAMyEAAHdvcmQvZm9vdG5vdGVzLnhtbFBLAQIt ABQABgAIAAAAIQBCL5damAcAANIgAAAVAAAAAAAAAAAAAAAAAEwjAAB3b3JkL3RoZW1lL3RoZW1l MS54bWxQSwECLQAUAAYACAAAACEAWWCJgjIGAAClEgAAEQAAAAAAAAAAAAAAAAAXKwAAd29yZC9z ZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAZb4HjDwQAAAscgAAGgAAAAAAAAAAAAAAAAB4MQAA d29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWxQSwECLQAUAAYACAAAACEARJBc0rQPAAA7bwAADwAA AAAAAAAAAAAAAADsQQAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAFhBVtZbAgAA7QUA ABAAAAAAAAAAAAAAAAAAzVEAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEATHf3BJAB AADvAgAAEQAAAAAAAAAAAAAAAABeVQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEA CIfFRvkCAAAvDQAAEgAAAAAAAAAAAAAAAAAlWAAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAG AAgAAAAhAK500eztAQAAtQwAABQAAAAAAAAAAAAAAAAATlsAAHdvcmQvd2ViU2V0dGluZ3MueG1s UEsBAi0AFAAGAAgAAAAhAIK/FztBBwAAqDIAABIAAAAAAAAAAAAAAAAAbV0AAHdvcmQvbnVtYmVy aW5nLnhtbFBLAQItABQABgAIAAAAIQB8bIAhDQIAAMkIAAAUAAAAAAAAAAAAAAAAAN5kAAB3b3Jk L2NvbW1lbnRzSWRzLnhtbFBLAQItABQABgAIAAAAIQDG4RhUBQIAAKwIAAAZAAAAAAAAAAAAAAAA AB1nAAB3b3JkL2NvbW1lbnRzRXh0ZW5kZWQueG1sUEsFBgAAAAARABEAUQQAAFlpAAAAAA== --_006_6B7134B31289DC4FAF731D844122B36E3A242ED0OPEXCAUBM41corp_-- From nobody Mon Oct 14 03:14:28 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806B912016E; Mon, 14 Oct 2019 03:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 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, UNPARSEABLE_RELAY=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 1SCpxUBWff9p; Mon, 14 Oct 2019 03:14:15 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D8D120143; Mon, 14 Oct 2019 03:14:15 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 46sDtZ1D20zBrVq; Mon, 14 Oct 2019 12:14:14 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 46sDtY5kgbzCqkX; Mon, 14 Oct 2019 12:14:13 +0200 (CEST) Received: from OPEXCAUBM41.corporate.adroot.infra.ftgroup ([fe80::857d:4f67:b0a7:10d7]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Mon, 14 Oct 2019 12:14:13 +0200 From: To: Ian Swett , Lars Eggert CC: "httpbis-chairs@ietf.org" , "allison.mankin@gmail.com" , "quic-chairs@ietf.org" , Gonzalo Camarillo , "ietf-http-wg@w3.org" , "quic@ietf.org" , "quic-ads@ietf.org" , "httpbis-ads@ietf.org" , "tsvwg-chairs@ietf.org" , "tsvwg@ietf.org" Subject: RE: LS from 3GPP on QUIC network level troubleshooting capabilities Thread-Topic: LS from 3GPP on QUIC network level troubleshooting capabilities Thread-Index: AQHVgaDz8OgjCQSpfkiz3j/IjLIVhadZCDMAgADij6A= Date: Mon, 14 Oct 2019 10:14:13 +0000 Message-ID: <7429_1571048053_5DA44A75_7429_244_1_6B7134B31289DC4FAF731D844122B36E3A24304B@OPEXCAUBM41.corporate.adroot.infra.ftgroup> References: <20859_1570868686_5DA18DCE_20859_72_1_6B7134B31289DC4FAF731D844122B36E3A240FE0@OPEXCAUBM41.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E3A24304BOPEXCAUBM41corp_" MIME-Version: 1.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: Mon, 14 Oct 2019 10:14:19 -0000 --_000_6B7134B31289DC4FAF731D844122B36E3A24304BOPEXCAUBM41corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFzIHNhaWQgYmVsb3csIFFVSUMgd291bGQgYmUgdXNlZCBvbmx5IGluIHRoZSBjb250 cm9sIHBsYW5lIGFuZCBub3QgZm9yIGUyZSB1c2VyIHRyYWZmaWMuDQoNClJlZ2FyZHMsDQoNCkxp b25lbA0KDQpEZSA6IElhbiBTd2V0dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb21dDQpFbnZv ecOpIDogbHVuZGkgMTQgb2N0b2JyZSAyMDE5IDAwOjM1DQrDgCA6IExhcnMgRWdnZXJ0DQpDYyA6 IE1PUkFORCBMaW9uZWwgVEdJL09MTjsgaHR0cGJpcy1jaGFpcnNAaWV0Zi5vcmc7IGFsbGlzb24u bWFua2luQGdtYWlsLmNvbTsgcXVpYy1jaGFpcnNAaWV0Zi5vcmc7IEdvbnphbG8gQ2FtYXJpbGxv OyBpZXRmLWh0dHAtd2dAdzMub3JnOyBxdWljQGlldGYub3JnOyBxdWljLWFkc0BpZXRmLm9yZzsg aHR0cGJpcy1hZHNAaWV0Zi5vcmcNCk9iamV0IDogUmU6IExTIGZyb20gM0dQUCBvbiBRVUlDIG5l dHdvcmsgbGV2ZWwgdHJvdWJsZXNob290aW5nIGNhcGFiaWxpdGllcw0KDQpJZiB0aGUgbWFpbiBj b25jZXJuIGlzIGluYWJpbGl0eSB0byBwYXNzaXZlbHkgbWVhc3VyZSBwYWNrZXQgbG9zcyBhbmQg YXMgTGFycyBzYWlkIHRoaXMgaXMgbm90IGZvciBlbmQtdG8tZW5kIHVzZXIgdHJhZmZpYyhzbyBz dXBwb3J0IGZvciBjZXJ0YWluIGV4dGVuc2lvbnMgY291bGQgYmUgYXNzdW1lZCksIHRoZW4gdGhp cyBjb3VsZCBiZSBhIGdvb2QgdGVzdCBjYXNlIGZvciBkcmFmdC1mZXJyaWV1eGhhbWNoYW91aS1x dWljLWxvc3NiaXRzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mZXJyaWV1eGhh bWNoYW91aS1xdWljLWxvc3NiaXRzLTAxPiB0byBwcm92ZSBpdCB3b3JrcyBhcyBpbnRlbmRlZCBh bmQgc2VlIGlmIHRoZSBtZWNoYW5pc20gbmVlZHMgYW55IGNoYW5nZXMuDQoNCk9uIFN1biwgT2N0 IDEzLCAyMDE5IGF0IDQ6MzQgQU0gTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZzxtYWlsdG86 bGFyc0BlZ2dlcnQub3JnPj4gd3JvdGU6DQpIaSBMaW9uZWwsDQoNCk9uIDIwMTktMTAtMTIsIGF0 IDExOjI0LCA8bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9y YW5nZS5jb20+PiA8bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5k QG9yYW5nZS5jb20+PiB3cm90ZToNCj4gUGxlYXNlIGZpbmQgZW5jbG9zZWQgYSBsaWFpc29uIHN0 YXRlbWVudCBmcm9tIHRoZSAzR1BQIENUIFdHIDQgKENUNCkuDQoNCkkgZG8gbm90IHNlZSB0aGlz IGxpYWlzb24gc3RhdGVtZW50IHBvc3RlZCBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2xpYWlzb24vLiBQbGVhc2UgbWFrZSBzdXJlIHRvIHN1Ym1pdCBpdCB2aWEgdGhlIHJlZ3VsYXIg cHJvY2VzcywgdG8ga2VlcCBhbGwgcmVsZXZhbnQgZW50aXRpZXMgaW4gdGhlIGxvb3AuDQoNCj4g VGhpcyBXRyBpcyBhY3R1YWxseSBzdHVkeWluZyB0aGUgaW50cm9kdWN0aW9uIG9mIFFVSUMgYXMg dHJhbnNwb3J0IHByb3RvY29sIGluc3RlYWQgb2YgSFRUUC8yIGluIHRoZSA1RyBjb3JlIG5ldHdv cmsuDQo+IFRoZSBXRyBoYXMgc29tZSBxdWVzdGlvbnMgcmVnYXJkaW5nIHRoZSB0cm91Ymxlc2hv b3RpbmcgY2FwYWJpbGl0aWVzIHN1cHBvcnRlZCBieSBRVUlDIGNvbXBhcmVkIHRvIHRoZSBvbmVz IGF2YWlsYWJsZSB3aXRoIFRDUC4NCg0KQmFzZWQgb24gbXkgKGxpbWl0ZWQpIHVuZGVyc3RhbmRp bmcgb2YgdGhlIDVHIGFyY2hpdGVjdHVyZSwgdGhpcyB1c2Ugb2YgUVVJQyB3b3VsZCBiZSBhcyBh IHByb3RvY29sIGZvciBjYXJyeWluZyBjb250cm9sIGluZm9ybWF0aW9uIGluc2lkZSBhIDVHIG5l dHdvcmsgY29udHJvbCBwbGFuZS4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIG5vdCBhYm91dCB0aGUg ZW5kLXRvLWVuZCB1c2Ugb2YgUVVJQyBvdmVyIHBhdGhzIHRoYXQgdHJhdmVyc2UgNUcgbmV0d29y a3MuIElzIG15IHVuZGVyc3RhbmRpbmcgY29ycmVjdD8NCg0KVGhhbmtzLA0KTGFycw0KDQo+ICBU aGUgTFMgaXMgb2ZmaWNpYWxseSBhZGRyZXNzZWQgdG8gdGhlIFFVSUMgV0cuIEhvd2V2ZXIsIGl0 IHdhcyBoaWdobGlnaHRlZCB0aGF0IGh0dHBiaXMgV0cgY291bGQgYWxzbyBiZSBpbnRlcmVzdGVk IGluLiBJIHdpbGwgbGV0IHlvdSBkZWNpZGUgaWYgb25seSBRVUlDIG9yIGJvdGggYXJlIHJlbGV2 YW50IGluIHRoZSBkaXNjdXNzaW9uLg0KPg0KPiBOZXh0IENUNCBXRyBtZWV0aW5nczoNCj4gM0dQ UCBUU0cgQ1Q0Izk1ICAgICAgICAgICAxMXRoIOKAkyAxNXRoIE5vdmVtYmVyIDIwMTkgICAgICAg UmVubywgVVMNCj4gM0dQUCBUU0cgQ1Q0Izk2ICAgICAgICAgICAyNHRoIOKAkyAyOHRoIEZlYnJ1 YXJ5IDIwMjAgICAgICAgICAgU29waGlhIEFudGlwb2xpcywgRlINCj4NCj4gSXQgd291bGQgYmUg Z29vZCB0byByZWNlaXZlIGFuIG9mZmljaWFsIGZlZWRiYWNrIGF0IHRoZSBsYXRlc3QgZm9yIHRo ZSBGZWJydWFyeSBtZWV0aW5nLCB3aGVyZSB0aGUgc3R1ZHkgd2lsbCBiZSBjb25jbHVkZWQgKGF0 IGxlYXN0IGZvciB0aGlzIHJlbGVhc2UpLg0KPg0KPiBSZWdhcmRzLA0KPg0KPiA8aW1hZ2UwMDEu anBnPg0KPg0KPiBMaW9uZWwgTW9yYW5kDQo+IENoYWlyIG9mIDNHUFAgVFNHIENUDQo+IDNHUFAg TGlhaXNvbiBQZXJzb24gdG8gSUVURg0KPiBDaGFpciBvZiBJRVRGIERpbWUgYW5kIFJhZGV4dCBX R3MNCj4gQ29yZSBOZXR3b3JrIFNlbmlvciBBcmNoaXRlY3QgYW5kIERpYW1ldGVyIGV4cGVydA0K PiBDZWxsLiArMzMgNiAwNyA3NSA4OSAzNjx0ZWw6KzMzJTIwNiUyMDA3JTIwNzUlMjA4OSUyMDM2 Pg0KPiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jhbmdl LmNvbT4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCj4gcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCj4gYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwN Cj4gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0 ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPg0KPiBUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KPiB0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4N Cj4gVGhhbmsgeW91Lg0KPg0KPiA8TGlhaXNvbiBTdGF0ZW1lbnQgb24gUVVJQyBuZXR3b3JrIGxl dmVsIHRyb3VibGVzaG9vdGluZyBjYXBhYmlsaXRpZXMuZG9jeD4NCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlv dS4KCg== --_000_6B7134B31289DC4FAF731D844122B36E3A24304BOPEXCAUBM41corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBzYWlk IGJlbG93LCBRVUlDIHdvdWxkIGJlIHVzZWQgb25seSBpbiB0aGUgY29udHJvbCBwbGFuZSBhbmQg bm90IGZvciBlMmUgdXNlciB0cmFmZmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW9uZWw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPkVudm95 w6kmbmJzcDs6PC9iPiBsdW5kaSAxNCBvY3RvYnJlIDIwMTkgMDA6MzU8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+IExhcnMgRWdnZXJ0PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBNT1JBTkQgTGlvbmVsIFRH SS9PTE47IGh0dHBiaXMtY2hhaXJzQGlldGYub3JnOyBhbGxpc29uLm1hbmtpbkBnbWFpbC5jb207 IHF1aWMtY2hhaXJzQGlldGYub3JnOyBHb256YWxvIENhbWFyaWxsbzsgaWV0Zi1odHRwLXdnQHcz Lm9yZzsgcXVpY0BpZXRmLm9yZzsgcXVpYy1hZHNAaWV0Zi5vcmc7IGh0dHBiaXMtYWRzQGlldGYu b3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogTFMgZnJvbSAzR1BQIG9uIFFVSUMgbmV0 d29yayBsZXZlbCB0cm91Ymxlc2hvb3RpbmcgY2FwYWJpbGl0aWVzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIG1haW4gY29uY2VybiBpcyBpbmFiaWxpdHkgdG8g cGFzc2l2ZWx5IG1lYXN1cmUgcGFja2V0IGxvc3MgYW5kIGFzIExhcnMgc2FpZCB0aGlzIGlzIG5v dCBmb3IgZW5kLXRvLWVuZCB1c2VyIHRyYWZmaWMoc28gc3VwcG9ydCBmb3IgY2VydGFpbiBleHRl bnNpb25zIGNvdWxkIGJlIGFzc3VtZWQpLCB0aGVuJm5ic3A7dGhpcyBjb3VsZCBiZSBhIGdvb2Qg dGVzdCBjYXNlIGZvciZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1mZXJyaWV1eGhhbWNoYW91aS1xdWljLWxvc3NiaXRzLTAxIj5kcmFmdC1mZXJyaWV1eGhh bWNoYW91aS1xdWljLWxvc3NiaXRzPC9hPg0KIHRvIHByb3ZlIGl0IHdvcmtzIGFzIGludGVuZGVk IGFuZCBzZWUgaWYgdGhlIG1lY2hhbmlzbSBuZWVkcyBhbnkgY2hhbmdlcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgT2N0IDEzLCAyMDE5IGF0 IDQ6MzQgQU0gTGFycyBFZ2dlcnQgJmx0OzxhIGhyZWY9Im1haWx0bzpsYXJzQGVnZ2VydC5vcmci PmxhcnNAZWdnZXJ0Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5IaSBMaW9uZWwsPGJyPg0KPGJyPg0KT24gMjAxOS0xMC0xMiwgYXQgMTE6MjQsICZsdDs8 YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsaW9u ZWwubW9yYW5kQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5saW9uZWwubW9yYW5kQG9yYW5n ZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IFBsZWFzZSBmaW5kIGVuY2xvc2VkIGEgbGlh aXNvbiBzdGF0ZW1lbnQgZnJvbSB0aGUgM0dQUCBDVCBXRyA0IChDVDQpLjxicj4NCjxicj4NCkkg ZG8gbm90IHNlZSB0aGlzIGxpYWlzb24gc3RhdGVtZW50IHBvc3RlZCBhdCA8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vPC9hPi4gUGxlYXNlIG1ha2Ugc3VyZSB0 byBzdWJtaXQgaXQgdmlhIHRoZSByZWd1bGFyIHByb2Nlc3MsIHRvIGtlZXAgYWxsIHJlbGV2YW50 IGVudGl0aWVzIGluIHRoZSBsb29wLjxicj4NCjxicj4NCiZndDsgVGhpcyBXRyBpcyBhY3R1YWxs eSBzdHVkeWluZyB0aGUgaW50cm9kdWN0aW9uIG9mIFFVSUMgYXMgdHJhbnNwb3J0IHByb3RvY29s IGluc3RlYWQgb2YgSFRUUC8yIGluIHRoZSA1RyBjb3JlIG5ldHdvcmsuPGJyPg0KJmd0OyBUaGUg V0cgaGFzIHNvbWUgcXVlc3Rpb25zIHJlZ2FyZGluZyB0aGUgdHJvdWJsZXNob290aW5nIGNhcGFi aWxpdGllcyBzdXBwb3J0ZWQgYnkgUVVJQyBjb21wYXJlZCB0byB0aGUgb25lcyBhdmFpbGFibGUg d2l0aCBUQ1AuPGJyPg0KPGJyPg0KQmFzZWQgb24gbXkgKGxpbWl0ZWQpIHVuZGVyc3RhbmRpbmcg b2YgdGhlIDVHIGFyY2hpdGVjdHVyZSwgdGhpcyB1c2Ugb2YgUVVJQyB3b3VsZCBiZSBhcyBhIHBy b3RvY29sIGZvciBjYXJyeWluZyBjb250cm9sIGluZm9ybWF0aW9uIGluc2lkZSBhIDVHIG5ldHdv cmsgY29udHJvbCBwbGFuZS4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIG5vdCBhYm91dCB0aGUgZW5k LXRvLWVuZCB1c2Ugb2YgUVVJQyBvdmVyIHBhdGhzIHRoYXQgdHJhdmVyc2UgNUcgbmV0d29ya3Mu DQogSXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0Pzxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpM YXJzPGJyPg0KPGJyPg0KJmd0OyZuYnNwOyBUaGUgTFMgaXMgb2ZmaWNpYWxseSBhZGRyZXNzZWQg dG8gdGhlIFFVSUMgV0cuIEhvd2V2ZXIsIGl0IHdhcyBoaWdobGlnaHRlZCB0aGF0IGh0dHBiaXMg V0cgY291bGQgYWxzbyBiZSBpbnRlcmVzdGVkIGluLiBJIHdpbGwgbGV0IHlvdSBkZWNpZGUgaWYg b25seSBRVUlDIG9yIGJvdGggYXJlIHJlbGV2YW50IGluIHRoZSBkaXNjdXNzaW9uLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBOZXh0IENUNCBXRyBtZWV0aW5nczo8YnI+DQomZ3Q7IDNHUFAgVFNHIENU NCM5NSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MTF0aCDigJMgMTV0 aCBOb3ZlbWJlciAyMDE5Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UmVubywgVVM8YnI+DQom Z3Q7IDNHUFAgVFNHIENUNCM5NiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7MjR0aCDigJMgMjh0aCBGZWJydWFyeSAyMDIwJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBTb3BoaWEgQW50aXBvbGlzLCBGUjxicj4NCiZndDsgPGJyPg0KJmd0OyBJdCB3b3Vs ZCBiZSBnb29kIHRvIHJlY2VpdmUgYW4gb2ZmaWNpYWwgZmVlZGJhY2sgYXQgdGhlIGxhdGVzdCBm b3IgdGhlIEZlYnJ1YXJ5IG1lZXRpbmcsIHdoZXJlIHRoZSBzdHVkeSB3aWxsIGJlIGNvbmNsdWRl ZCAoYXQgbGVhc3QgZm9yIHRoaXMgcmVsZWFzZSkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2Fy ZHMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZsdDtpbWFnZTAwMS5qcGcmZ3Q7PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IExpb25lbCBNb3JhbmQ8YnI+DQomZ3Q7IENoYWlyIG9mIDNHUFAgVFNHIENUPGJy Pg0KJmd0OyAzR1BQIExpYWlzb24gUGVyc29uIHRvIElFVEY8YnI+DQomZ3Q7IENoYWlyIG9mIElF VEYgRGltZSBhbmQgUmFkZXh0IFdHczxicj4NCiZndDsgQ29yZSBOZXR3b3JrIFNlbmlvciBBcmNo aXRlY3QgYW5kIERpYW1ldGVyIGV4cGVydDxicj4NCiZndDsgQ2VsbC4gPGEgaHJlZj0idGVsOiYj NDM7MzMlMjA2JTIwMDclMjA3NSUyMDg5JTIwMzYiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzMzIDYg MDcgNzUgODkgMzY8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBv cmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPjxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxicj4NCiZndDsgcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8YnI+DQomZ3Q7IGEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sPGJyPg0KJmd0OyBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7PGJyPg0KJmd0OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48YnI+DQomZ3Q7IElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxicj4NCiZndDsgQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxicj4NCiZndDsg VGhhbmsgeW91Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAmbHQ7TGlhaXNvbiBTdGF0ZW1lbnQgb24g UVVJQyBuZXR3b3JrIGxldmVsIHRyb3VibGVzaG9vdGluZyBjYXBhYmlsaXRpZXMuZG9jeCZndDs8 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_6B7134B31289DC4FAF731D844122B36E3A24304BOPEXCAUBM41corp_-- From nobody Mon Oct 14 10:08:28 2019 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 4B2B2120914; Mon, 14 Oct 2019 10:08:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "Lars Eggert" , "Mark Nottingham" Cc: =?utf-8?q?Mirja_K=C3=BChlewind?= , Mark Nottingham , QUIC Discussion List , georg.mayer.huawei@gmx.com, Lars Eggert , Magnus Westerlund , 3GPPLiaison@etsi.org Subject: New Liaison Statement, "LS on 3GPP CT WG4 feedback on QUIC network level troubleshooting capabilities" X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157107290622.24688.13746109096420368827.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2019 10:08:26 -0700 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: Mon, 14 Oct 2019 17:08:26 -0000 Title: LS on 3GPP CT WG4 feedback on QUIC network level troubleshooting capabilities Submission Date: 2019-10-14 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1655/ Please reply by 2020-02-14 From: Susanna Kooistra <3GPPLiaison@etsi.org> To: Lars Eggert ,Mark Nottingham Cc: Mirja Kühlewind ,QUIC Discussion List ,Lars Eggert ,Magnus Westerlund ,Mark Nottingham Response Contacts: georg.mayer.huawei@gmx.com,3GPPLiaison@etsi.org Technical Contacts: Purpose: For action Body: 1. Overall Description: 3GPP CT WG4 is performing a feasibility study on the potential usage of QUIC protocol for the 3GPP 5G Core Network in 3GPP°TR°29.893 (last version available via the following link: https://www.3gpp.org/ftp/Specs/archive/29_series/29.893/29893-120.zip). 3GPP CT WG4 is currently waiting for the release of the first official version of QUIC RFC in order to resume and conclude this study. 3GPP CT4 WG hence reviewed the IETF draft-ietf-quic-transport-19 and would like to provide the following feedback on network level troubleshooting capabilities of QUIC as compared to TCP (cf. clause°9.6.3 of 3GPP TR°29.893 for more details): - QUIC replaces both TLS and TCP. One of the main differences indeed is that QUIC encrypts the transport headers in addition to the payload, which is highly relevant for the network level troubleshooting matters. The existing Network OAM (Operation And Maintenance) solutions which are designed to make use and act on TCP headers would hence not be able to troubleshoot QUIC traffic and even less be easily adaptable to perform this task. - QUIC includes an optional measurement bit, named spinbit, which allows in-path probes to measure both the round trip delay and the decomposition of the delay on both sides of symmetrical path. - As of version 19, QUIC specifications do not support packet loss measurements. - To enable an in depth analysis of the performance (e.g. flow control, etc.) between a consumer 3GPP 5G core Network Function (NF) and a producer NF, the decryption of the entire QUIC message is often required in order to read the transport parameters of the QUIC packet header. Contrary to HTTP/2 over TLS, this has the side effect of decrypting and revealing application layer information to network probes. 2. Actions: To IETF QUIC group ACTION: 3GPP CT WG4 kindly asks IETF QUIC WG to take the above feedback into consideration in QUIC version 1 specification and provide a feedback (especially on the highlighted points). 3. Date of Next CT4 Meetings: 3GPP TSG CT4#95 11th – 15th November 2019 Reno, US 3GPP TSG CT4#96 24th – 28th February 2020 Sophia Antipolis, FR Attachments: Liaison Statement on QUIC network level troubleshooting capabilities https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2019-10-14-3gpp-tsgct-ct4-quic-ls-on-3gpp-ct-wg4-feedback-on-quic-network-level-troubleshooting-capabilities-attachment-1.docx From nobody Mon Oct 14 22:28:41 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A448120018; Mon, 14 Oct 2019 22:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.1 X-Spam-Level: X-Spam-Status: No, score=-4.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, 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 3luQFh89mD5z; Mon, 14 Oct 2019 22:28:37 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0E9AC120013; Mon, 14 Oct 2019 22:28:37 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DD8CCC04D2E5C4DE34BB; Tue, 15 Oct 2019 06:28:34 +0100 (IST) Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 15 Oct 2019 06:28:33 +0100 Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.58]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0439.000; Tue, 15 Oct 2019 13:28:30 +0800 From: "Roni Even (A)" To: "Black, David" , Christian Huitema , "lionel.morand@orange.com" , "quic@ietf.org" , "ietf-http-wg@w3.org" CC: Magnus Westerlund , "quic-chairs@ietf.org" Subject: RE: LS from 3GPP on QUIC network level troubleshooting capabilities Thread-Topic: LS from 3GPP on QUIC network level troubleshooting capabilities Thread-Index: AdWA0hpjWJ/tXLvVSCu8fqJq00l+9AAYtkQAAAZBkwAAJhlCgABMpveg Date: Tue, 15 Oct 2019 05:28:29 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD23D85F7A@dggemm526-mbx.china.huawei.com> References: <20859_1570868686_5DA18DCE_20859_72_1_6B7134B31289DC4FAF731D844122B36E3A240FE0@OPEXCAUBM41.corporate.adroot.infra.ftgroup> <4f9136db-73f7-33a6-bd1e-b399bfa7bf7e@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.64] Content-Type: multipart/related; boundary="_004_6E58094ECC8D8344914996DAD28F1CCD23D85F7Adggemm526mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 15 Oct 2019 05:28:41 -0000 --_004_6E58094ECC8D8344914996DAD28F1CCD23D85F7Adggemm526mbxchi_ Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD23D85F7Adggemm526mbxchi_" --_000_6E58094ECC8D8344914996DAD28F1CCD23D85F7Adggemm526mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The work on further development for passive monitoring takes place now in I= PPM WG see https://tools.ietf.org/id/draft-cfb-ippm-spinbit-new-measurement= s-01.txt. So IPPM WG should also be aware of this liaison Roni From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Black, David Sent: Monday, October 14, 2019 3:51 AM To: Lubashev, Igor; Christian Huitema; lionel.morand@orange.com; quic@ietf.= org; ietf-http-wg@w3.org Cc: httpbis-chairs@ietf.org; Magnus Westerlund; allison.mankin@gmail.com; q= uic-chairs@ietf.org; wes@mti-systems.com; Gorry (erg); Gonzalo Camarillo; B= lack, David; httpbis-ads@ietf.org; quic-ads@ietf.org Subject: RE: LS from 3GPP on QUIC network level troubleshooting capabilitie= s Everyone, I write as a TSVWG WG chair and as the shepherd for the TSVWG draft that Ch= ristian mentioned. Going back to the beginning of this thread, Lionel wrot= e: > Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4). I could not find that in the liaison statement area of the IETF datatracker= . Would someone please forward a copy to tsvwg-chairs@ietf.org ? Thanks in advance. Moving onward ... > This topic, troubleshooting capabilities supported by QUIC compared to th= e ones available with TCP, is currently being debated in the transport area= working group (tsvwg). > The TSVWG draft (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transp= ort-encrypt/) is a general discussion of "The Impact of Transp= ort Header Confidentiality on Network Operation and Evolution of the Intern= et". The latter sentence is correct, but the first sentence is mistaken. Troub= leshooting capabilities supported by QUIC are a matter for the QUIC WG, and= discussion should occur there - in this regard, I'm reminded of a statemen= t posted on the cash register of a pizza place that I frequented back when = I was an undergrad: "The bank doesn't make pizza - We don't cash checks." T= here is a TSVWG discussion on the general matter of transport header confid= entiality impacts that we (TSVWG chairs) hope to see conclude in the near f= uture, as that draft (draft-ietf-tsvwg-transport-encrypt) is currently in W= G Last Call in TSVWG. If that discussion does conclude in the next several= weeks, the resulting revised draft would make a fine input to a QUIC WG di= scussion of troubleshooting, so: > It might be a good idea for the IETF to have that discussion at just one = place. I would agree and suggest the QUIC WG as the appropriate place for a discus= sion of QUIC troubleshooting. Thanks, --David From: Lubashev, Igor > Sent: Sunday, October 13, 2019 2:40 AM To: Christian Huitema; lionel.morand@orange.com; quic@ietf.org; ietf-http-wg@w3.org Cc: httpbis-chairs@ietf.org; Magnus Westerl= und; allison.mankin@gmail..com; quic-chai= rs@ietf.org; wes@mti-systems.com; Gorry (erg); Gonzalo Camarillo; Black, David; httpbis-ads@i= etf.org; quic-ads@ietf.org Subject: RE: LS from 3GPP on QUIC network level troubleshooting capabilitie= s [EXTERNAL EMAIL] Christian, do you believe that the outcome of the tsvwg discussion and the = contents of draft-ietf-Ztsvwg-transport-encrypt will be timely enough to af= fect QUIC v1? If not, a discussion in QUIC WG would have a better chance o= f being timely for QUIC v1. 3GPP consists of Internet players who are mostly absent from QUIC WG, and t= heir concerns should be taken seriously, since their networks carry a large= portion of QUIC traffic. It would require everyone's efforts to ensure th= at QUIC can grow from a single-digit percentage to the majority of Internet= traffic with QUIC v1. * Igor From: Christian Huitema > Sent: Saturday, October 12, 2019 11:41 PM This topic, troubleshooting capabilities supported by QUIC compared to the = ones available with TCP, is currently being debated in the transport area w= orking group (tsvwg). The TSVWG draft (https://datatracker.ietf.org/doc/dra= ft-ietf-tsvwg-transport-encrypt/) is a general discussion of "T= he Impact of Transport Header Confidentiality on Network Operation and Evol= ution of the Internet". It might be a good idea for the IETF to have that discussion at just one pl= ace. -- Christian huitema On 10/12/2019 1:24 AM, lionel.morand@orange.com wrote: Hi, Please find enclosed a liaison statement from the 3GPP CT WG 4 (CT4). This WG is actually studying the introduction of QUIC as transport protocol= instead of HTTP/2 in the 5G core network. The WG has some questions regarding the troubleshooting capabilities suppor= ted by QUIC compared to the ones available with TCP. The LS is officially addressed to the QUIC WG. However, it was highlighted = that httpbis WG could also be interested in. I will let you decide if only = QUIC or both are relevant in the discussion. Next CT4 WG meetings: 3GPP TSG CT4#95 11th - 15th November 2019 Reno, US 3GPP TSG CT4#96 24th - 28th February 2020 Sophia Antipol= is, FR It would be good to receive an official feedback at the latest for the Febr= uary meeting, where the study will be concluded (at least for this release)= . Regards, ________________________________ [http://www.orange.com/sirius/logos_mail/orange_logo.gif] Lionel Morand Chair of 3GPP TSG CT 3GPP Liaison Person to IETF Chair of IETF Dime and Radext WGs Core Network Senior Architect and Diameter expert Cell. +33 6 07 75 89 36 lionel.morand@orange.com --_000_6E58094ECC8D8344914996DAD28F1CCD23D85F7Adggemm526mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

The work on further de= velopment for passive monitoring takes place now in IPPM WG see https://tools.ietf.org/id/draft-cfb-ippm-spinbit-new-measu= rements-01.txt. So IPPM WG should also be aware of this liaison

Roni=

 

From: QUIC [ma= ilto:quic-bounces@ietf.org] On Behalf Of Black, David
Sent: Monday, October 14, 2019 3:51 AM
To: Lubashev, Igor; Christian Huitema; lionel.morand@orange.com; qui= c@ietf.org; ietf-http-wg@w3.org
Cc: httpbis-chairs@ietf.org; Magnus Westerlund; allison.mankin@gmail= .com; quic-chairs@ietf.org; wes@mti-systems.com; Gorry (erg); Gonzalo Camar= illo; Black, David; httpbis-ads@ietf.org; quic-ads@ietf.org
Subject: RE: LS from 3GPP on QUIC network level troubleshooting capa= bilities

 

Everyone,

 

I write as a TSVWG WG = chair and as the shepherd for the TSVWG draft that Christian mentioned.&nbs= p; Going back to the beginning of this thread, Lionel wrote:

 

> Please find enclosed a liaison statement from t= he 3GPP CT WG 4 (CT4).

 

I could not find that = in the liaison statement area of the IETF datatracker.  Would someone = please forward a copy to tsvwg-chairs@ietf.org ?  = Thanks in advance.

 

Moving onward …<= o:p>

> This topic, troubleshooting capabilities supported by QUIC compared= to the ones available with TCP, is currently being debated in the transpor= t area working group (tsvwg).
> The TSVWG draft (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-t= ransport-encrypt/) is a general discussion of "The Impact of Transport Header Confidenti= ality on Network Operation and Evolution of the Internet".

The latter sentence is= correct, but the first sentence is mistaken.   Troubleshooting c= apabilities supported by QUIC are a matter for the QUIC WG, and discussion = should occur there – in this regard, I’m reminded of a statement posted on the cash register of a pizza place that I frequen= ted back when I was an undergrad: “The bank doesn’t make pizza = – We don’t cash checks.” There is a TSVWG discussion on t= he general matter of transport header confidentiality impacts that we (TSVWG chairs) hope to see conclude in the near future, as that dr= aft (draft-ietf-tsvwg-transport-encrypt) is currently in WG Last Call in TS= VWG.  If that discussion does conclude in the next several weeks, the = resulting revised draft would make a fine input to a QUIC WG discussion of troubleshooting, so:

> It might be a good idea for the IETF to have that discussion at jus= t one place.

I would agree and sugg= est the QUIC WG as the appropriate place for a discussion of QUIC troublesh= ooting.

 

Thanks, --David

 

From: Lubashev, Igor <ilubashe@akamai.com>
Sent: Sunday, October 13, 2019 2:40 AM
To: Christian Huitema; l= ionel.morand@orange.com; quic@ietf.org; ietf-http-wg@w3.org
Cc: httpbis-chairs@ietf.o= rg; Magnus Westerlund; allison.mankin@gmail..com;= quic-chairs@ietf.org; wes@mti-sy= stems.com; Gorry (erg); Gonzalo Camarillo; Black, David; httpbis-ads@ietf.org; quic-ads@ietf.org
Subject: RE: LS from 3GPP on QUIC network level troubleshooting capa= bilities

 

[EXTERNAL EMAIL]

Christian, do you believe that the outcome of the ts= vwg discussion and the contents of draft-ietf-Ztsvwg-transport-encrypt will= be timely enough to affect QUIC v1?  If not, a discussion in QUIC WG = would have a better chance of being timely for QUIC v1.

 

3GPP consists of Internet players who are mostly abs= ent from QUIC WG, and their concerns should be taken seriously, since their= networks carry a large portion of QUIC traffic.  It would require eve= ryone’s efforts to ensure that QUIC can grow from a single-digit percentage to the majority of Internet traffic wi= th QUIC v1.

 

  • Igor

 

From: Christian Huitema <huitema@huitema.net>
Sent: Saturday, October 12, 2019 11:41 PM

This topic, troubleshooting capabilities supported by QUIC compared to t= he ones available with TCP, is currently being debated in the transport are= a working group (tsvwg). The TSVWG draft (https://datatracker.ietf.org/do= c/draft-ietf-tsvwg-transport-encrypt/) is a general discussion of "The Impact of Transport Header Confidenti= ality on Network Operation and Evolution of the Internet".

It might be a good idea for the IETF to have that discussion at just one= place.

-- Christian huitema

On 10/12/2019 1:24 AM, lionel.morand@orange.com wrote:

Hi,

 

Please find enclosed a liaison statement from the 3G= PP CT WG 4 (CT4).

This WG is actually studying the introduction of QUI= C as transport protocol instead of HTTP/2 in the 5G core network.

The WG has some questions regarding the troubleshoot= ing capabilities supported by QUIC compared to the ones available with TCP.=

 

The LS is officially addressed to the QUIC WG. Howev= er, it was highlighted that httpbis WG could also be interested in. I will = let you decide if only QUIC or both are relevant in the discussion.

 

Next CT4 WG meetings:

3GPP TSG CT4#95      &= nbsp;    11th – 15th November 2019   &n= bsp;   Reno, US

3GPP TSG CT4#96      &= nbsp;    24th – 28th February 2020   &n= bsp;      Sophia Antipolis, FR

 

It would be good to receive an official feedback at = the latest for the February meeting, where the study will be concluded (at = least for this release).

 

Regards,

 

3D"http://www.orange.com/sirius/logos_mail/orange_logo.gif"

Lionel Morand<= /span>
Chair of 3GPP TSG CT

3GPP Liaison Person to= IETF

Chair of IETF Dime and= Radext WGs
Core Network Senior Architect and Diameter expert

Cell. +33 6 07 75 89 36
lione= l.morand@orange.com  

--_000_6E58094ECC8D8344914996DAD28F1CCD23D85F7Adggemm526mbxchi_-- --_004_6E58094ECC8D8344914996DAD28F1CCD23D85F7Adggemm526mbxchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=998; creation-date="Tue, 15 Oct 2019 05:28:28 GMT"; modification-date="Tue, 15 Oct 2019 05:28:28 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAyADIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCxRRRX 52fpgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAWbXT7y+3fZbaSbZ97YOlEen3ksTypaytGh IdgvCkdc1s6PfWv9kpZy37WMkVyJy4H+sX0qXUdctbq0kSKWSNZb3fIi8Ex4xmu+OHo+zUnLX5HB LEV/aOCjpfz/AK1/4cw5NLv4ljaS0lUSHCEr1NJPpt9bKjTWksYkbapZep9K63+2tKhTy47tGQXK SIApyFA7nuaq2mtQNNIGdp5H1HzY0PUp6itJYSgnbn/Iyji8Q1fk/M52bStQt9vnWcybiFXK9Se1 S/2W8LbL5jZueV8xeCK7Bp4dEtIprmeWdDfM/wC8GCoPoPaub16+juIILeK6huER2ceXHt2596Vb C0qMW29e39foOji61aSilp31/r7zDf5XYD5gDgH1ooorzT0wooooAKMleQSCOhHaiinHcT2Hy3E9 w486aSTA43sTj86ZRRWlf+IzKh/DQUUUVkbH/9k= --_004_6E58094ECC8D8344914996DAD28F1CCD23D85F7Adggemm526mbxchi_-- From nobody Tue Oct 15 08:00:57 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524701207FC for ; Tue, 15 Oct 2019 08:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=oje2bGfg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k8vARLXe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX3-zcx-OBNV for ; Tue, 15 Oct 2019 08:00:46 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1292412010F for ; Tue, 15 Oct 2019 08:00:45 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B70CD22085; Tue, 15 Oct 2019 11:00:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 15 Oct 2019 11:00:41 -0400 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=fm3; bh=h mmqzrzccPq29lwfYbWYCipy+vWOiBtmlezO+N4ePg0=; b=oje2bGfg47j/XF0vR hnkD8wMlb2BXj/GYdUtVyYB5A2CmWISXcrL6Upyu6MrMAtLi6ZVAdigiWrInOjg1 8vLG6ZLAxmeMreb2HyXQ0iB8gmQxDqW6HNUZDK3eWj361eFF7kOdxT5NfP3EKRHZ t2nS7zkWnC1gq/txWFkZGJFqynNlRrHQOQs9KStyJrrwCrZ5bgcXw0aUSjwO/YuX toRgkd0YG4KgFNb7VlcPoKyrArtV0uKx9q61BKUVmftb5wIsMXbZ984vQGFwtzF5 RDGg5gE/jBNPj3q33oaHFhDM+x/JUR4NTxrZgBH45nnol4drcVnxfB0Yg8SCGYGH +NEvA== 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=fm1; bh=hmmqzrzccPq29lwfYbWYCipy+vWOiBtmlezO+N4eP g0=; b=k8vARLXetM99+RgDy9veH/pEEot80JMivLwjKtBpw+ZzRyAyqHl3cJlaV FgVR8SEMUZVU9nw5mF9JHtROYCV2haQSyWbhEh9yEGrNOqB4m/U7wVXxRaIq1/IP 56AUlXkEpZQnQ9PUOXowGyPsk78VNdbfmEL8kXMzEGJpIRx/88PSGsn6lDNm+o+x ZCMWFtILfXSaGswtv8aF538x+1lmoQdj6ZLaexyIelZpVuQeGTvVL5yvqy0VQcF+ Jaaj8qz2vGpO6P3RpkPf8Gs76sOHrQKhK1gkAaL0/dweso0fsnlYLLxyRwLBP16B G5+XhTAa3Rhuhozjt6nAgk1tV1T4w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjeefgdekvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppeeifedrkedvrddvhedtrdeh tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlh hushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [172.20.0.149] (unknown [63.82.250.50]) by mail.messagingengine.com (Postfix) with ESMTPA id 77E2B8006B; Tue, 15 Oct 2019 11:00:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Re: Consensus Calls on Recent Transport/TLS Issues, week of 25 September From: Mark Nottingham In-Reply-To: Date: Tue, 15 Oct 2019 08:00:37 -0700 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <6B0AAD51-83BA-480B-9184-0CAA52A21545@mnot.net> References: To: IETF QUIC WG X-Mailer: Apple Mail (2.3594.4.19) 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, 15 Oct 2019 15:00:50 -0000 There's been some more discussion on #2152 and #3053, so we'll remove = the 'proposal-ready' flag on those and hopefully nail down solutions = this week. For the rest, consensus declared. > On 25 Sep 2019, at 12:30 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 next week. >=20 > See for the current = state of issues in the Late Stage process, itself defined at = . >=20 > * #3053: Padding requirement seems to be incorrect. > The proposal is = >=20 > * #3034: Allow PING in Initial/Handshake? > The proposal is >=20 > * #3030: Remove Requirement of an Acknowledgement per Round Trip > The proposal is >=20 > * #3010: Validating 0-RTT configuration in TLS API > The proposal is >=20 > * #2785: Disallow reuse of stateless reset tokens > The proposal is >=20 > * #2152: Why does stateless reset have to be checked after MAC failure > The proposal is >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu Oct 17 07:44:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F03B1200B8 for ; Thu, 17 Oct 2019 07:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 ElFPbdAlCO82 for ; Thu, 17 Oct 2019 07:44:15 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 66B101200F9 for ; Thu, 17 Oct 2019 07:44:15 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id o12so3963853qtf.3 for ; Thu, 17 Oct 2019 07:44:15 -0700 (PDT) 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=WJmcf8DquE3qtxWZpsr2MVXQ9XHYLAKr+NFd8McuNC0=; b=jNpF3Z93xnDzACfr374Nq8SwI+RcvzVHtviD0Mrcw1ZJ1yFnMyuwwiUmsQalE12FjZ dFM/tZ3Q+rbu8FqGsVLwUHNhyvnEQ6ilm9J82GBrdT5LKUGuJN/0WoI+g1bB7RASbAtw KVLEyQZ4S5TZ9i/giIBCzUKxdDJSeXApTdl23MLjxY0Vsw4COmQatpMK+YOP4QsNWthO wNsmRA7MSvk9oDXskrZAVsNUIPZE9W0Ue0UDgqJXrYkFKpHKXVXhvdSkzela/uv0Z3BS 06KET+jPqTFKbyxODC61sFkZfik0s/ewfjfY1Wj0M0hObeyOLRFS7gI/a+zkifUabASP NVaA== 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=WJmcf8DquE3qtxWZpsr2MVXQ9XHYLAKr+NFd8McuNC0=; b=YAFQE/d4NstSJXgtox/I71qIIxwV4oZxVefeMqIAFP7haNMTe4EaAURARgXO1fjjEb EPA9gD09vAaJUgVb2TAStZEkw2sQ9P0Q3XL6BZxvNQUJozqVAafZ1rfuvadWnH1Przzx 3IO1lZyYRmxA+SZGrVGnLxbQJqJi/bErmxjQGnjJXj2JT7nKNu/Ujr4cpAz+2gusgStw UwieU8cR7OlvxGNlmStdtOofFaLFN7YcCAYfrSez8OHEdLEPqY3PfxU5OphdSD/I8t/y Wud/EeLnE4OgCz+zHbc95Lyxa9AFcbFM2yP1omJPZe3hE17yxEPU+UpqBwxKsvr1dgA+ RhYg== X-Gm-Message-State: APjAAAURe3qzMfGOTS22XyUKemdIskJqwTcB2fT+b+KO1kvp5KwbloQT n3/ikHdfUgSMfpgI+Ur18ZFSww== X-Google-Smtp-Source: APXvYqyYU8nCgg/jvUKTfWuzPtYXlnIbJdM3BbJfXGZqt4C6bhLZz9ZDTR7Ul39gmENo+BdSG92dcw== X-Received: by 2002:ac8:3408:: with SMTP id u8mr4251892qtb.380.1571323454509; Thu, 17 Oct 2019 07:44:14 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id l185sm1465487qkd.20.2019.10.17.07.44.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Oct 2019 07:44:13 -0700 (PDT) Date: Thu, 17 Oct 2019 10:44:07 -0400 From: Dmitri Tikhonov To: David Schinazi Cc: Kazuho Oku , Eric Rescorla , Nick Harper , Ted Hardie , IETF QUIC WG Subject: Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS Message-ID: <20191017144406.GA18835@ubuntu-dmitri> Mail-Followup-To: David Schinazi , Kazuho Oku , Eric Rescorla , Nick Harper , Ted Hardie , IETF QUIC WG References: 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: Thu, 17 Oct 2019 14:44:17 -0000 On Wed, Oct 02, 2019 at 02:20:52PM -0700, David Schinazi wrote: > If we decide that the first requests need to operate without knowledge > of settings, we're effectively crippling the main extension mechanism > we have in HTTP/3. I'm not comfortable saying that for the entire > lifetime of QUICv1 we cannot have extensions that impact the first > requests. That feels like painting ourselves into a corner. Is there prior art? That is, are there protocols that allow extension settings to be specified in a first request/packet? - Dmitri. From nobody Thu Oct 17 08:53:36 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B3012099A for ; Thu, 17 Oct 2019 08:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 LQxxKBNmLqyy for ; Thu, 17 Oct 2019 08:53:32 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 3CFB6120980 for ; Thu, 17 Oct 2019 08:53:32 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id v8so1720406lfa.12 for ; Thu, 17 Oct 2019 08:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UG1VsHqG2u9ERaaDIQ/00wKbFfrQO5I5zR2bcrHTu58=; b=p5HJUAXkWx+cUwqRmJtxQi+8pXz7azstFJagnqjNRfC/LbpuSzIZzSR709h+QU6G8L t3rZuGT+rYPCpO1suP4TVvW+6SBvb9RjFEihRcZHocVto/xApWEYfqCfeDFmLCNXqJwv euIpq9XxbLwjrIRcpIij9Cf/GLP5lrHWuRb1oer9az4JQA9oKhWQmoGbSiBBEyacfCTY ITU/D+MXSxcRNRzL377RxeHnICBW9ZHfzhiCbKBU1epeWQOVydaD1x7wdb/acoxOW4ce wIcpM5VSTtQqy4qZgAdIXucpEI4+hB+A6uvjiQfb6cmBkJXtMZMmRVOIcjarcQCxAPIO y0JQ== 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=UG1VsHqG2u9ERaaDIQ/00wKbFfrQO5I5zR2bcrHTu58=; b=YRiT5N/3rLtIX/j1J/vSbUBwqlb0ohpZSeIEFe4CejlSGgte4IF9upin57H5WtQxdR RJ/WEfMCWjgxuBA6tSt5gE8Fm+rs8JfOF8JURhsCLmySaq7Y0jrtdjusP3itfkl7mMEJ nliTdDAEc+O+IZ17fTdDfS7Pt06p4gyMZT5636A77mPzQcG3eANsF/1lpivnWMrr3/Tu UQgHkoW7E5YcuyvWrEQ+gTEslfCwPsr5nCmgb1A14tuujhtKqVPzmUEsHfNulKMwCfg8 ldeYATJcGobyW1vBQ3nQiSv5RtoPPpANKE17BRB+QDsExaYz2LwUAoJ0f0YnYMa5GntI CAvA== X-Gm-Message-State: APjAAAUNJqJAfeCZvnjsp5ZEO74Z7DP2yAYa/FjI6oHYgTSOn8t/WJUy JJaPcV1kLmWundXpuMulrxbJ6zJcbAa5fMmE8LQ= X-Google-Smtp-Source: APXvYqw7/G65bb/vniWIjkjRhVWYb4gSJY5DEUpWiW4pxZwfrDwsVwf4aYZU4L/K+qE8Y3w0vlh8cMsqmp5m8D5zrlI= X-Received: by 2002:ac2:53a7:: with SMTP id j7mr2898753lfh.10.1571327610475; Thu, 17 Oct 2019 08:53:30 -0700 (PDT) MIME-Version: 1.0 References: <20191017144406.GA18835@ubuntu-dmitri> In-Reply-To: <20191017144406.GA18835@ubuntu-dmitri> From: David Schinazi Date: Thu, 17 Oct 2019 08:53:12 -0700 Message-ID: Subject: Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS To: Dmitri Tikhonov Cc: Kazuho Oku , Eric Rescorla , Nick Harper , Ted Hardie , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000000c5b1105951d38e5" 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, 17 Oct 2019 15:53:35 -0000 --0000000000000c5b1105951d38e5 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 17, 2019 at 7:44 AM Dmitri Tikhonov wrote: > On Wed, Oct 02, 2019 at 02:20:52PM -0700, David Schinazi wrote: > > If we decide that the first requests need to operate without knowledge > > of settings, we're effectively crippling the main extension mechanism > > we have in HTTP/3. I'm not comfortable saying that for the entire > > lifetime of QUICv1 we cannot have extensions that impact the first > > requests. That feels like painting ourselves into a corner. > > Is there prior art? That is, are there protocols that allow extension > settings to be specified in a first request/packet? > TLS has client hello extensions. TCP has options that can travel with the SYN. --0000000000000c5b1105951d38e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Oct 17, 2019 at 7:44 AM Dmitri Ti= khonov <dtikhonov@litespe= edtech.com> wrote:
On Wed, Oct 02, 2019 at 02:20:52PM -0700, David Schinazi wrote:<= br> > If we decide that the first requests need to operate without knowledge=
> of settings, we're effectively crippling the main extension mechan= ism
> we have in HTTP/3.=C2=A0 I'm not comfortable saying that for the e= ntire
> lifetime of QUICv1 we cannot have extensions that impact the first
> requests. That feels like painting ourselves into a corner.

Is there prior art?=C2=A0 That is, are there protocols that allow extension=
settings to be specified in a first request/packet?
TLS has client hello extensions. TCP has options that can trav= el with the SYN.
--0000000000000c5b1105951d38e5-- From nobody Thu Oct 17 09:47:37 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCAA120953 for ; Thu, 17 Oct 2019 09:47:33 -0700 (PDT) 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 IQJaFU7c7jDY for ; Thu, 17 Oct 2019 09:47:31 -0700 (PDT) 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 4FD24120A30 for ; Thu, 17 Oct 2019 09:47:31 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id l10so2743193wrb.2 for ; Thu, 17 Oct 2019 09:47:31 -0700 (PDT) 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=zIFyyOVmYkUMM27R8v0nBo4iCLCdiZQ4sFZ5xZ8p8Eg=; b=Q6tO5ZwgcKN4yl4tEGbdeFmHpM4sZA++CNIDn4eKGdPckYZibD4QQzi51K+CEycA+Z CpWT4Np+xMK0fDUwYos6Op5ro344HY0SnCqW4UJeS0PIkTXPYtUe8stWpnDtEGy6AOEQ 6KHTylP6/tjqDbbUdJv8ylHmMC2WXid7BzrfpB0u6u3oPKuB1S1WLfrU8adklQFwO5K5 GBg+g4ZY3t52UwwIPNCRIhSaGjOyC5f3dADIb47TE4ByTtnIq8gernsmkITtkW7TKGze cDeG7Dh/j1ZI3ykG2OF44liUQYlCHXq+C+wyBY3KmazK1jyWqr+1tfhI2E8X000rkJDW 58Og== 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=zIFyyOVmYkUMM27R8v0nBo4iCLCdiZQ4sFZ5xZ8p8Eg=; b=NvRI0DOjQCTVKE4LfC9tzSjy4kpCxsApNKWwIVmjvJFebvd0wcKSaAy1GccxXTq7Aw ts/zvS3ktLnKNO4Bxt4Mny1r/XxiRxDSUEtyK75aGhQtFnGIRUIbDzCwTGGfW6UByN4b kQgtiViov0C3Ii+jfDwDfwMdkvA7w1IYA9zptI4b07Piml82IIK24d+7KrKv526EsUR9 Zuv1DluQ6ABPulXptrZMCeK0/8GD29soyqAfb8q3T4aTeh0gEtiZlo8ASJXomjoUTCv4 7DqPl9//Ll9rgUFn0IzmB4UOCuflfqORpI+/Jm7TpcpmjzKriHqMBqCACynql/C7reec kKKw== X-Gm-Message-State: APjAAAVt4xSyVrqoTLNnNuVCX/iGDxrh14EntPZzEsovdZDYX7lSyg8v DwGn5bFlu4I8MZvWEOtkn1NlaQUS0DnqxlB+35LsKbNoMWc= X-Google-Smtp-Source: APXvYqwOPtaLukBMp58xRLGtoAu6/mzIVZnceYoZPztE6IK1j3g/kIQpJMNV2boNdA27OjgD9HvaHgCDJfCuJ5R1H4M= X-Received: by 2002:a5d:540d:: with SMTP id g13mr3746869wrv.8.1571330849177; Thu, 17 Oct 2019 09:47:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Hamilton Date: Thu, 17 Oct 2019 09:47:16 -0700 Message-ID: Subject: Re: ALT_SVC HTTP/3 Frame? To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000001779a505951df9f9" 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, 17 Oct 2019 16:47:34 -0000 --0000000000001779a505951df9f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 26, 2019 at 5:06 PM Martin Thomson wrote: > On Fri, Sep 27, 2019, at 04:15, Mike Bishop wrote: > > The language in A.2.3 is talking about what is involved in porting an > > HTTP/2 extension to HTTP/3. In A.2.4 it says, =E2=80=9CFrame types defi= ned by > > extensions to HTTP/2 need to be separately registered for HTTP/3 if > > still applicable.=E2=80=9D Perhaps that sentence should be in A.2.3 ins= tead. > > Maybe this is something that should be on the body of the document, and > with a MUST. > I think that would be a good idea. --0000000000001779a505951df9f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 26, 2019 at 5:06 PM Martin Thomson <mt@lowentropy.net> wrote:
On Fri, Sep 27, 2019, at 04:15, Mike Bishop wrote:
> The language in A.2.3 is talking about what is involved in porting an =
> HTTP/2 extension to HTTP/3. In A.2.4 it says, =E2=80=9CFrame types def= ined by
> extensions to HTTP/2 need to be separately registered for HTTP/3 if > still applicable.=E2=80=9D Perhaps that sentence should be in A.2.3 in= stead.

Maybe this is something that should be on the body of the document, and wit= h a MUST.

I think that would be = a good idea.
--0000000000001779a505951df9f9-- From nobody Sun Oct 20 22:05:46 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08AD12002E for ; Sun, 20 Oct 2019 22:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=SVuJRFup; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CS1UnfSm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAfSmynUAfsB for ; Sun, 20 Oct 2019 22:05:41 -0700 (PDT) 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 5C50912002F for ; Sun, 20 Oct 2019 22:05:41 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 77F682016D for ; Mon, 21 Oct 2019 01:05:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 21 Oct 2019 01:05:40 -0400 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=jlfQU5nykcLoF3gOUEHd80Jo2HmTwPeqLlmOj313YP4=; b=SVuJRFup 6oOLEXvXOkaB5MWK/xPGoEVpXt8Z0rBVTn4Hf4z+aur7PzrTblL8K0TjkIVW8Sy2 aMVr2cyScEawPKBJrRRma1snBZlMjynmV+vDTDVPVuAjVf/GpZj2JCEbCXofyOOz E4B4haC6Zyfou77r1nmn/fFk/MK7OklULPKWKhOxwA4mPTAJ917skf9T5PADAvAT EjcmsslDzFmsGxzgPwnAhpzBCGGYp5t0tDwGpQdlQvLlXFi1InxA2ldOFyc+/Cl4 2HfpEbNCBchSJkbTrVmAdHj43b1b2zqnVtdFwZ3rbmRRe0dBRSkD8uTlefOkkIaX 01XEfxVW2Xvutg== 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=jlfQU5nykcLoF3gOUEHd80Jo2HmTw PeqLlmOj313YP4=; b=CS1UnfSm/mObm/9dy92PJdyP4zZ5Pnp9GK3YUH5EigQxJ coR9BfSkbSpH18jhByvRywCIW7dZGywyUqMP+LG6kDpXSUNamMiborVaLOJRlDo0 qtLD5j7DNDu/nc3+LFa+zaKm8iZBRbM9NVg92BWmypQ/bczfmbeGrb0DqK1kbiNX 1vLKgfeoqhSvLJJKox63ercfggsBIkiivZPtXA2qxJY2uVImDMyFG5araeOrX3N5 8tLT0elJ0Tb/uodCPNl779omcIatRgAoUO6Dtpej75JJeZ2aJ6anEjxhg6Vd4DU+ GDKeC32w2D1TyEmFgHBhi+rMSrz0PF9UeiU+9qZ5Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrkeeggdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgsucfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc fkphepgeehrdejledruddufedrudeiheenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedu X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id C91168005C for ; Mon, 21 Oct 2019 01:05:39 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 1277A9E87C for ; Mon, 21 Oct 2019 05:05:39 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============7707653271370235573==" MIME-Version: 1.0 From: Github Notifications To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20191021050539.1277A9E87C@cloud.mnot.net> Date: Mon, 21 Oct 2019 05:05:39 +0000 (UTC) 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, 21 Oct 2019 05:05:45 -0000 --===============7707653271370235573== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+8/-9/=F0=9F=92=AC100) 8 issues created: - HTTP/3 figures caption capitalization (by LPardue) https://github.com/quicwg/base-drafts/issues/3125=20 - Recommend algorithm for packet scheduler, rather than implementation (b= y mikkelfj) https://github.com/quicwg/base-drafts/issues/3122=20 - Recouple QUIC version and ALPN (by MikeBishop) https://github.com/quicwg/base-drafts/issues/3117 [-transport]=20 - Consider HTTP_ prefix on h3 error codes (by martinthomson) https://github.com/quicwg/base-drafts/issues/3116 [-http] [editorial]=20 - Don't use bitmap frames to describe varint structures (by royfielding) https://github.com/quicwg/base-drafts/issues/3115=20 - [Version Ossification] Alternative version and Initial Salt should be p= art of NEW_TOKEN (by kazuho) https://github.com/quicwg/base-drafts/issues/3111=20 - Does a client need to remember SETTINGS it doesn't understand when doin= g 0-RTT resumption? (by nharper) https://github.com/quicwg/base-drafts/issues/3110=20 - Add provisional registration for all registries (by martinthomson) https://github.com/quicwg/base-drafts/issues/3102 [-http] [-transport] = 35 issues received 100 new comments: - #3122 Recommend algorithm for packet scheduler, rather than implementat= ion (2 by ianswett, mikkelfj) https://github.com/quicwg/base-drafts/issues/3122 [-recovery] [editoria= l]=20 - #3116 Consider HTTP_ prefix on h3 error codes (2 by LPardue, royfieldin= g) https://github.com/quicwg/base-drafts/issues/3116 [-http] [editorial]=20 - #3115 Don't use bitmap frames to describe varint structures (2 by David= Schinazi, ianswett) https://github.com/quicwg/base-drafts/issues/3115 [editorial]=20 - #3111 [Version Ossification] Alternative version and Initial Salt shoul= d be part of NEW_TOKEN (4 by kazuho, marten-seemann, martinduke) https://github.com/quicwg/base-drafts/issues/3111=20 - #3110 Does a client need to remember SETTINGS it doesn't understand whe= n doing 0-RTT resumption? (4 by LPardue, RyanAtGoogle, nharper) https://github.com/quicwg/base-drafts/issues/3110=20 - #3101 Alt-Svc and extension equivalence across H2 and H3 (3 by LPardue= , MikeBishop) https://github.com/quicwg/base-drafts/issues/3101=20 - #3100 ACK+PADDING in response to ACK should be illegal (2 by ianswett, = marten-seemann) https://github.com/quicwg/base-drafts/issues/3100 [-transport]=20 - #3097 Is CONNECTION_CLOSE ACK-eliciting? (1 by larseggert) https://github.com/quicwg/base-drafts/issues/3097 [-recovery] [-transpo= rt] [design] [proposal-ready]=20 - #3095 Backoff of CONNECTION_CLOSE needs to be a MUST (5 by janaiyengar,= larseggert, martinthomson) https://github.com/quicwg/base-drafts/issues/3095 [-transport] [design]= =20 - #3094 congestion window increase on every ACKed packet could result in = bursty sends (18 by goelvidhi, huitema, janaiyengar, junhochoi, larseggert) https://github.com/quicwg/base-drafts/issues/3094 [-recovery] [design] = - #3086 Add application parameters to QUIC handshake and use it for H3 SE= TTINGS (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/3086 [-http] [-transport] = [design] [quicv2]=20 - #3078 Lost Server Initial Takes Too Long to be Retransmitted (4 by huit= ema, larseggert, martinthomson) https://github.com/quicwg/base-drafts/issues/3078 [-recovery] [design] = - #3073 Boolean blocked streams setting (5 by afrind, dtikhonov, ianswett) https://github.com/quicwg/base-drafts/issues/3073 [-qpack] [design]=20 - #3062 Disconnect version number from draft number (3 by erickinnear, hu= itema, larseggert) https://github.com/quicwg/base-drafts/issues/3062 [-transport]=20 - #3054 Label for key updates (1 by larseggert) https://github.com/quicwg/base-drafts/issues/3054 [-tls] [design]=20 - #3046 Handling of Retire Prior To field (1 by larseggert) https://github.com/quicwg/base-drafts/issues/3046 [-transport] [design]= [proposal-ready]=20 - #3027 Codes for frame encoding errors (1 by larseggert) https://github.com/quicwg/base-drafts/issues/3027 [-transport] [design]= =20 - #3020 Transport parameter registry is too constraining for innovation (= 2 by DavidSchinazi, larseggert) https://github.com/quicwg/base-drafts/issues/3020 [-transport] [design]= =20 - #3014 Handling of corrupt Retry packets (1 by DavidSchinazi) https://github.com/quicwg/base-drafts/issues/3014 [-transport] [design]= =20 - #3011 Original/Initial Connection ID (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/3011 [-transport] [editori= al]=20 - #2963 What if server does not send HTTP_EARLY_RESPONSE but starts sendi= ng response (3 by MikeBishop, RyanAtGoogle) https://github.com/quicwg/base-drafts/issues/2963 [-http] [editorial]=20 - #2911 Separate HTTP/3 stream errors from connection errors. (1 by MikeB= ishop) https://github.com/quicwg/base-drafts/issues/2911 [-http] [design]=20 - #2909 Path Migration makes unjustified assumptions about a new path. (1= by larseggert) https://github.com/quicwg/base-drafts/issues/2909 [-transport] [editori= al]=20 - #2863 unrecoverable loss pattern leads to deadlock (15 by RyanAtGoogle,= ekr, ianswett, kazuho, martinduke, mikkelfj, nibanks) https://github.com/quicwg/base-drafts/issues/2863 [-transport] [design]= [proposal-ready]=20 - #2823 Do Initial secrets change after Retry packet? (1 by mnot) https://github.com/quicwg/base-drafts/issues/2823 [-tls] [design]=20 - #2817 Guidance for propogation of errors between H2 and H3 (1 by MikeBi= shop) https://github.com/quicwg/base-drafts/issues/2817 [-http]=20 - #2792 Timing side-channel on key updates (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2792 [-tls] [design]=20 - #2787 HTTP/3 has less concurrency than HTTP/2 (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2787 [-http]=20 - #2783 Consider making SETTINGS part of the control stream header (1 by = LPardue) https://github.com/quicwg/base-drafts/issues/2783 [-http]=20 - #2755 ECN Algorithm (2 by janaiyengar, larseggert) https://github.com/quicwg/base-drafts/issues/2755 [-transport] [editori= al]=20 - #2741 Re-visit initial keys discard (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2741 [-tls] [-transport] [= design]=20 - #2632 H3 GOAWAY should be symmetric and cover bidi and uni streams (1 b= y MikeBishop) https://github.com/quicwg/base-drafts/issues/2632 [-http] [design]=20 - #2555 Define idle period for congestion control (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2555 [-recovery] [design] = - #2496 QUIC Version Ossification (4 by DavidSchinazi, RyanAtGoogle, kazu= ho) https://github.com/quicwg/base-drafts/issues/2496 [-transport] [design]= =20 - #2143 Be more conservative about migration? (3 by erickinnear, larsegge= rt, mikkelfj) https://github.com/quicwg/base-drafts/issues/2143 [-transport] [design]= =20 9 issues closed: - http: Allow unquoted tokens in Alt-Svc quic parameter https://github.co= m/quicwg/base-drafts/issues/3063 [-http]=20 - Unclear what to do when QUIC Version Hints are missing https://github.c= om/quicwg/base-drafts/issues/3061 [-http]=20 - Consider making SETTINGS part of the control stream header https://gith= ub.com/quicwg/base-drafts/issues/2783 [-http]=20 - Boolean blocked streams setting https://github.com/quicwg/base-drafts/i= ssues/3073 [-qpack] [design]=20 - Separate HTTP/3 stream errors from connection errors. https://github.co= m/quicwg/base-drafts/issues/2911 [-http] [design]=20 - Add application parameters to QUIC handshake and use it for H3 SETTINGS= https://github.com/quicwg/base-drafts/issues/3086 [-http] [-transport] [de= sign] [quicv2]=20 - Alt-Svc and extension equivalence across H2 and H3 https://github.com/= quicwg/base-drafts/issues/3101=20 - Original/Initial Connection ID https://github.com/quicwg/base-drafts/is= sues/3011 [-transport] [editorial]=20 - Disconnect version number from draft number https://github.com/quicwg/b= ase-drafts/issues/3062 [-transport]=20 Pull requests ------------- * quicwg/base-drafts (+16/-3/=F0=9F=92=AC18) 16 pull requests submitted: - Rephrase #2780 to active voice (by MikeBishop) https://github.com/quicwg/base-drafts/pull/3124 [-http] [editorial]=20 - Require clients to keep sending if they want to keep receiving (by Mike= Bishop) https://github.com/quicwg/base-drafts/pull/3123 [-http] [editorial]=20 - Forbid Handshake key discarding (by martinthomson) https://github.com/quicwg/base-drafts/pull/3121 [-tls] [design]=20 - Add retry integrity tag (by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/3120=20 - rename HTTP_ error code prefix to H3_ (by LPardue) https://github.com/quicwg/base-drafts/pull/3119=20 - Remove QUIC version hint (by martinthomson) https://github.com/quicwg/base-drafts/pull/3118 [-http] [design]=20 - Talk about concurrency in H3 vs. H2 (by MikeBishop) https://github.com/quicwg/base-drafts/pull/3114 [-http] [editorial]=20 - Clarify that clients don't need to remember unknown SETTINGS (by nharpe= r) https://github.com/quicwg/base-drafts/pull/3113=20 - TLS overview tweaks (by seanturner) https://github.com/quicwg/base-drafts/pull/3112 [-tls] [editorial]=20 - Change transport parameter IANA registration policy (by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/3109=20 - Replace use of the TLS presentation language with QUIC encoding (by Dav= idSchinazi) https://github.com/quicwg/base-drafts/pull/3108=20 - Immediately close with INVALID_TOKEN (by ianswett) https://github.com/quicwg/base-drafts/pull/3107 [-transport]=20 - MUST pace or limit bursts to 10 packets (by ianswett) https://github.com/quicwg/base-drafts/pull/3106=20 - Alternative > alternate (by martinthomson) https://github.com/quicwg/base-drafts/pull/3105 [-recovery] [editorial]= =20 - Prohibit PADDING in response to ACK (by martinduke) https://github.com/quicwg/base-drafts/pull/3104=20 - Prohibit PADDING in response to ACK (by martinduke) https://github.com/quicwg/base-drafts/pull/3103=20 10 pull requests received 18 new comments: - #3121 Forbid Handshake key discarding (3 by mikkelfj, nibanks) https://github.com/quicwg/base-drafts/pull/3121 [-tls] [design]=20 - #3108 Replace use of the TLS presentation language with QUIC encoding (= 1 by mikkelfj) https://github.com/quicwg/base-drafts/pull/3108 [-tls] [-transport]=20 - #3107 Immediately close with INVALID_TOKEN (3 by ianswett, nibanks) https://github.com/quicwg/base-drafts/pull/3107 [-transport]=20 - #3106 MUST pace or limit bursts to 10 packets (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/3106 [-recovery]=20 - #3103 Prohibit PADDING in response to ACK (3 by janaiyengar, martinduke) https://github.com/quicwg/base-drafts/pull/3103=20 - #3092 MUST ACK each ack-eliciting packet once (2 by mikkelfj) https://github.com/quicwg/base-drafts/pull/3092 [-transport]=20 - #3087 Make transport parameters varint (1 by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/3087 [-transport] [design]=20 - #3042 Use the FRAME_ENCODING_ERROR for errors in frame encoding (1 by k= azuho) https://github.com/quicwg/base-drafts/pull/3042 [-transport] [design]=20 - #2958 Move server's SETTINGS to transport parameters (2 by nharper) https://github.com/quicwg/base-drafts/pull/2958 [-http] [-transport]=20 - #2925 Add initial threat model to security considerations (1 by erickin= near) https://github.com/quicwg/base-drafts/pull/2925 [-transport] [editorial= ]=20 3 pull requests merged: - Remove QUIC version hint https://github.com/quicwg/base-drafts/pull/3118 [-http] [design]=20 - MUST pace or limit bursts to 10 packets https://github.com/quicwg/base-drafts/pull/3106 [-recovery]=20 - Alternative > alternate https://github.com/quicwg/base-drafts/pull/3105 [-recovery] [editorial]= =20 Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============7707653271370235573== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Monday October 21, 2019

Issues

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

8 issues created:

35 issues received 100 new comments:

9 issues closed:

Pull requests

quicwg/base-drafts (+16/-3/=F0=9F=92=AC18)

16 pull requests submitted:

10 pull requests received 18 new comments:

3 pull requests merged:

Repositories tracked by this digest:

--===============7707653271370235573==-- From nobody Mon Oct 21 16:54:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51F2120A7E for ; Mon, 21 Oct 2019 16:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=tSO1Dcid; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ajbEEDxt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uG_94-6of78 for ; Mon, 21 Oct 2019 16:54:47 -0700 (PDT) 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 617DE120A7A for ; Mon, 21 Oct 2019 16:54:47 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id CB14C41B; Mon, 21 Oct 2019 19:54:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 21 Oct 2019 19:54:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm1; bh=FSaaYdnh3cUvSK5o0wPeG+isENOoCc 07XgeCCXDOmtE=; b=tSO1DcidpmCw1tx6mkQ+pQ7v8C8OxuMdiEGu8xzz0OUb80 eCg2UyHFuiTIBO4S0G3xS7cWkmKtn2IJHkUbaDIxbFxlNcljFKsj2VC8Z96UpZw0 NWa816QBqg/H1iUsbP2U/zhBl6jGFzGV45nrGOkdVDMczC9QE2iUdEJ3HqT2ejoz 9II0HFnjUa+k9cIqU/jtbKdsnTE943gKszb5NpyLv+eZ0KfeuTmdvxcfVABYDWUe jiY/hbCwx/IVBXcpVQ0ecjziWXqCKxi5tMcGCo1rtLtNIjA9Iz4JSH9HJ/0zIQN3 hb8GcMtbVWS35hObIbEVCuZnbN5lpwNMtm8l60zw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=FSaaYd nh3cUvSK5o0wPeG+isENOoCc07XgeCCXDOmtE=; b=ajbEEDxt4GpRYNwB/0iu1o gChtsRTdv48Gyt/ykefYbTxD/a11TZ6cYPDE5v4EEHVn0aei1UsAdKGawMpreH4X MHCyMQVpB29rnTRWkds0qe/3jLpGTLQ4ufoqu9Kyg5YcpK500K/UN60JpoAiIWgM 622DTEbu1kRQiU4MdKGnuzh2CbKPMVZMBljSfSPrjHkeyEw8yedIiqUonYZ8J/J9 /dwMDcvciD8EpeB48RqdsXcGKf2nBE9XDES8Rnqa2Luz0L4ZcBILP+xrujV6jNVa li2Ai0rJ51K+0kQabzLCHdb+VK9+7G8bqbTCiAF4QburQttkgq/jC6HorAMfVfAw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrkeeigddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhtgfgggfukfffvffosehtjehmtdhhtddvnecuhfhrohhmpeforghrkhcupfho thhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgih hthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppeduvddurddvtddtrdeirddvvdei necurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluh hsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (121-200-6-226.79c806.syd.nbn.aussiebb.net [121.200.6.226]) by mail.messagingengine.com (Postfix) with ESMTPA id 31CC98005A; Mon, 21 Oct 2019 19:54:43 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: DRAFT minutes for the Cupertino interim Message-Id: <51B26471-FB95-422A-B97F-5BA4AA8660A5@mnot.net> Date: Tue, 22 Oct 2019 10:54:40 +1100 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3594.4.19) 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, 21 Oct 2019 23:54:49 -0000 ... are available at: https://github.com/quicwg/wg-materials/blob/master/interim-19-10/minutes.md As always, corrections appreciated, either as Pull Requests or e-mail. Thanks again to our scribes and hosts. -- Mark Nottingham https://www.mnot.net/ From nobody Mon Oct 21 17:42:23 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F591120A87 for ; Mon, 21 Oct 2019 17:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=e3PcjFjK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GIBpBWQN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAtZ3GQbu6nH for ; Mon, 21 Oct 2019 17:42:19 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03455120A8E for ; Mon, 21 Oct 2019 17:42:19 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5D0E621AB4; Mon, 21 Oct 2019 20:42:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 21 Oct 2019 20:42:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm1; bh=dzxkf+Nv/v7avMapOx44Bt5MFqbcH1 MdZa1uf15IhlQ=; b=e3PcjFjK0B5zXcZzPrxwTiXzc6hnb/U700x6Dia3FdfaSr VoM8qh24q5JbYXGJQeiSxR8q01YWdwweLlZonA5KBrqi7Qm80toPbqzaSfLYHN6l Y3fWh62WdBzYEHIn9F1IjHLuK1eWhRb0R0Kamv+RqeOZ+xbDUzjZZIWmJ8/kOYke ji8TpXJ3mrJ/OGJ2CL+KlNPbCoCoBItWwCfB6Dtc9qAjrA13qOc29MGM4CfA6yTp gxh0aVE9AEr+LQPbEYAY3RpWWMYnDad2octpDc7QTFn6exqWuitWoRyFKrDkCNhW J+Fq0oCNd6CYLnWOJoFx4iEqK7fR0/KbFgwFUVRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=dzxkf+ Nv/v7avMapOx44Bt5MFqbcH1MdZa1uf15IhlQ=; b=GIBpBWQN69x0jGidAzJ7p+ SWViN/Z2qnORDILKlHCUeBgisWjh1Wc+2tYQOmmqZJVzxmWMlWIynlPBA5KG6mQa osy0aDfA7nivvOelhumyVYz6jDHSbpjtlbruTJ564GIEvHvjUmVboedmA3oznmwO qU2DumxfCeounbPwNjuaaPXR4i4cFcxMBeOHNvJ0SJOlHcnCxKeREU1aDDdwUyEC c1azoMIfLHJDVqhkov4UQ5122RiWKeNiSkmsRnlNGJEEGTaFqakc0fWY897xoiOt 1AzqvFwLUd8CajQXy8VeCsEqIabgfHoDLnL6D5wFIL0p8k0VAOSfM92Kz5AXmqOg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrkeeigdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhtgfgggfukfffvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfho thhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgih hthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppeduvddurddvtddtrdeirddvvdei necurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluh hsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (121-200-6-226.79c806.syd.nbn.aussiebb.net [121.200.6.226]) by mail.messagingengine.com (Postfix) with ESMTPA id 2415B80059; Mon, 21 Oct 2019 20:42:15 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Consensus Calls for Transport/TLS issues, post-Cupertino Message-Id: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> Date: Tue, 22 Oct 2019 11:42:13 +1100 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3594.4.19) 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, 22 Oct 2019 00:42:21 -0000 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 next week. See for the current = state of issues in the Late Stage process, itself defined at = . * #3097: Is CONNECTION_CLOSE ACK-eliciting? The proposal is * #3085: Stateless reset detection should be datagram-based The proposal is * #3054: Label for key updates The proposal is * #3046: Handling of Retire Prior To field The proposal is * #3037: Require peers to check if RETIRE_CONNECTION_ID sequence number = is valid The proposal is * #3027: Codes for frame encoding errors The proposal is * #2944: Layout of PreferredAddress The proposal is to close with no action. * #2928: Lift single-packet ClientHello requirement? The proposal is * #2863: unrecoverable loss pattern leads to deadlock The proposal is =20 * #2823: Do Initial secrets change after Retry packet? The proposal is * #2741: Re-visit initial keys discard The proposal is to close with no action. * #2152: Why does stateless reset have to be checked after MAC failure The proposal is -- Mark Nottingham https://www.mnot.net/ From nobody Mon Oct 21 18:31:28 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15621120AA0 for ; Mon, 21 Oct 2019 18:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt1P-W0GFzlM for ; Mon, 21 Oct 2019 18:31:25 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37CC120ABF for ; Mon, 21 Oct 2019 18:31:24 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id y3so15339703ljj.6 for ; Mon, 21 Oct 2019 18:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eHACB4/5NSWO+u866EyzTkFwN0tMRdmUc2SV4ZDRm9k=; b=QOB9IGZURXCbcGHrZHjbA4rALU831kM4maq3dRoL6T1EE9HL8zT1oInlh8UbXF7eCz jkmMR0vknCYS0CVlG9VQS+BmBRGnjZWXBaK5MXTbHILs2KxprW5lPOrfdRVi8/ha7eI9 ZfgDQtjS1nPU3/0xLyB7H1e/uoKtKHB/y7be1r6F+/VkuEXrEY6DGYJBI9at4fZt+dtM bvPAjhr1Y8xtAwi7uXXpxt67AA/1KMNJVVEihFmkqXqclFe/UQiLo/9msfSkk5MxpTTA D2aE3SrXV6Fhlcc3RlG07KDa+A0hg6QbY3ZFBZPu3ZoNLD+y7iC1ZJ27vKrDz2xn8aRO wJlQ== 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=eHACB4/5NSWO+u866EyzTkFwN0tMRdmUc2SV4ZDRm9k=; b=Wd4GF3LxaWvd/nf3EsAnScCaPtJgzeXK4TYFOIcFtSiKt0LLAVgKKoTslZzto3XsHF SqRu8X2GdfKEN3cwFTfhsd4pzZL3wNLdZA1Q1XAaZH0xwKUtCbmbTqGLcWRIw6tQ3DYT 7DIwGwxOFnrC7vapLXQeMp6cr6qN3McDXwWgFH2glAR91/Q2XafXQ+246oRTk6FwENEb v1goO/OU9kGIcZ1z23Hd3wLxP89uhHZXn9UGuFR/7lpHulttrZC9Lmw/TjhsQndY3AeS 95WM7hKOEZb6liyMuudUWx1fq3RE/cYZG8v3+QDlc8qwwo416cStfbxsJOMZ4JwSLl9u yhrw== X-Gm-Message-State: APjAAAXB6kkT7Gv2YuUUPsu5DHMi1Vtg+0KtTCDQ1HVgD2Yq50PMTcm6 z/yQHTmmkuOvHumvT2IzTB/vpyCiZZ0rOzAnA4hcmg== X-Google-Smtp-Source: APXvYqzN+FuW3VdD3Y52qpvJN668foCixDfJz/3JPbrsodQ5M+sVJ7RNvOygK8ISXOMDcjjv2vixW3xXGCtX2Q2aLTA= X-Received: by 2002:a2e:3c05:: with SMTP id j5mr17265942lja.24.1571707882950; Mon, 21 Oct 2019 18:31:22 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> In-Reply-To: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> From: Kazuho Oku Date: Tue, 22 Oct 2019 10:31:11 +0900 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Mark Nottingham Cc: IETF QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="0000000000000dd74c059575c24e" 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, 22 Oct 2019 01:31:27 -0000 --0000000000000dd74c059575c24e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2019=E5=B9=B410=E6=9C=8822=E6=97=A5(=E7=81=AB) 9:42 Mark Nottingham : > 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 next week. > > 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>. > > * #3097: Is CONNECTION_CLOSE ACK-eliciting? > The proposal is > > * #3085: Stateless reset detection should be datagram-based > The proposal is > > * #3054: Label for key updates > The proposal is > > * #3046: Handling of Retire Prior To field > The proposal is > > * #3037: Require peers to check if RETIRE_CONNECTION_ID sequence number i= s > valid > The proposal is > > * #3027: Codes for frame encoding errors > The proposal is > > * #2944: Layout of PreferredAddress > The proposal is to close with no action. > > * #2928: Lift single-packet ClientHello requirement? > The proposal is > > * #2863: unrecoverable loss pattern leads to deadlock > The proposal is > I feel sorry but I object to the proposed approach. As I have pointed out in my comments in #2863, not discarding the Handshake key forever breaks our assumption that no Handshake packets will be sent or received once the handshake is confirmed. We missed that there are these side effects when we rush to the conclusion at the end of the interim. Specifically, we'd be required to define how Handshake packets deal with migration (does the path for Handshake packets change? If it does, how do we fill in the SCID field of the Handshake packet? If it does not, until when do the endpoints need to retain the original path?). I think we should fix the deadlock, rather than changing other parts of the protocol that currently depend on the Handshake key being discarded at some point. > > * #2823: Do Initial secrets change after Retry packet? > The proposal is > > * #2741: Re-visit initial keys discard > The proposal is to close with no action. > > * #2152: Why does stateless reset have to be checked after MAC failure > The proposal is > > -- > Mark Nottingham https://www.mnot.net/ > > --=20 Kazuho Oku --0000000000000dd74c059575c24e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
2019=E5=B9=B410=E6=9C=8822=E6=97=A5(= =E7=81=AB) 9:42 Mark Nottingham <mnot@m= not.net>:
The following issues have propos= als for resolution, and discussion so far seems to support consensus to acc= ept them. If you object, please do so on the issue or in response to this m= essage (changing the Subject appropriately!). Absent any pushback, we'l= l direct the editors to incorporate them next week.

See <https://github.com/quicwg/base-drafts/projec= ts/5> for the current state of issues in the Late Stage process, its= elf defined at <https://github.c= om/quicwg/base-drafts/blob/master/CONTRIBUTING.md>.

* #3097: Is CONNECTION_CLOSE ACK-eliciting?
=C2=A0 =C2=A0The proposal is <https://github.com= /quicwg/base-drafts/issues/3097>

* #3085: Stateless reset detection should be datagram-based
=C2=A0 =C2=A0The proposal is <https://github.com/q= uicwg/base-drafts/pull/2993>

* #3054: Label for key updates
=C2=A0 =C2=A0The proposal is <https://github.com/q= uicwg/base-drafts/pull/3050>

* #3046: Handling of Retire Prior To field
=C2=A0 =C2=A0The proposal is <https://github.com/q= uicwg/base-drafts/pull/3096>

* #3037: Require peers to check if RETIRE_CONNECTION_ID sequence number is = valid
=C2=A0 =C2=A0The proposal is <https://github.com/q= uicwg/base-drafts/pull/3036>

* #3027: Codes for frame encoding errors
=C2=A0 =C2=A0The proposal is <https://github.com/q= uicwg/base-drafts/pull/3042>

* #2944: Layout of PreferredAddress
=C2=A0 =C2=A0The proposal is to close with no action.

* #2928: Lift single-packet ClientHello requirement?
=C2=A0 =C2=A0The proposal is <https://github.com/q= uicwg/base-drafts/pull/3045>

* #2863: unrecoverable loss pattern leads to deadlock
=C2=A0 =C2=A0The proposal is <https://github.com/q= uicwg/base-drafts/pull/3121>

I f= eel sorry but I object to the proposed approach. As I have pointed out in m= y comments in #2863, not discarding the Handshake key forever breaks our as= sumption that no Handshake packets will be sent or received once the handsh= ake is confirmed. We missed that there are these side effects when we rush = to the conclusion at the end of the interim.

Speci= fically, we'd be required to define how Handshake packets deal with mig= ration (does the path for Handshake packets change? If it does, how do we f= ill in the SCID field of the Handshake packet? If it does not, until when d= o the endpoints need to retain the original path?).

I think we should fix the deadlock, rather than changing other parts of t= he protocol that currently depend on the Handshake key being discarded at s= ome point.
=C2=A0

* #2823: Do Initial secrets change after Retry packet?
=C2=A0 =C2=A0The proposal is <https://github.com/q= uicwg/base-drafts/pull/2870>

* #2741: Re-visit initial keys discard
=C2=A0 =C2=A0The proposal is to close with no action.

* #2152: Why does stateless reset have to be checked after MAC failure
=C2=A0 =C2=A0The proposal is <https://github.com/q= uicwg/base-drafts/pull/2993>

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



--
Kazuho Oku
--0000000000000dd74c059575c24e-- From nobody Mon Oct 21 18:39:32 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1588120ACF for ; Mon, 21 Oct 2019 18:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 XD9GFs-cImJu for ; Mon, 21 Oct 2019 18:39:26 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650133.outbound.protection.outlook.com [40.107.65.133]) (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 21E8A120ABF for ; Mon, 21 Oct 2019 18:39:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hsp2DAuQaNZowh3Wkk+ZO9VvN+MHj0p0IQ1oEC0IU56IZrpF84GkBqRQTV1zp5CFQcHiaCZQo5k6rsY7SQeVEv7jSQZSHxk1dnvA5pXh/W/U4VSVJLfQ7OdW417xOrn/5IKqwtrzG52IW9wk+/zrQ3BsaBk3DZfBDn7K+Kn2JGBwcdzysyjm+9eX2DzZMTaLKdhpvB282fXbxxPH0fpIogw8pNTcqM25Gv/a0R5Gtazu0/3cVmiVxAKZHYniYnk9nX8MEMv3viO0qehhevGD8Z6j3GofDag2GZYWrPp1QAZIXDrwbZzlzBsTzUBfvrkJ7wL+5v/4IsOXX+Olxf8kvg== 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=W5/HtlDFsUYknv7mihzE9bWr5/UC34ws8WlBgOQjJCM=; b=OnYopNLjxcQgIY6v4Gu3zvKTfprH6jmJYXchdkpOomEfGxVHNafOEodAYbGGS7P930IgOh3c1VBLqwy8d4N5xLc6N3TH1iRgX+sYNczQvd6rIYQXyGVLGYt+UgndO/62pIWrM+BT+o5lcXgcAOx6P/t5hj7cyeaEXF0liW78+Auj1itO+by3ZHXPCP4HkCikkpFgH/xX43s77oIzyCe8WMZJnYjpen4368w/mEfw6Bynfw9Sk9dEWVJFrx4Jo6yydsEY8yRR/SgTlxVgoELaToYQ6PVywrVgtXcHJBUeFkeJMiHhZMIwFQX3yNfP88Fm8BYk0dMlmHw3cR3aiJ2a3A== 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=W5/HtlDFsUYknv7mihzE9bWr5/UC34ws8WlBgOQjJCM=; b=X+0sweuBSzskZi7ulX1y4LrqDWcO/aNnAzhjFx0rVvslUuOk3djVG3YAk5ggP0wYFAsueCy9/e2CDUmFci/d7kfaeQ+CpjXNAcE6LUnWAhSoZi1lTrm3G00OpApioQ1BwBkucFwCzcHgOlwIcn36bla1illbkfnj9uzpb2cK8Yk= Received: from BN3PR00MB0083.namprd00.prod.outlook.com (10.167.6.147) by BN3PR00MB0193.namprd00.prod.outlook.com (10.167.6.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.2399.0; Tue, 22 Oct 2019 01:39:23 +0000 Received: from BN3PR00MB0083.namprd00.prod.outlook.com ([fe80::793e:ff6e:5d6a:c8cb]) by BN3PR00MB0083.namprd00.prod.outlook.com ([fe80::793e:ff6e:5d6a:c8cb%9]) with mapi id 15.20.2403.000; Tue, 22 Oct 2019 01:39:22 +0000 From: Nick Banks To: Kazuho Oku , Mark Nottingham CC: Lars Eggert , IETF QUIC WG Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino Thread-Topic: Consensus Calls for Transport/TLS issues, post-Cupertino Thread-Index: AQHViHGZrlM8wQ569EKq+7NqZ8qSlqdl3+KAgAAB9KM= Date: Tue, 22 Oct 2019 01:39:22 +0000 Message-ID: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net>, 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=nibanks@microsoft.com; x-originating-ip: [24.113.13.203] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 398c02b2-82f3-405a-ed3f-08d75690aa5c x-ms-traffictypediagnostic: BN3PR00MB0193: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(136003)(376002)(396003)(366004)(39860400002)(199004)(189003)(7736002)(2906002)(54906003)(8676002)(81156014)(22452003)(6436002)(81166006)(256004)(476003)(8936002)(3846002)(6116002)(76116006)(606006)(110136005)(186003)(26005)(316002)(66556008)(486006)(66446008)(64756008)(66946007)(66476007)(86362001)(14444005)(11346002)(561944003)(91956017)(446003)(71200400001)(71190400001)(74316002)(8990500004)(99286004)(4326008)(10290500003)(55016002)(54896002)(102836004)(14454004)(33656002)(6246003)(6306002)(53546011)(6506007)(229853002)(478600001)(966005)(76176011)(25786009)(10090500001)(7696005)(52536014)(9686003)(66066001)(236005)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR00MB0193; H:BN3PR00MB0083.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: uBj8wxWImS0CWRTJxVu99oRttGmI5ww2nklgREw64w4gYKoU3sBZo8axN1DgIfqGNpcfPZGDinh/ViOHSE9i/hGnUdfuwwCowsVeVdsN8U/+BLubr7jL2u33TXbX0pZ9A/2UWF0tHlfYk/mnaUwQBNabpsZUs/0oFldfiRD9s8W4rxMRPy022WSF6S99CzVwGWltWk55sHt/k0/JZVdVhdCsP5cBUJ3Ok6kIICd2sPen/lpbxbrNwoNi+Wm3UKL+CbtvccMTGyezY8ZlTJbc/C8FkuhZJzm4iDbS/c5uamcwNeY/A55WYtVpKL86zgq+w5CUA2oL5pVGHmqTmiOu4ShhCAL7koZOpF8qWs2WasIPMJyOhiM9VM8CMOzZWgE9uxACFf04fIvi6wBJv0swxk7QkVRidhH6JODIyUbT5uk= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN3PR00MB0083E9A10A58F4CCC7B8A5C6B3680BN3PR00MB0083namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 398c02b2-82f3-405a-ed3f-08d75690aa5c X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2019 01:39:22.7361 (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: QSzR3CuQkP6OoTjBwd2DLJrs/rL7rS638VKZxyO3cOK1lgIPUwLCHfq1LqXRsbuLxtnROgD2EfU5hf3sU0CHPg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR00MB0193 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, 22 Oct 2019 01:39:31 -0000 --_000_BN3PR00MB0083E9A10A58F4CCC7B8A5C6B3680BN3PR00MB0083namp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable I'd also prefer to fix the problem, even if it means bringing back somethin= g like RETIRE_KEY. - Nick Get Outlook for Android ________________________________ From: QUIC on behalf of Kazuho Oku Sent: Monday, October 21, 2019 6:31:11 PM To: Mark Nottingham Cc: Lars Eggert ; IETF QUIC WG Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino 2019=1B$BG/=1B(B10=1B$B7n=1B(B22=1B$BF|=1B(B(=1B$B2P=1B(B) 9:42 Mark Nottin= gham >: The following issues have proposals for resolution, and discussion so far s= eems to support consensus to accept them. If you object, please do so on th= e issue or in response to this message (changing the Subject appropriately!= ). Absent any pushback, we'll direct the editors to incorporate them next w= eek. See > for the current state of issues in the Late Stage process, itself= defined at >. * #3097: Is CONNECTION_CLOSE ACK-eliciting? The proposal is > * #3085: Stateless reset detection should be datagram-based The proposal is > * #3054: Label for key updates The proposal is > * #3046: Handling of Retire Prior To field The proposal is > * #3037: Require peers to check if RETIRE_CONNECTION_ID sequence number is = valid The proposal is > * #3027: Codes for frame encoding errors The proposal is > * #2944: Layout of PreferredAddress The proposal is to close with no action. * #2928: Lift single-packet ClientHello requirement? The proposal is > * #2863: unrecoverable loss pattern leads to deadlock The proposal is > I feel sorry but I object to the proposed approach. As I have pointed out i= n my comments in #2863, not discarding the Handshake key forever breaks our= assumption that no Handshake packets will be sent or received once the han= dshake is confirmed. We missed that there are these side effects when we ru= sh to the conclusion at the end of the interim. Specifically, we'd be required to define how Handshake packets deal with mi= gration (does the path for Handshake packets change? If it does, how do we = fill in the SCID field of the Handshake packet? If it does not, until when = do the endpoints need to retain the original path?). I think we should fix the deadlock, rather than changing other parts of the= protocol that currently depend on the Handshake key being discarded at som= e point. * #2823: Do Initial secrets change after Retry packet? The proposal is > * #2741: Re-visit initial keys discard The proposal is to close with no action. * #2152: Why does stateless reset have to be checked after MAC failure The proposal is > -- Mark Nottingham https://www.mnot.net/ -- Kazuho Oku --_000_BN3PR00MB0083E9A10A58F4CCC7B8A5C6B3680BN3PR00MB0083namp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
I'd also prefer to fix the problem, even if it means bringing back somethin= g like RETIRE_KEY.

- Nick

From: QUIC <quic-bounces= @ietf.org> on behalf of Kazuho Oku <kazuhooku@gmail.com>
Sent: Monday, October 21, 2019 6:31:11 PM
To: Mark Nottingham <mnot@mnot.net>
Cc: Lars Eggert <lars@eggert.org>; IETF QUIC WG <quic@ietf.= org>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertin= o
 


2019=1B$BG/=1B(B10=1B$B7n=1B(B22=1B= $BF|=1B(B(=1B$B2P=1B(B) 9:42 Mark Nottingham <mnot@mnot.net>:
The following issues have proposals for resolution, and discussion so far s= eems to support consensus to accept them. If you object, please do so on th= e issue or in response to this message (changing the Subject appropriately!= ). Absent any pushback, we'll direct the editors to incorporate them next week.

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

* #3097: Is CONNECTION_CLOSE ACK-eliciting?
   The proposal is <https://github.com/quicwg/base-drafts/issues/3097>
* #3085: Stateless reset detection should be datagram-based
   The proposal is <https://github.com/quicwg/base-drafts/pull/2993>

* #3054: Label for key updates
   The proposal is <https://github.com/quicwg/base-drafts/pull/3050>

* #3046: Handling of Retire Prior To field
   The proposal is <https://github.com/quicwg/base-drafts/pull/3096>

* #3037: Require peers to check if RETIRE_CONNECTION_ID sequence number is = valid
   The proposal is <https://github.com/quicwg/base-drafts/pull/3036>

* #3027: Codes for frame encoding errors
   The proposal is <https://github.com/quicwg/base-drafts/pull/3042>

* #2944: Layout of PreferredAddress
   The proposal is to close with no action.

* #2928: Lift single-packet ClientHello requirement?
   The proposal is <https://github.com/quicwg/base-drafts/pull/3045>

* #2863: unrecoverable loss pattern leads to deadlock
   The proposal is <https://github.com/quicwg/base-drafts/pull/3121>

I feel sorry but I object to the proposed approach. As I have pointed = out in my comments in #2863, not discarding the Handshake key forever break= s our assumption that no Handshake packets will be sent or received once th= e handshake is confirmed. We missed that there are these side effects when we rush to the conclusion at the en= d of the interim.

Specifically, we'd be required to define how Handshake packets deal wi= th migration (does the path for Handshake packets change? If it does, how d= o we fill in the SCID field of the Handshake packet? If it does not, until = when do the endpoints need to retain the original path?).

I think we should fix the deadlock, rather than changing other parts o= f the protocol that currently depend on the Handshake key being discarded a= t some point.
 

* #2823: Do Initial secrets change after Retry packet?
   The proposal is <https://github.com/quicwg/base-drafts/pull/2870>

* #2741: Re-visit initial keys discard
   The proposal is to close with no action.

* #2152: Why does stateless reset have to be checked after MAC failure
   The proposal is <https://github.com/quicwg/base-drafts/pull/2993= >

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



--
Kazuho Oku
--_000_BN3PR00MB0083E9A10A58F4CCC7B8A5C6B3680BN3PR00MB0083namp_-- From nobody Mon Oct 21 19:38:47 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D234120AEC for ; Mon, 21 Oct 2019 19:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Grv77A+9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y1qdK7IG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-tqyzQWkrUw for ; Mon, 21 Oct 2019 19:38:43 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE587120024 for ; Mon, 21 Oct 2019 19:38:43 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id DA3B56A0 for ; Mon, 21 Oct 2019 22:38:42 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 21 Oct 2019 22:38:42 -0400 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=fm3; bh=PITt/INuBtg3q0t5LuN+CdGpGK14U2O hFMT70ruBwJU=; b=Grv77A+9u+NbSQ6RT/m0x62wRRzIkWiBkMs/4Qx9ErMig7G hrg/sCDDaF/Tvxde2rCbHTPpzInnqtitvNdrYd2A5p8qptb1D5yUZFv2VJJvnL3F CReggYuNUgU0pWi2yhSoeIn74utrbYQzs0nAGoysLEreu7TjFiSeDjFczU0tqrpL l/wzZU+CktcURsCIKX2K9CZdKxIeHvT2BG/+ERnfwYRK18zW5NJYD9sLEIxI+z+a UoC6CAsqy5e50jxawr1+tbfTnMPw06RtpYYL3n4GgQyNV0g0vX7I9AJ6QG7CKlU7 bmLEfmkDCa1b//OIJE2QW2mfWfdJbo3bHJyK3/A== 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=fm1; bh=PITt/I NuBtg3q0t5LuN+CdGpGK14U2OhFMT70ruBwJU=; b=Y1qdK7IGkeQ10qPMs3LBpW I14F616r3j+GP5G9EzbcLyU80Y69K3NUQ8x+4lC37qV5X8xFxg/rOivjnXAHj+Xq AdAXBnwQA1vgOuuujcsed5l0NlkDQEhuZKnd8LTrKKJ8vpYzb12FE95YX5zDpXc8 OOxwxPTDHQOqvRWryZJaorSiljGpCAhqsOSmjG7OZdxnCHPVPX6M906BLb8hO3xc NqO1Xe8yuajBbBoSdGpxbty41mItf2Zg1G9ADYaWHMvQtZqa1koMSDkK3bIU2OIv I0FjkFqwGiBM79GAcZLG55sGDr9q8IJ533nRF/eljuGvnblXqTTkR/3biC06Id5Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrkeeigdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F1200E00BB; Mon, 21 Oct 2019 22:38:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> In-Reply-To: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> Date: Tue, 22 Oct 2019 13:38:23 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino 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: Tue, 22 Oct 2019 02:38:45 -0000 On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote: > I'd also prefer to fix the problem, even if it means bringing back > something like RETIRE_KEY. I would prefer to think of this proposed resolution as a temporary one. I don't think that we agreed to keep the handshake keys indefinitely, only that we would use that option as a fallback position until we found a better solution. On that basis, I think that it would be best if we open a new issue that says "Handshake keys can't ever be dropped". We might still conclude not to address that issue, but the important thing is to ensure that any solution works properly. From nobody Mon Oct 21 21:57:55 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D60D120AF3 for ; Mon, 21 Oct 2019 21:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWzoUD-_OvDp for ; Mon, 21 Oct 2019 21:57:51 -0700 (PDT) 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 2A781120074 for ; Mon, 21 Oct 2019 21:57:51 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id q78so529415lje.5 for ; Mon, 21 Oct 2019 21:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XqiM0HN6IA1QK6KSpnz+yjS83oh7ngsvNUm+33XsJy4=; b=Q4v8n98niq92lH7PvdMlI9oR1JpnOty9X2WWC+FuIYe4gf7fBgR5P03+uzylsNajxI HbgCkwtwDOp3eZ8RIW6ADXiaEXw8sKvzdxkX0IESLhz/+Sj7yy4z1N+Sc5nq9z81vmJw 2n0MOiCiP02d4DSP5LttLdH/VaJynIrgV6BovusaG+hTs6GcFGFgw8bFr3KE04OHGFY2 P52918ySLAoJ7++NI/OZvhZRE1cZ2eGgzZn4snwEIjyK++IfBa6O9WL11um7/OwdW5Le uoKEsWS/Uck38Bslg6XHA0ai+0Qd2hdrY7mDYWjl7U8L1H2ZOS0xogFMk7RtkRl688BK YbTw== 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=XqiM0HN6IA1QK6KSpnz+yjS83oh7ngsvNUm+33XsJy4=; b=D5EkSkbNyHoYlRxlacMt6dckNCAod7ofSbBLz/BrQ0Qq7ADVOUGw+xStMgdpvHb2fK INs8Z2D7/lkie16lgO3VGvBvtLRQMPT/GTC34xm5FVQdpaDEoROZZPiDKxDil/k7hxI0 xqS6fj772m1ZEXUqPSSXUM4cveXPD+hed9bo7MKZxVscMP1cclFFzB6c4Uc2zSE5o+Nh Y41YHTTP5HFTcJsHPxzcYzm3cEAEeCZlo/sSgc/hN05wPV59bY8Y282Y7exykvsN0oiQ lDUjHhH20VAp8w1y9WdB7uWMpiwU5nFN6/cwU2EBE6oXWUwfrJmdeELhCuoHfHwhzYL/ AREw== X-Gm-Message-State: APjAAAUXN5FP4/Pjlo5TwsobDRFtUqN0CbRP/ihEplNY4xJ2+Vqomc7d NR2S+KQ2GX5Aoxb9X5I6k9FURYnNilOTXRb5Ta+gzg== X-Google-Smtp-Source: APXvYqz5UevAihHMjLOCIW4wkJJ5kpPSUBp+uq6J415g5nbmoSrQ37/Hu3svcA0Ud+txu3w7EP4pe9Vf2PDoO5bN8G4= X-Received: by 2002:a05:651c:326:: with SMTP id b6mr2063967ljp.119.1571720269294; Mon, 21 Oct 2019 21:57:49 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> In-Reply-To: <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> From: Kazuho Oku Date: Tue, 22 Oct 2019 13:57:38 +0900 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000567244059578a4c7" 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, 22 Oct 2019 04:57:54 -0000 --000000000000567244059578a4c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2019=E5=B9=B410=E6=9C=8822=E6=97=A5(=E7=81=AB) 11:38 Martin Thomson : > On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote: > > I'd also prefer to fix the problem, even if it means bringing back > > something like RETIRE_KEY. > > I would prefer to think of this proposed resolution as a temporary one. = I > don't think that we agreed to keep the handshake keys indefinitely, only > that we would use that option as a fallback position until we found a > better solution. > I might point out that #3121 is not proposal-ready as a way to resolve #2863. That is because it does not define how to send and receive Handshake packets until or after migration happens. There would be a deadlock unless both endpoints agree on how that should be done (e.g., how to select SCID, whether the path used for Handshake packets migrates too). Without that being clarified, can we say that we are ready for a consensus call? > > On that basis, I think that it would be best if we open a new issue that > says "Handshake keys can't ever be dropped". > > We might still conclude not to address that issue, but the important thin= g > is to ensure that any solution works properly. > > --=20 Kazuho Oku --000000000000567244059578a4c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
2019=E5=B9=B410=E6=9C=8822=E6=97=A5(= =E7=81=AB) 11:38 Martin Thomson <mt= @lowentropy.net>:
On Tue, Oct 22, 2019, = at 12:39, Nick Banks wrote:
>=C2=A0 I'd also prefer to fix the problem, even if it means bringin= g back
> something like RETIRE_KEY.

I would prefer to think of this proposed resolution as a temporary one.=C2= =A0 I don't think that we agreed to keep the handshake keys indefinitel= y, only that we would use that option as a fallback position until we found= a better solution.

I might point out t= hat #3121 is not proposal-ready as a way to resolve #2863. That is because = it does not define how to send and receive Handshake packets until or after= migration happens. There would be a deadlock unless both endpoints agree o= n how that should be done (e.g., how to select SCID, whether the path used = for Handshake packets migrates too).

Without that = being clarified, can we say that we are ready for a consensus=C2=A0call?
=C2=A0

On that basis, I think that it would be best if we open a new issue that sa= ys "Handshake keys can't ever be dropped".=C2=A0

We might still conclude not to address that issue, but the important thing = is to ensure that any solution works properly.



--
Kazuho Oku
--000000000000567244059578a4c7-- From nobody Mon Oct 21 22:14:37 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF4F120AFA for ; Mon, 21 Oct 2019 22:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9BvtpYF2mWy for ; Mon, 21 Oct 2019 22:14:34 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 C8BF3120046 for ; Mon, 21 Oct 2019 22:14:33 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id r1so6576466wrs.9 for ; Mon, 21 Oct 2019 22:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=fWcih5TOR/GH5k4neOrkM3y9DwhbM2Vt8WENriHKBtY=; b=sHIBYCqMcPWr5Ei0gZwrgSAJUsf5jb/8PxFODapS5Z46/5xR9b2gqjnBr/lK7uA+sH pFgjN3To122gqPY4eAz0J8co0uEo1qKEmph9aZDXp2RAa985CYvhxe4OjbZDm6yopcOj ZUU4Qh7npIV7ibVpYWP3Fk3VtkXwYoVYxCKRwA7/AWoaZKJraJ7ypalYo5mhEfUmCJnx YMDPj2+pxqGV+iPAtnp2zCVVz8XDNDIHyjrcDVb/+O3y718bs3x0QIYDNIEt74Lh5aN8 pUD2GpYXMdg5MwkOAXCTu1RFTA9kAgNzKAAjB0kPfummNgzCpyxGsQt9p+5Fu0QJA3HM BvKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=fWcih5TOR/GH5k4neOrkM3y9DwhbM2Vt8WENriHKBtY=; b=mFqSkQfeRnasrHc1TR0aIe/s19/t373ZirbhSochXTon3ILMw0CIOSsLmVmr21KPw0 BLZCXWKCTihVEPjWuPytDpVcDvmc6zCUkfXEDb2+ghQ2Vj7+2IBG3HklEHgkLMm2ptNB dOg11ouuP+94MwE3K12oqwT7oSP44tbftsXw/H40f+BKbP5nnbdqqkoCZeQy3oMw40X2 GOw2dWB6/j+7UfNdUPrOBzE728v3qUZ859rEAvH/6VcRNJPuBdhWh1qM/0DAFl1ydj1j ietGdrL38tC/tBXM9fRZZ86DsyuMx3C4iuLmFvDD3qwx7qYfOxTz9RLrkDEVgKqGQgk1 9zZw== X-Gm-Message-State: APjAAAW7BTfVWIb3mm+xwbarR8+SwdVar2MxswyPzfQH4TdMnDajT1lf x9f7yRzvTTTcULeaEjsJ7MO8QF3X X-Google-Smtp-Source: APXvYqyMOow1ui6+p+TQpi9r9Bzo/iKg7AwLLaKy/akIkcV4erVLol018/1Xm8yyaykSsZCTOb4UZQ== X-Received: by 2002:adf:f2d1:: with SMTP id d17mr1452735wrp.353.1571721272265; Mon, 21 Oct 2019 22:14:32 -0700 (PDT) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([2603:1026:6:38::5]) by smtp.gmail.com with ESMTPSA id 65sm12617962wrs.9.2019.10.21.22.14.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Oct 2019 22:14:31 -0700 (PDT) From: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= To: Kazuho Oku , Martin Thomson CC: IETF QUIC WG Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino Thread-Topic: Consensus Calls for Transport/TLS issues, post-Cupertino Thread-Index: AUNGRDRGcAHxOVcuLp0Y9BVrwR+CR3cyVXYtMDVDMTBlZGU0NVE1YTdXmZSbGlc= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Tue, 22 Oct 2019 05:14:31 +0000 Message-ID: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB176678E88FF226C2EB8FF78EAC680DB6PR10MB1766EURP_" MIME-Version: 1.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: Tue, 22 Oct 2019 05:14:36 -0000 --_000_DB6PR10MB176678E88FF226C2EB8FF78EAC680DB6PR10MB1766EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2l0aG91dCBhIHdheSB0byBtb3ZlIHRvIGEgc2luZ2xlIFBOIHNwYWNlIEkgZmluZCB0aGlzIGEg ZGVhbCBicmVha2VyLiBJIG1pZ2h0IGRvIGEgY3VzdG9tIHZlcnNpb24gb2YgdGhlIHByb3RvY29s Lg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcmE6IFFVSUMgPHF1aWMt Ym91bmNlc0BpZXRmLm9yZz4gcMOlIHZlZ25lIGFmIEthenVobyBPa3UgPGthenVob29rdUBnbWFp bC5jb20+DQpTZW5kdDogdGlyc2RhZywgb2t0b2JlciAyMiwgMjAxOSA2OjU4IEFNDQpUaWw6IE1h cnRpbiBUaG9tc29uDQpDYzogSUVURiBRVUlDIFdHDQpFbW5lOiBSZTogQ29uc2Vuc3VzIENhbGxz IGZvciBUcmFuc3BvcnQvVExTIGlzc3VlcywgcG9zdC1DdXBlcnRpbm8NCg0KDQoNCjIwMTnlubQx MOaciDIy5pelKOeBqykgMTE6MzggTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0PG1h aWx0bzptdEBsb3dlbnRyb3B5Lm5ldD4+Og0KT24gVHVlLCBPY3QgMjIsIDIwMTksIGF0IDEyOjM5 LCBOaWNrIEJhbmtzIHdyb3RlOg0KPiAgSSdkIGFsc28gcHJlZmVyIHRvIGZpeCB0aGUgcHJvYmxl bSwgZXZlbiBpZiBpdCBtZWFucyBicmluZ2luZyBiYWNrDQo+IHNvbWV0aGluZyBsaWtlIFJFVElS RV9LRVkuDQoNCkkgd291bGQgcHJlZmVyIHRvIHRoaW5rIG9mIHRoaXMgcHJvcG9zZWQgcmVzb2x1 dGlvbiBhcyBhIHRlbXBvcmFyeSBvbmUuICBJIGRvbid0IHRoaW5rIHRoYXQgd2UgYWdyZWVkIHRv IGtlZXAgdGhlIGhhbmRzaGFrZSBrZXlzIGluZGVmaW5pdGVseSwgb25seSB0aGF0IHdlIHdvdWxk IHVzZSB0aGF0IG9wdGlvbiBhcyBhIGZhbGxiYWNrIHBvc2l0aW9uIHVudGlsIHdlIGZvdW5kIGEg YmV0dGVyIHNvbHV0aW9uLg0KDQpJIG1pZ2h0IHBvaW50IG91dCB0aGF0ICMzMTIxIGlzIG5vdCBw cm9wb3NhbC1yZWFkeSBhcyBhIHdheSB0byByZXNvbHZlICMyODYzLiBUaGF0IGlzIGJlY2F1c2Ug aXQgZG9lcyBub3QgZGVmaW5lIGhvdyB0byBzZW5kIGFuZCByZWNlaXZlIEhhbmRzaGFrZSBwYWNr ZXRzIHVudGlsIG9yIGFmdGVyIG1pZ3JhdGlvbiBoYXBwZW5zLiBUaGVyZSB3b3VsZCBiZSBhIGRl YWRsb2NrIHVubGVzcyBib3RoIGVuZHBvaW50cyBhZ3JlZSBvbiBob3cgdGhhdCBzaG91bGQgYmUg ZG9uZSAoZS5nLiwgaG93IHRvIHNlbGVjdCBTQ0lELCB3aGV0aGVyIHRoZSBwYXRoIHVzZWQgZm9y IEhhbmRzaGFrZSBwYWNrZXRzIG1pZ3JhdGVzIHRvbykuDQoNCldpdGhvdXQgdGhhdCBiZWluZyBj bGFyaWZpZWQsIGNhbiB3ZSBzYXkgdGhhdCB3ZSBhcmUgcmVhZHkgZm9yIGEgY29uc2Vuc3VzIGNh bGw/DQoNCg0KT24gdGhhdCBiYXNpcywgSSB0aGluayB0aGF0IGl0IHdvdWxkIGJlIGJlc3QgaWYg d2Ugb3BlbiBhIG5ldyBpc3N1ZSB0aGF0IHNheXMgIkhhbmRzaGFrZSBrZXlzIGNhbid0IGV2ZXIg YmUgZHJvcHBlZCIuDQoNCldlIG1pZ2h0IHN0aWxsIGNvbmNsdWRlIG5vdCB0byBhZGRyZXNzIHRo YXQgaXNzdWUsIGJ1dCB0aGUgaW1wb3J0YW50IHRoaW5nIGlzIHRvIGVuc3VyZSB0aGF0IGFueSBz b2x1dGlvbiB3b3JrcyBwcm9wZXJseS4NCg0KDQoNCi0tDQpLYXp1aG8gT2t1DQo= --_000_DB6PR10MB176678E88FF226C2EB8FF78EAC680DB6PR10MB1766EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOiBsdHI7Ij5XaXRob3V0IGEgd2F5IHRvIG1v dmUgdG8gYSBzaW5nbGUgUE4gc3BhY2UgSSBmaW5kIHRoaXMgYSBkZWFsIGJyZWFrZXIuIEkgbWln aHQgZG8gYSBjdXN0b20gdmVyc2lvbiBvZiB0aGUgcHJvdG9jb2wuPC9kaXY+DQo8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJtcy1vdXRsb29rLWlvcy1zaWduYXR1cmUiPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGhyIHN0eWxlPSJkaXNwbGF5OmlubGlu ZS1ibG9jazt3aWR0aDo5OCUiIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNn IiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiI+PGI+RnJhOjwvYj4g UVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyBww6UgdmVnbmUgYWYgS2F6dWhvIE9r dSAmbHQ7a2F6dWhvb2t1QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TZW5kdDo8L2I+IHRpcnNkYWcs IG9rdG9iZXIgMjIsIDIwMTkgNjo1OCBBTTxicj4NCjxiPlRpbDo8L2I+IE1hcnRpbiBUaG9tc29u PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0c8YnI+DQo8Yj5FbW5lOjwvYj4gUmU6IENvbnNl bnN1cyBDYWxscyBmb3IgVHJhbnNwb3J0L1RMUyBpc3N1ZXMsIHBvc3QtQ3VwZXJ0aW5vDQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPC9mb250PjwvZGl2Pg0KPG1ldGEgY29udGVudD0idGV4dC9odG1sOyBj aGFyc2V0PXV0Zi04Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9k aXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iZ21haWxfYXR0ciI+MjAxOeW5tDEw5pyIMjLml6Uo54GrKSAxMTozOCBNYXJ0aW4gVGhvbXNv biAmbHQ7PGEgaHJlZj0ibWFpbHRvOm10QGxvd2VudHJvcHkubmV0Ij5tdEBsb3dlbnRyb3B5Lm5l dDwvYT4mZ3Q7Ojxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDoxcHg7IGJv cmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQp OyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCk9uIFR1ZSwgT2N0IDIyLCAyMDE5LCBhdCAxMjozOSwgTmlj ayBCYW5rcyB3cm90ZTo8YnI+DQomZ3Q7Jm5ic3A7IEknZCBhbHNvIHByZWZlciB0byBmaXggdGhl IHByb2JsZW0sIGV2ZW4gaWYgaXQgbWVhbnMgYnJpbmdpbmcgYmFjayA8YnI+DQomZ3Q7IHNvbWV0 aGluZyBsaWtlIFJFVElSRV9LRVkuPGJyPg0KPGJyPg0KSSB3b3VsZCBwcmVmZXIgdG8gdGhpbmsg b2YgdGhpcyBwcm9wb3NlZCByZXNvbHV0aW9uIGFzIGEgdGVtcG9yYXJ5IG9uZS4mbmJzcDsgSSBk b24ndCB0aGluayB0aGF0IHdlIGFncmVlZCB0byBrZWVwIHRoZSBoYW5kc2hha2Uga2V5cyBpbmRl ZmluaXRlbHksIG9ubHkgdGhhdCB3ZSB3b3VsZCB1c2UgdGhhdCBvcHRpb24gYXMgYSBmYWxsYmFj ayBwb3NpdGlvbiB1bnRpbCB3ZSBmb3VuZCBhIGJldHRlciBzb2x1dGlvbi48YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIG1pZ2h0IHBvaW50IG91dCB0aGF0ICMz MTIxIGlzIG5vdCBwcm9wb3NhbC1yZWFkeSBhcyBhIHdheSB0byByZXNvbHZlICMyODYzLiBUaGF0 IGlzIGJlY2F1c2UgaXQgZG9lcyBub3QgZGVmaW5lIGhvdyB0byBzZW5kIGFuZCByZWNlaXZlIEhh bmRzaGFrZSBwYWNrZXRzIHVudGlsIG9yIGFmdGVyIG1pZ3JhdGlvbiBoYXBwZW5zLiBUaGVyZSB3 b3VsZCBiZSBhIGRlYWRsb2NrIHVubGVzcyBib3RoIGVuZHBvaW50cyBhZ3JlZSBvbiBob3cgdGhh dA0KIHNob3VsZCBiZSBkb25lIChlLmcuLCBob3cgdG8gc2VsZWN0IFNDSUQsIHdoZXRoZXIgdGhl IHBhdGggdXNlZCBmb3IgSGFuZHNoYWtlIHBhY2tldHMgbWlncmF0ZXMgdG9vKS48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldpdGhvdXQgdGhhdCBiZWluZyBjbGFyaWZpZWQsIGNhbiB3 ZSBzYXkgdGhhdCB3ZSBhcmUgcmVhZHkgZm9yIGEgY29uc2Vuc3VzJm5ic3A7Y2FsbD88L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVy LWxlZnQtc3R5bGU6c29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IHBh ZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KT24gdGhhdCBiYXNpcywgSSB0aGluayB0aGF0IGl0IHdv dWxkIGJlIGJlc3QgaWYgd2Ugb3BlbiBhIG5ldyBpc3N1ZSB0aGF0IHNheXMgJnF1b3Q7SGFuZHNo YWtlIGtleXMgY2FuJ3QgZXZlciBiZSBkcm9wcGVkJnF1b3Q7LiZuYnNwOw0KPGJyPg0KPGJyPg0K V2UgbWlnaHQgc3RpbGwgY29uY2x1ZGUgbm90IHRvIGFkZHJlc3MgdGhhdCBpc3N1ZSwgYnV0IHRo ZSBpbXBvcnRhbnQgdGhpbmcgaXMgdG8gZW5zdXJlIHRoYXQgYW55IHNvbHV0aW9uIHdvcmtzIHBy b3Blcmx5Ljxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsZWFyPSJhbGwi Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCi0tIDxicj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFp bF9zaWduYXR1cmUiPkthenVobyBPa3U8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_DB6PR10MB176678E88FF226C2EB8FF78EAC680DB6PR10MB1766EURP_-- From nobody Tue Oct 22 00:51:10 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39AB1200B5 for ; Tue, 22 Oct 2019 00:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvIE2pl_Yy4p for ; Tue, 22 Oct 2019 00:51:06 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 34A0312002F for ; Tue, 22 Oct 2019 00:51:06 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id 21so3306346lft.10 for ; Tue, 22 Oct 2019 00:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8qQU6OlfWNtjADIZomuL0Tn/A19rwZrrb6jxn3oL1HE=; b=XEDklC6ZyzGUjO27f2z2ie9GEbReZoxX/gFjubfv+2Wl5Sfj0IVOYopuTlY3zbJ9jl wBIbwnW2ziTfKpL9IhcBbU2nwysw1pVCUnjllIjBCXd602jLknDiglsCQ70Ooh2H3JN6 YZGAQV/fsN/8b2vVnpB84BqBq3CNRS2L++6E2aOA743rNYGwNkQhsgef0cUwyyWLEOVw HZr9H3zn9GuAm1ZoQQX4JWbbpdw6a1UpsBVRuX984kZ3YT315Y3GWpO9dfBucdbxWHtL N3nsXuCPOybb5t1AjnhXH6fAMylp0kujp3hcpYHvEVT2NFpWp6MaNwxlhP5ypDBMs2aE suPw== 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=8qQU6OlfWNtjADIZomuL0Tn/A19rwZrrb6jxn3oL1HE=; b=uI29f9Bri6gAtX9E1yFWIHCUb3RTdMOhT6J+RPQcquOyhObDyiaqvVC5V5TUW9pWFS WHiHh/CdTcI28OK57Kvt+n/7+lOhznsHPRMRjlwRtgBPTgVxQnOuf7t3K3o/JUs2Z8z3 rKKTRmYzVjVm/IJjE5Gb2aDQdvOOrys0XzIipB705PlVtKF2ryXOAGarQjBASJXLUr1o nSHbZPzkvVEVe1POJlcRaFMy0W4khyJWfkduQ2BebD0U9oibTY1A1+A4EZQNvcSeSHMP lpKfPWJPOR9o0yU5fKu3iEGX+KQLtwQrnn2bk66bJrCPYufOxoaw85TSyVkexzKxx2zS 2StQ== X-Gm-Message-State: APjAAAX4hqDFUe86pxOg/ZVuQrit6roqtyhLePdwh8QUKZCGNoNQgVQR eQW+6DUziT66FjfCXTliKdcWCZ3dCkPxJoItojI= X-Google-Smtp-Source: APXvYqzMd/+6NK7aqt3mD65IJPonRPZRxQPLxYo8ldnIBThm+YXAXLGx9xqjRlWcSTiG2ajVCqv40FhjJBX0XQC1MWY= X-Received: by 2002:ac2:4142:: with SMTP id c2mr17663483lfi.47.1571730664140; Tue, 22 Oct 2019 00:51:04 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> In-Reply-To: From: Jana Iyengar Date: Tue, 22 Oct 2019 16:50:53 +0900 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Kazuho Oku , Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000eb35b505957b0fd7" 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, 22 Oct 2019 07:51:09 -0000 --000000000000eb35b505957b0fd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Kazuho here. The issue of migration was not one we had considered. I was going through this with Kazuho, and we may have identified yet another issue with handshake retransmissions and migration, which is present in the current spec. Sadly, I don't think we can call this issue done. On Tue, Oct 22, 2019 at 2:14 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Without a way to move to a single PN space I find this a deal breaker. I > might do a custom version of the protocol. > > > ------------------------------ > *Fra:* QUIC p=C3=A5 vegne af Kazuho Oku < > kazuhooku@gmail.com> > *Sendt:* tirsdag, oktober 22, 2019 6:58 AM > *Til:* Martin Thomson > *Cc:* IETF QUIC WG > *Emne:* Re: Consensus Calls for Transport/TLS issues, post-Cupertino > > > > 2019=E5=B9=B410=E6=9C=8822=E6=97=A5(=E7=81=AB) 11:38 Martin Thomson : > >> On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote: >> > I'd also prefer to fix the problem, even if it means bringing back >> > something like RETIRE_KEY. >> >> I would prefer to think of this proposed resolution as a temporary one. >> I don't think that we agreed to keep the handshake keys indefinitely, on= ly >> that we would use that option as a fallback position until we found a >> better solution. >> > > I might point out that #3121 is not proposal-ready as a way to resolve > #2863. That is because it does not define how to send and receive Handsha= ke > packets until or after migration happens. There would be a deadlock unles= s > both endpoints agree on how that should be done (e.g., how to select SCID= , > whether the path used for Handshake packets migrates too). > > Without that being clarified, can we say that we are ready for a > consensus call? > > >> >> On that basis, I think that it would be best if we open a new issue that >> says "Handshake keys can't ever be dropped". >> >> We might still conclude not to address that issue, but the important >> thing is to ensure that any solution works properly. >> >> > > -- > Kazuho Oku > --000000000000eb35b505957b0fd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Kazuho here. The issue of migration was not o= ne we had considered. I was going through this with Kazuho, and we may have= identified yet another issue with handshake retransmissions and migration,= which is present in the current spec.

Sadly, I don'= t think we can call this issue done.

On Tue, Oct 22, 2019 at 2:14 PM M= ikkel Fahn=C3=B8e J=C3=B8rgensen <= mikkelfj@gmail.com> wrote:
Without a way to move to a single PN space I f= ind this a deal breaker. I might do a custom version of the protocol.

=C2=A0
Fra: QUIC <quic-bounces@ietf.org> p=C3=A5 vegne a= f Kazuho Oku <k= azuhooku@gmail.com>
Sendt: tirsdag, oktober 22, 2019 6:58 AM
Til: Martin Thomson
Cc: IETF QUIC WG
Emne: Re: Consensus Calls for Transport/TLS issues, post-Cupertino
=C2=A0


2019=E5=B9=B410=E6=9C=8822=E6=97=A5(= =E7=81=AB) 11:38 Martin Thomson <mt@lowentropy.net>:
On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote:
>=C2=A0 I'd also prefer to fix the problem, even if it means bringin= g back
> something like RETIRE_KEY.

I would prefer to think of this proposed resolution as a temporary one.=C2= =A0 I don't think that we agreed to keep the handshake keys indefinitel= y, only that we would use that option as a fallback position until we found= a better solution.

I might point out that #3121 is not proposal-ready as a way to resolve= #2863. That is because it does not define how to send and receive Handshak= e packets until or after migration happens. There would be a deadlock unles= s both endpoints agree on how that should be done (e.g., how to select SCID, whether the path used for Handsh= ake packets migrates too).

Without that being clarified, can we say that we are ready for a conse= nsus=C2=A0call?
=C2=A0

On that basis, I think that it would be best if we open a new issue that sa= ys "Handshake keys can't ever be dropped".=C2=A0

We might still conclude not to address that issue, but the important thing = is to ensure that any solution works properly.



--
Kazuho Oku
--000000000000eb35b505957b0fd7-- From nobody Tue Oct 22 05:24:43 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2F61200E6 for ; Tue, 22 Oct 2019 05:24:42 -0700 (PDT) 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, 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 (1024-bit key) header.d=uhasselt.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugGQvxs9cbdu for ; Tue, 22 Oct 2019 05:24:40 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 0A460120047 for ; Tue, 22 Oct 2019 05:24:39 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id f5so5206836lfp.1 for ; Tue, 22 Oct 2019 05:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:from:date:message-id:subject:to; bh=PpjVFI42A18Ro7g8b5aEyH6QzqIVi6uv9sXvgoWmAvk=; b=N+4dnz42yMcZNyb6gSrgDtaPXXNHPw1RmIoBplqBp16aiNTuOJRgz62Dh6xNgLYGWO 24PMqT43N5/peZ4mOW5a6awBTXrv22mPPE6JmLAT3A2pRBz5y64tad+H6gBhxUKckiYG ZyAaYvWzAryN5qgb49gbDgf/MREXVSST5RcQU= 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=PpjVFI42A18Ro7g8b5aEyH6QzqIVi6uv9sXvgoWmAvk=; b=QHaqg7qP1WL9G2qFOPnxgTuOtUpgE5VWiRbX+rG4K3nWTpwupey6wDtO3bOAGOsN6+ prTITA1d/g9a6CzhgC8tg5OSZ7VWdyR85RD5yPISjfKK3pPZr2sqjuhbjm4qxaOuh9WZ 59GDhekIm98bU+vKdJirnrc8brHkNJqHGsYWWNyiNF+jVWujgo3q4gAsRu4igbkXBgyK vEp6lX0/8kYFe+v14ImutAG+0j3dfBPyxwZZiy17obIU5sDqT9S2ZDT42E1cDYeqdQdg aoRAexXUVsvMbhhXPo5lDa2EYZPPtfh0U5dtvW47ZF0QL7VQiAF/bsHP3sdIGhXGqnAV FCmQ== X-Gm-Message-State: APjAAAXc3Y3mHyOEurxhgzYY4BP2nPFVShQnaewEa03OlIoJ1SwBnVTL dZMrric5FA8SpgAQjpGg8p2F/sXovr00DyAkWhlbF9/CY5HmZw== X-Google-Smtp-Source: APXvYqz1B74ptIvNsVTR0nS3da9soPPgMOsk0WZAgJUHsEanhEDXkDrOAW8qGb9iAcmSfejXagIGMd1c/kAkSmRhMNc= X-Received: by 2002:a19:855:: with SMTP id 82mr18362953lfi.44.1571747077281; Tue, 22 Oct 2019 05:24:37 -0700 (PDT) MIME-Version: 1.0 From: Robin MARX Date: Tue, 22 Oct 2019 14:24:25 +0200 Message-ID: Subject: An update on qlog To: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000037f28b05957ee2c1" 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, 22 Oct 2019 12:24:43 -0000 --00000000000037f28b05957ee2c1 Content-Type: text/plain; charset="UTF-8" Hello everyone, In the run-up to Singapore, I wanted to give an update on the structure logging format for QUIC that we've been working on, called qlog. The draft-01 version was released last week and can be found at: - https://tools.ietf.org/html/draft-marx-qlog-main-schema-01 - https://tools.ietf.org/html/draft-marx-qlog-event-definitions-quic-h3-01 Between draft-00 and draft-01, over half of the currently active QUIC implementations support some form of qlog, with for example Facebook reporting billions of logged events in production each day. For those on -00 that want to move to -01, I have created a short guide at https://github.com/quiclog/internet-drafts/blob/master/implementers/transition-00-to-01.md . The main reason for supporting qlog, at least at the moment, is the ability to create and use tools like the ones available at https://qvis.edm.uhasselt.be. As simulation and testing frameworks such as https://github.com/marten-seemann/quic-network-simulator/ mature, we expect these tools to become invaluable for in-depth debugging, as well as for easy sharing of test results. Both the format and the tools are in a good initial stage, but I would like to get some input from the wg going forward. For example: - Feedback on the qlog schema and format itself (missing events, interesting new features, encountered practical issues, ...) - Opinions on security and privacy aspects of the qlog files (mentioned several times during tsvarea Q&A's but rarely followed up afterwards) - Opinions on practically exposing the logs (we currently propose a .well-known URI) - Feedback on the current tools (usability, performance, missing features, ...) - Requests for new tools / debugging use cases (which tools should be prioritized first?) - Opinions on potential wg adoption (part of v1? part of v2? no adoption / just remain as de-facto "standard"?) Getting some of this feedback now will help me to tackle the main issues by Singapore. I will also be present there for the full week, including the Hackaton, to gather feedback and help people resolve issues. Feedback is welcome here, via the quicdev slack group (channel #qlog) or via our github repositories. With best regards, Robin -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 --00000000000037f28b05957ee2c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

In the run-up to Singap= ore, I wanted to give an update on the structure logging format for QUIC th= at we've been working on, called qlog.=C2=A0

T= he draft-01 version was released last week and can be found at:

Between draft-00 and draft-01, = over half of the currently active QUIC implementations support some form of= qlog, with for example Facebook reporting billions of logged events in pro= duction each day. For those on -00 that want to move to -01, I have created= a short guide at=C2=A0https://github.com/quicl= og/internet-drafts/blob/master/implementers/transition-00-to-01.md.=C2= =A0

The main reason for supporting qlog, at least = at the moment, is the ability to create and use tools like the ones availab= le at=C2=A0https://qvis.edm.uhass= elt.be. As simulation and testing frameworks such as=C2=A0https://github.com= /marten-seemann/quic-network-simulator/=C2=A0mature, we expect these to= ols to become invaluable for in-depth debugging, as well as for easy sharin= g of test results.=C2=A0


Both the f= ormat and the tools are in a good initial stage, but I would like to get so= me input from the wg going forward. For example:=C2=A0

=
- Feedback on the qlog schema and format itself (missing events, inter= esting new features, encountered practical issues, ...)
- Opinion= s on security and privacy aspects of the qlog files (mentioned several time= s during tsvarea=C2=A0Q&A's but rarely followed up afterwards)
- Opinions on practically exposing the logs (we currently propose a .= well-known URI)

- Feedback on the current tools (u= sability, performance, missing features, ...)
- Requests for new = tools / debugging use cases (which tools should be prioritized first?)

- Opinions on potential wg adoption (part of v1? part = of v2? no adoption / just remain as de-facto "standard"?)


Getting some of this feedback now will hel= p me to tackle the main issues by Singapore.
I will also be prese= nt there for the full week, including the Hackaton, to gather feedback and = help people resolve issues.=C2=A0

Feedback is welc= ome here, via the quicdev slack group (channel #qlog) or via our github rep= ositories.=C2=A0

With best regards,
Robi= n

--

<= tr>=
Robin=C2=A0Marx
PhD researcher - web performance
Expertise centre for= Digital Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
=C2=A0
www.uh= asselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 = Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
3D""
--00000000000037f28b05957ee2c1-- From nobody Tue Oct 22 13:06:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A421200F3 for ; Tue, 22 Oct 2019 13:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lif_fPTVyQsH for ; Tue, 22 Oct 2019 13:06:46 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F16120077 for ; Tue, 22 Oct 2019 13:06:46 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id y3so18556348ljj.6 for ; Tue, 22 Oct 2019 13:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bKbb177bT8VoaewjqpBSP+HAYOHi+OdJHBRsNI79EWY=; b=GdZtirkAyQDSVlbQDv2HJv4oP4fnez9rfS9M6CgpCV7szdnyrb4sFnnyTs+Pvdq2yn BAAAjKnwcRudIJMKaCeO+jx5KcgLVJ1xNXL73hYbPuG20QfupypLeWILba+vr3xC6qu6 WrEPt77e7w2Oq/vqPhJk0ka4Bfm5bOf0TuuUAOvi2fq4c3rDdqNcfoNBzQH79a9+8Lg2 ItXkDYapkoKICKts3mqyZbB/PC1n12dB3yBbhcqR9uJdgty6a3IeNMgA+RM/eaBSTz36 d2FthMYrjeKzzVIWt0qFpGGeWsKLRaCYtCsboGgEajIzbSuBIG0tbHKjDcroofJWcuvK ampA== 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=bKbb177bT8VoaewjqpBSP+HAYOHi+OdJHBRsNI79EWY=; b=cy76WWj+7qbKkBsGb2u9SbvMYJ4t4nwO2XDQdJ1cUK1yA2aLiwI5FBUiZdWM0ie1tj iXdLguejc8XrLSXlOrGVvC+6dWc+xYMprAOSzYM4SpqdpXKHFhR8Addem0XqPdia6fRd N70QOzOnD3y5cg98QlDSBFX4GHRXVmGlrWVuf2RhpRllyUQr/xj7G2YIVBxm1WJzPZwE rWEhhD+KQGDi4mG5RK53MJYeogWea2/fiPDv/87uSjPuDoBoYPqcZpJ5V1Psre4Oo4Z7 t8AlaVXIhRpNQe8NWJTwvvfam1xfx8zPTo6aQBmZHfYbB+2itvsEiEgRkiF3wZqTDel8 dogQ== X-Gm-Message-State: APjAAAWN8GtYPKVQRmuDco7/9qpmthbz0ShqLUHKV/GrL4cJ400M08Ba GwG59qhtpaEuRbvHLLxjiVuV6qqw2R4oPB7zbfI= X-Google-Smtp-Source: APXvYqxAVp9Lo2BdDv+mtZLZ4tVFGvodMZ4BXye8jRqntz93HMghkD04tjU354iUeJAbdA979VmfAcuvE0GfNsc+wf8= X-Received: by 2002:a2e:416:: with SMTP id 22mr3417147lje.55.1571774804430; Tue, 22 Oct 2019 13:06:44 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> In-Reply-To: From: David Schinazi Date: Tue, 22 Oct 2019 13:06:33 -0700 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Jana Iyengar Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000e2923605958556e4" 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, 22 Oct 2019 20:06:49 -0000 --000000000000e2923605958556e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 I think the text we have in the spec today is better than the proposal to never discard the handshake keys. My preference would be to spend the time to fix the issue, and not add a temporary workaround for now. On Tue, Oct 22, 2019 at 12:51 AM Jana Iyengar wrote: > I agree with Kazuho here. The issue of migration was not one we had > considered. I was going through this with Kazuho, and we may have > identified yet another issue with handshake retransmissions and migration= , > which is present in the current spec. > > Sadly, I don't think we can call this issue done. > > On Tue, Oct 22, 2019 at 2:14 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > >> Without a way to move to a single PN space I find this a deal breaker. I >> might do a custom version of the protocol. >> >> >> ------------------------------ >> *Fra:* QUIC p=C3=A5 vegne af Kazuho Oku < >> kazuhooku@gmail.com> >> *Sendt:* tirsdag, oktober 22, 2019 6:58 AM >> *Til:* Martin Thomson >> *Cc:* IETF QUIC WG >> *Emne:* Re: Consensus Calls for Transport/TLS issues, post-Cupertino >> >> >> >> 2019=E5=B9=B410=E6=9C=8822=E6=97=A5(=E7=81=AB) 11:38 Martin Thomson : >> >>> On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote: >>> > I'd also prefer to fix the problem, even if it means bringing back >>> > something like RETIRE_KEY. >>> >>> I would prefer to think of this proposed resolution as a temporary one. >>> I don't think that we agreed to keep the handshake keys indefinitely, o= nly >>> that we would use that option as a fallback position until we found a >>> better solution. >>> >> >> I might point out that #3121 is not proposal-ready as a way to resolve >> #2863. That is because it does not define how to send and receive Handsh= ake >> packets until or after migration happens. There would be a deadlock unle= ss >> both endpoints agree on how that should be done (e.g., how to select SCI= D, >> whether the path used for Handshake packets migrates too). >> >> Without that being clarified, can we say that we are ready for a >> consensus call? >> >> >>> >>> On that basis, I think that it would be best if we open a new issue tha= t >>> says "Handshake keys can't ever be dropped". >>> >>> We might still conclude not to address that issue, but the important >>> thing is to ensure that any solution works properly. >>> >>> >> >> -- >> Kazuho Oku >> > --000000000000e2923605958556e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

I think the text we have in the = spec today is better than the proposal to never discard the handshake keys.=
My preference would be to spend the time to fix the issue, and n= ot add a temporary workaround for now.

On Tue, Oct 22, 2019 at 12:51 A= M Jana Iyengar <jri.ietf@gmail.com= > wrote:
=
I agree with Kazuho here. The issue of migration was not o= ne we had considered. I was going through this with Kazuho, and we may have= identified yet another issue with handshake retransmissions and migration,= which is present in the current spec.

Sadly, I don'= t think we can call this issue done.

On Tue, Oct 22, 2019 at 2:14 PM M= ikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
Without a way to move to a single PN space I f= ind this a deal breaker. I might do a custom version of the protocol.

=C2=A0
Fra: QUIC <quic-bounces@ietf.= org> p=C3=A5 vegne af Kazuho Oku <kazuhooku@gmail.com>
Sendt: tirsdag, oktober 22, 2019 6:58 AM
Til: Martin Thomson
Cc: IETF QUIC WG
Emne: Re: Consensus Calls for Transport/TLS issues, post-Cupertino
=C2=A0


2019=E5=B9=B410=E6=9C=8822=E6=97=A5(= =E7=81=AB) 11:38 Martin Thomson <mt@lowentropy.net>:
On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote:
>=C2=A0 I'd also prefer to fix the problem, even if it means bringin= g back
> something like RETIRE_KEY.

I would prefer to think of this proposed resolution as a temporary one.=C2= =A0 I don't think that we agreed to keep the handshake keys indefinitel= y, only that we would use that option as a fallback position until we found= a better solution.

I might point out that #3121 is not proposal-ready as a way to resolve= #2863. That is because it does not define how to send and receive Handshak= e packets until or after migration happens. There would be a deadlock unles= s both endpoints agree on how that should be done (e.g., how to select SCID, whether the path used for Handsh= ake packets migrates too).

Without that being clarified, can we say that we are ready for a conse= nsus=C2=A0call?
=C2=A0

On that basis, I think that it would be best if we open a new issue that sa= ys "Handshake keys can't ever be dropped".=C2=A0

We might still conclude not to address that issue, but the important thing = is to ensure that any solution works properly.



--
Kazuho Oku
--000000000000e2923605958556e4-- From nobody Tue Oct 22 14:19:35 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E5C1200F7 for ; Tue, 22 Oct 2019 14:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9IvtU7d96uu for ; Tue, 22 Oct 2019 14:19:32 -0700 (PDT) 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 AAB231200F3 for ; Tue, 22 Oct 2019 14:19:31 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id i15so6818442lfo.7 for ; Tue, 22 Oct 2019 14:19:31 -0700 (PDT) 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=1EIYL/e2dZA3wADqTi7LCLqL07qM4OhL3Fn418OuPyY=; b=OGiTEywmmTW2tMPMP1dIxBDAg2+7mLWZN4wu0bu2SuCnJT7cMGUaJbp1QdNdW8IEfK fMzuh9qnkCnaV6Syd1v/PTCipgPztaApRcyPZW/kZ1+vFYdTNQfzclCsQ4QkDmOpUTJX 0WhPKvfaoDgCy4RSQcdmPOq1t4YcAvpmzkZTGL9s5a3GBaGD5NGlVGX2bZDWYTQQejn6 PfZvePNM5fx9IrayEGIES/XgV+Xb+qoJjaFQJgLCCPPDzXUyt6UrBqWULAIJUjwrPwfA EDn2gWvwO3GLrcApdQhzKuHcQTw1W94ZZf08wDEdTJ7fgF8NPPe2oLij8Fop4vbpA2fL b3oA== 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=1EIYL/e2dZA3wADqTi7LCLqL07qM4OhL3Fn418OuPyY=; b=R/TEjJuciRA+JQuIN4XdRYu2nwk294qMUAw4GKloeTZaUEHR57AUYeUNlRA/tp4m6r 3jnFhqmmBpiyMptJ0QZTW/cIkxVLF48/X+WgIAIGiCfJVoViMQ22gM6TtoGw641aOYuL S0mptvP4HGfFM1IKCmSLTaEWo/lXMYPpQi0ie9CsPk3j5gn0OrjoLh1ZC9pA7iU1eXGE OzHGPmSQK7oU/bCKgDsmh+NBa+nhcI2JGpMz0/zLg8vv+mfKDKRXh8/SZtKqV47gW9A7 /9BkfwsdzxOX4uJrSd9V6T9/esWuJ3kAf1+vHoTAVviQZd4jxiiL6AmJKwBZiOJJk1+P eskg== X-Gm-Message-State: APjAAAXZlNgBEvIXeEZm/w+aE2kPN0f9OOxfu5/Ic8XPP108XJYgPd40 CmpZ4NyhuRhxt0QdPHptHsVNVZHHUzc0fzUig71udckN X-Google-Smtp-Source: APXvYqzaSk86xo2v6dM1n4hY6US5NGKbfjt1ZxjT7I/xhCFaDY6Svt5aaCYpDdfFHbJbeTXivsyA1YL+0j7ClGoDrfk= X-Received: by 2002:a19:f813:: with SMTP id a19mr4885992lff.33.1571779169725; Tue, 22 Oct 2019 14:19:29 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Tue, 22 Oct 2019 14:19:18 -0700 Message-ID: Subject: Updates to QUIC Datagrams To: QUIC Cc: Tommy Pauly , Eric Kinnear Content-Type: multipart/alternative; boundary="00000000000013b15a0595865ba1" 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, 22 Oct 2019 21:19:34 -0000 --00000000000013b15a0595865ba1 Content-Type: text/plain; charset="UTF-8" Hi everyone, In Montreal, we discussed the flow ID in QUIC datagrams, and reached rough consensus that it made sense for QUIC datagrams to be as simple as possible, and for higher layers to handle demultiplexing if necessary. So we've split the identifier into a new draft that only defines it for application protocols sharing a QUIC connection with HTTP/3. Here are the updated drafts: https://tools.ietf.org/html/draft-pauly-quic-datagram-04 https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram-01 Thanks, David --00000000000013b15a0595865ba1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

In Montreal, we discussed = the flow ID in QUIC datagrams, and reached rough consensus that it made sen= se for QUIC datagrams to be as simple as possible, and for higher layers to= handle demultiplexing if necessary.

So we've = split the identifier into a new draft that only defines it for application = protocols sharing a QUIC connection with HTTP/3.

H= ere are the updated drafts:
Th= anks,
David
--00000000000013b15a0595865ba1-- From nobody Tue Oct 22 17:22:39 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B929E120219 for ; Tue, 22 Oct 2019 17:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=lowentropy.net header.b=Rip5k1bZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AQeei58L Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ds3iC3axg9v for ; Tue, 22 Oct 2019 17:22:36 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA901201CE for ; Tue, 22 Oct 2019 17:22:36 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2353820F20 for ; Tue, 22 Oct 2019 20:22:35 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 22 Oct 2019 20:22:35 -0400 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=fm3; bh=1WhOzSTtOHtrqx/TkG2eTU9PQggQzk8 AmQ/gQ0U5OEw=; b=Rip5k1bZoZMK4QIF9cbBJtZOdjU03m/20c5yCam62LwkAU1 Sg4wRurVM0MVXIURtw3gFcWUcO5euTUcYhps3shubZBTM73/s90iHVRojiCaxuam L2Bihjo2A7dPq+07B21pm3xvJaSlquFMfrs1sonyr0yqIewOeWr/Zw+WsqeS/7KC WSimfKtoGyyxc5HxUU9AV5+1NLLMKpRPpSANRnqzLAwHE6+vOaP2hx1bHLLeWlSH VYEtl9SjA7p2yKZXpLs0EjPLMqr1UhwPdmcyA/dPb5SKHL6imBQ98odoty+b7+xc 0Kec6QDD6XKFp3XFtumkxQB49u1KLCoLZM76lgw== 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=fm1; bh=1WhOzS TtOHtrqx/TkG2eTU9PQggQzk8AmQ/gQ0U5OEw=; b=AQeei58LjXDzwr16717PG4 z40+seaFk7p61Tbvg1UCcMCO0SskFjpbUcXv7+jtm4vo9etpB/Nji7E1XscQDGLs O7JCLe/IgwtTGPPGhSGCBBmAi17i9fPYColpXnSYPOTOkfQT9o1lVb/qF34XO8zp sVp7abdhqlq6qSuKXHju2Mbwyk5pnn50m6sNFQOHDFu8YaCONHUEwiw0E6TjPeLq wGh1zNu9QCK//tfQUIu39zYOA1MC5ueiAKdFHA2igxXDd9B+Yo0MxUa7Txn8vQNZ tphQsFalh4Kdl7ncQXtHbqbkC8/ecREEo22R709SUdKvhfqsQHelD2qaNYuFfQOA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrkeekgdefvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BBE87E00BB; Tue, 22 Oct 2019 20:22:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: <7ac87af3-b49b-4e93-8f70-db35a74419a8@www.fastmail.com> In-Reply-To: References: Date: Wed, 23 Oct 2019 11:22:14 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Updates to QUIC Datagrams 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: Wed, 23 Oct 2019 00:22:38 -0000 Thanks for doing this, I think that this is a reasonable approach. On Wed, Oct 23, 2019, at 08:19, David Schinazi wrote: > https://tools.ietf.org/html/draft-pauly-quic-datagram-04 Simple is good. This probably need to say more about 0-RTT. That is, explain that protocols that use DATAGRAM in 0-RTT need to define a protocol-specific profile that explains what usage patterns are safe and what anti-replay countermeasures are recommended. The bit that mentions flow identifiers shouldn't presume so much about how these frames will be used. The only point you need to make is that it is up to the protocol in use to define how the receiver of a DATAGRAM frame processes that frame. If you are going to make a point, you might observe that it might be desirable in some protocols to have multiple logical entities receiving DATAGRAM frames, in which case it is up to the protocol to define how DATAGRAM frames are efficiently routed to one of those entities. Is it illegal to send an empty DATAGRAM frame? > https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram-01 I would frame this slightly differently, to the above point: This creates a system of "flow identifiers" to allow for concurrent use of DATAGRAM frames by multiple extensions without creating contention. Except that it doesn't entirely... You should mention that signaling about flow identifiers is necessary, but that is the responsibility of the protocol that defines the usage. If you don't signal, how does a receiver know that flow ID 1 maps to usage foo and flow ID 2 maps to usage bar? Also, you should explain that there is no general limit to the flow identifier space, though protocols might want to provide mechanisms to limit usage to prevent resource exhaustion. This will depend on the protocol, of course. Some protocols might not expend resources when creating flow IDs. From nobody Wed Oct 23 11:53:57 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F8012087B for ; Wed, 23 Oct 2019 11:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=ham 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 s6eLV-I4w6_v for ; Wed, 23 Oct 2019 11:53:51 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720104.outbound.protection.outlook.com [40.107.72.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FAC12029C for ; Wed, 23 Oct 2019 11:53:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CdqyIw0eextgtCZOwPrherbl4nd84yNKw6YIc0toYTT+3XXR63yT+fHdXa19OfHG47L/GoxbFhvEwoeR5veHsW9OZBqfA8m1sXZR2Ib+dgbE2dxnKwpD3362U0iIfq6r0vySDTcM7yZ5n/XpFlJ6cyVwI5m0agjTtcMr3Tg4IhsM3jUI0kgfk7vL+ftBTkFNdu+39ZvsLuoXbls0LS4Oh2eziNsY/SNFT5w3GGgeqHbqEPv2rR7Z/0FKALZv1Di4DEzPUEWD38m383xu7XS2Wbg7p73EPAmuiwbXkdl9IzwBqdkC5yo7yemMaE5BYHOMkVKVUExO+XoP8FRsLjlrgw== 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=phawMbFtwT3ITsoMSerLwCip9g5sjLJbIw1fjDwbPWM=; b=UqGc/ZVx6pJ6s/RPayWFBMGorWNQ9t/3KqtU8OIBC/8a3JGYkDr57Lnc89ANh8XZB4aQ815cr464gcqxAufH9XYT3pdRdm7WxX4nKVw6R4ZpQ6jOt3vylMkHx0lGrSEc20j5lUHVAIP/iYLabKtOHMBdwsRRpAVtt2L1ICuQwaBJ0yUnuh4Orb7FRPrFpnKIBIJSavHwW00J0CjuHo2TPW8PD2mrkiteZEDRiEwuLJ7ObNtp0frgD/J+WGfxah4BaDRxz0Sowjh0IgyC+kmcoa56D8t9aSqa8dtGd2jWBo16EOQoMaugWuwpglmcbF7XIVdXlgCMRT2PKo7/CPbRMA== 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=phawMbFtwT3ITsoMSerLwCip9g5sjLJbIw1fjDwbPWM=; b=aDGmDRt222ehKJMivRx7aGuS1ZNmOKHrrKaAhiWW3dClnVVyVHsDE1BdkpV1n80l/URC+DY9V7QZpB2baFLbCRg0dcUzSYz7Z1xUgYRd2fRK2V7XCVUN1CzNQ/boaXtH8JH2IpdfNEMz8hMU+ok4Xbi1jNXWZImLe272D29TyM4= Received: from BN6PR2201MB1700.namprd22.prod.outlook.com (10.161.152.144) by BN6PR2201MB1715.namprd22.prod.outlook.com (10.161.158.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.20; Wed, 23 Oct 2019 18:53:32 +0000 Received: from BN6PR2201MB1700.namprd22.prod.outlook.com ([fe80::d9e:768a:ed0e:5a04]) by BN6PR2201MB1700.namprd22.prod.outlook.com ([fe80::d9e:768a:ed0e:5a04%3]) with mapi id 15.20.2367.022; Wed, 23 Oct 2019 18:53:31 +0000 From: Mike Bishop To: David Schinazi , Jana Iyengar CC: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , IETF QUIC WG , Martin Thomson , Kazuho Oku Subject: RE: Consensus Calls for Transport/TLS issues, post-Cupertino Thread-Topic: Consensus Calls for Transport/TLS issues, post-Cupertino Thread-Index: AQHViHGZIuF5g6IoEE6LYrhgawqNGqdl3+KAgAACSQCAABB9gIAAJugAgAAEuICAACuwgIAAzYuAgAF9CnA= Date: Wed, 23 Oct 2019 18:53:31 +0000 Message-ID: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> 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: [2600:2b00:931f:a301:74fe:e1eb:9fd7:63dc] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8a86e60f-f6d1-4086-adbc-08d757ea4cd3 x-ms-traffictypediagnostic: BN6PR2201MB1715: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 019919A9E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(396003)(346002)(136003)(366004)(39830400003)(376002)(51444003)(189003)(199004)(31014005)(7696005)(25786009)(66946007)(76116006)(561944003)(64756008)(6116002)(790700001)(5660300002)(66476007)(66446008)(229853002)(52536014)(66556008)(74316002)(508600001)(76176011)(99286004)(316002)(54906003)(8936002)(110136005)(81156014)(81166006)(8676002)(14454004)(7736002)(440504004)(517774005)(54896002)(6306002)(9686003)(71200400001)(71190400001)(236005)(102836004)(14444005)(55016002)(6436002)(66574012)(6506007)(5070765005)(53546011)(186003)(476003)(6246003)(4326008)(11346002)(46003)(486006)(446003)(2906002)(33656002)(256004)(86362001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR2201MB1715; H:BN6PR2201MB1700.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: ZVZH+dorZZijRjTm2n4lemZ12waWlSXeeyId4dK618XWmqzG+bbetRGa2BObt+7O4xAdR4jBagdfsbYDTtvb298pCxcV2rexDCTMcoPEb+1KrR1fUNVr58Op3KmpB4W1/LO2ce6te7oDhU6zAjL8d4NGNbK7geCEpOh5cyQVRFg+4CbhaYIO9L/HUr2vM2fPkZuz8k0fwDVdJ43Q8n+zEPXV1Ih3xa4nS1fT+5t8Lcl+XgjfmMC7yhZEem/HeT+ANcDkYkHNHWdUvosBKp12+EDbY4eaHZo0pJ8I6f31lUx3zkhn3opjNNumLPPqiKlpvlPrpOYMjTYJVyn9eLJYknV5OhiQvGYFXcqpxOr+yAMGgwBLF65fm5hHTypnc8M9J5LihloRjCDn0HNLAJhQXG01cjf3S6X20aySRPsUvvTu29uhmK4Ol+1wBXQHODqc x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR2201MB17008576E4F8400B5DDB696FDA6B0BN6PR2201MB1700_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 8a86e60f-f6d1-4086-adbc-08d757ea4cd3 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2019 18:53:31.6840 (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: 4CHAmCCvTwVfRmciTPCberW3wB3TvY8EbeP5elwqY8gh/kSZkQR595qJ0BeuN/FBaOVPRP2ZD8TE2VWxcfyBkQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1715 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, 23 Oct 2019 18:53:55 -0000 --_000_BN6PR2201MB17008576E4F8400B5DDB696FDA6B0BN6PR2201MB1700_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB3ZeKAmXZlIGFtcGx5IGRlbW9uc3RyYXRlZCB0aGF0IGltcGxpY2l0IHNpZ25hbHMg ZG9u4oCZdCB3b3JrLiAgSeKAmWQgbGlrZSB0byBzZWUgYW4gZXhwbGljaXQgY29uZmlybWF0aW9u IG9mIGhhbmRzaGFrZSBjb21wbGV0aW9uIHRoYXQgaGFwcGVucyBhdCAxLVJUVC4NCg0KRnJvbTog UVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRGF2aWQgU2NoaW5hemkN ClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjIsIDIwMTkgNDowNyBQTQ0KVG86IEphbmEgSXllbmdh ciA8anJpLmlldGZAZ21haWwuY29tPg0KQ2M6IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1p a2tlbGZqQGdtYWlsLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBU aG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldD47IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5j b20+DQpTdWJqZWN0OiBSZTogQ29uc2Vuc3VzIENhbGxzIGZvciBUcmFuc3BvcnQvVExTIGlzc3Vl cywgcG9zdC1DdXBlcnRpbm8NCg0KKzENCg0KSSB0aGluayB0aGUgdGV4dCB3ZSBoYXZlIGluIHRo ZSBzcGVjIHRvZGF5IGlzIGJldHRlciB0aGFuIHRoZSBwcm9wb3NhbCB0byBuZXZlciBkaXNjYXJk IHRoZSBoYW5kc2hha2Uga2V5cy4NCk15IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gc3BlbmQgdGhl IHRpbWUgdG8gZml4IHRoZSBpc3N1ZSwgYW5kIG5vdCBhZGQgYSB0ZW1wb3Jhcnkgd29ya2Fyb3Vu ZCBmb3Igbm93Lg0KDQpPbiBUdWUsIE9jdCAyMiwgMjAxOSBhdCAxMjo1MSBBTSBKYW5hIEl5ZW5n YXIgPGpyaS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86anJpLmlldGZAZ21haWwuY29tPj4gd3JvdGU6 DQpJIGFncmVlIHdpdGggS2F6dWhvIGhlcmUuIFRoZSBpc3N1ZSBvZiBtaWdyYXRpb24gd2FzIG5v dCBvbmUgd2UgaGFkIGNvbnNpZGVyZWQuIEkgd2FzIGdvaW5nIHRocm91Z2ggdGhpcyB3aXRoIEth enVobywgYW5kIHdlIG1heSBoYXZlIGlkZW50aWZpZWQgeWV0IGFub3RoZXIgaXNzdWUgd2l0aCBo YW5kc2hha2UgcmV0cmFuc21pc3Npb25zIGFuZCBtaWdyYXRpb24sIHdoaWNoIGlzIHByZXNlbnQg aW4gdGhlIGN1cnJlbnQgc3BlYy4NCg0KU2FkbHksIEkgZG9uJ3QgdGhpbmsgd2UgY2FuIGNhbGwg dGhpcyBpc3N1ZSBkb25lLg0KDQpPbiBUdWUsIE9jdCAyMiwgMjAxOSBhdCAyOjE0IFBNIE1pa2tl bCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpA Z21haWwuY29tPj4gd3JvdGU6DQpXaXRob3V0IGEgd2F5IHRvIG1vdmUgdG8gYSBzaW5nbGUgUE4g c3BhY2UgSSBmaW5kIHRoaXMgYSBkZWFsIGJyZWFrZXIuIEkgbWlnaHQgZG8gYSBjdXN0b20gdmVy c2lvbiBvZiB0aGUgcHJvdG9jb2wuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyYTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNA aWV0Zi5vcmc+PiBww6UgdmVnbmUgYWYgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxt YWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbT4+DQpTZW5kdDogdGlyc2RhZywgb2t0b2JlciAyMiwg MjAxOSA2OjU4IEFNDQpUaWw6IE1hcnRpbiBUaG9tc29uDQpDYzogSUVURiBRVUlDIFdHDQpFbW5l OiBSZTogQ29uc2Vuc3VzIENhbGxzIGZvciBUcmFuc3BvcnQvVExTIGlzc3VlcywgcG9zdC1DdXBl cnRpbm8NCg0KDQoNCjIwMTnlubQxMOaciDIy5pelKOeBqykgMTE6MzggTWFydGluIFRob21zb24g PG10QGxvd2VudHJvcHkubmV0PG1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldD4+Og0KT24gVHVlLCBP Y3QgMjIsIDIwMTksIGF0IDEyOjM5LCBOaWNrIEJhbmtzIHdyb3RlOg0KPiAgSSdkIGFsc28gcHJl ZmVyIHRvIGZpeCB0aGUgcHJvYmxlbSwgZXZlbiBpZiBpdCBtZWFucyBicmluZ2luZyBiYWNrDQo+ IHNvbWV0aGluZyBsaWtlIFJFVElSRV9LRVkuDQoNCkkgd291bGQgcHJlZmVyIHRvIHRoaW5rIG9m IHRoaXMgcHJvcG9zZWQgcmVzb2x1dGlvbiBhcyBhIHRlbXBvcmFyeSBvbmUuICBJIGRvbid0IHRo aW5rIHRoYXQgd2UgYWdyZWVkIHRvIGtlZXAgdGhlIGhhbmRzaGFrZSBrZXlzIGluZGVmaW5pdGVs eSwgb25seSB0aGF0IHdlIHdvdWxkIHVzZSB0aGF0IG9wdGlvbiBhcyBhIGZhbGxiYWNrIHBvc2l0 aW9uIHVudGlsIHdlIGZvdW5kIGEgYmV0dGVyIHNvbHV0aW9uLg0KDQpJIG1pZ2h0IHBvaW50IG91 dCB0aGF0ICMzMTIxIGlzIG5vdCBwcm9wb3NhbC1yZWFkeSBhcyBhIHdheSB0byByZXNvbHZlICMy ODYzLiBUaGF0IGlzIGJlY2F1c2UgaXQgZG9lcyBub3QgZGVmaW5lIGhvdyB0byBzZW5kIGFuZCBy ZWNlaXZlIEhhbmRzaGFrZSBwYWNrZXRzIHVudGlsIG9yIGFmdGVyIG1pZ3JhdGlvbiBoYXBwZW5z LiBUaGVyZSB3b3VsZCBiZSBhIGRlYWRsb2NrIHVubGVzcyBib3RoIGVuZHBvaW50cyBhZ3JlZSBv biBob3cgdGhhdCBzaG91bGQgYmUgZG9uZSAoZS5nLiwgaG93IHRvIHNlbGVjdCBTQ0lELCB3aGV0 aGVyIHRoZSBwYXRoIHVzZWQgZm9yIEhhbmRzaGFrZSBwYWNrZXRzIG1pZ3JhdGVzIHRvbykuDQoN CldpdGhvdXQgdGhhdCBiZWluZyBjbGFyaWZpZWQsIGNhbiB3ZSBzYXkgdGhhdCB3ZSBhcmUgcmVh ZHkgZm9yIGEgY29uc2Vuc3VzIGNhbGw/DQoNCg0KT24gdGhhdCBiYXNpcywgSSB0aGluayB0aGF0 IGl0IHdvdWxkIGJlIGJlc3QgaWYgd2Ugb3BlbiBhIG5ldyBpc3N1ZSB0aGF0IHNheXMgIkhhbmRz aGFrZSBrZXlzIGNhbid0IGV2ZXIgYmUgZHJvcHBlZCIuDQoNCldlIG1pZ2h0IHN0aWxsIGNvbmNs dWRlIG5vdCB0byBhZGRyZXNzIHRoYXQgaXNzdWUsIGJ1dCB0aGUgaW1wb3J0YW50IHRoaW5nIGlz IHRvIGVuc3VyZSB0aGF0IGFueSBzb2x1dGlvbiB3b3JrcyBwcm9wZXJseS4NCg0KDQotLQ0KS2F6 dWhvIE9rdQ0K --_000_BN6PR2201MB17008576E4F8400B5DDB696FDA6B0BN6PR2201MB1700_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDgg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGlu ayB3ZeKAmXZlIGFtcGx5IGRlbW9uc3RyYXRlZCB0aGF0IGltcGxpY2l0IHNpZ25hbHMgZG9u4oCZ dCB3b3JrLiZuYnNwOyBJ4oCZZCBsaWtlIHRvIHNlZSBhbiBleHBsaWNpdCBjb25maXJtYXRpb24g b2YgaGFuZHNoYWtlIGNvbXBsZXRpb24gdGhhdCBoYXBwZW5zIGF0IDEtUlRULjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3Jn Jmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KRGF2aWQgU2NoaW5hemk8YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgT2N0b2JlciAyMiwgMjAxOSA0OjA3IFBNPGJyPg0KPGI+VG86PC9iPiBKYW5h IEl5ZW5nYXIgJmx0O2pyaS5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2tl bCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0O21pa2tlbGZqQGdtYWlsLmNvbSZndDs7IElFVEYgUVVJ QyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1hcnRpbiBUaG9tc29uICZsdDttdEBsb3dlbnRy b3B5Lm5ldCZndDs7IEthenVobyBPa3UgJmx0O2thenVob29rdUBnbWFpbC5jb20mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBDb25zZW5zdXMgQ2FsbHMgZm9yIFRyYW5zcG9ydC9UTFMgaXNz dWVzLCBwb3N0LUN1cGVydGlubzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0Mzsx PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRo ZSB0ZXh0IHdlIGhhdmUgaW4gdGhlIHNwZWMgdG9kYXkgaXMgYmV0dGVyIHRoYW4gdGhlIHByb3Bv c2FsIHRvIG5ldmVyIGRpc2NhcmQgdGhlIGhhbmRzaGFrZSBrZXlzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgcHJlZmVyZW5jZSB3b3VsZCBi ZSB0byBzcGVuZCB0aGUgdGltZSB0byBmaXggdGhlIGlzc3VlLCBhbmQgbm90IGFkZCBhIHRlbXBv cmFyeSB3b3JrYXJvdW5kIGZvciBub3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgT2N0IDIyLCAyMDE5IGF0IDEyOjUxIEFNIEph bmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaS5pZXRmQGdtYWlsLmNvbSI+anJpLmll dGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIEthenVobyBo ZXJlLiBUaGUgaXNzdWUgb2YgbWlncmF0aW9uIHdhcyBub3Qgb25lIHdlIGhhZCBjb25zaWRlcmVk LiBJIHdhcyBnb2luZyB0aHJvdWdoIHRoaXMgd2l0aCBLYXp1aG8sIGFuZCB3ZSBtYXkgaGF2ZSBp ZGVudGlmaWVkIHlldCBhbm90aGVyIGlzc3VlIHdpdGggaGFuZHNoYWtlIHJldHJhbnNtaXNzaW9u cyBhbmQgbWlncmF0aW9uLCB3aGljaCBpcyBwcmVzZW50IGluIHRoZSBjdXJyZW50DQogc3BlYy48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNhZGx5LCBJIGRv bid0IHRoaW5rIHdlIGNhbiBjYWxsIHRoaXMgaXNzdWUgZG9uZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBPY3QgMjIsIDIwMTkg YXQgMjoxNCBQTSBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86 bWlra2VsZmpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGhvdXQg YSB3YXkgdG8gbW92ZSB0byBhIHNpbmdsZSBQTiBzcGFjZSBJIGZpbmQgdGhpcyBhIGRlYWwgYnJl YWtlci4gSSBtaWdodCBkbyBhIGN1c3RvbSB2ZXJzaW9uIG9mIHRoZSBwcm90b2NvbC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0i MiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1f MTU4NzQwMjkwNTY1NjU5ODgwNWdtYWlsLW1fNTE0NjA4MzY1NzU5ODYxOTIyOGRpdlJwbHlGd2RN c2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJhOjwvYj4gUVVJQyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IHDDpSB2ZWduZSBhZiBLYXp1aG8gT2t1ICZsdDs8YSBocmVmPSJt YWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthenVob29rdUBnbWFp bC5jb208L2E+Jmd0Ozxicj4NCjxiPlNlbmR0OjwvYj4gdGlyc2RhZywgb2t0b2JlciAyMiwgMjAx OSA2OjU4IEFNPGJyPg0KPGI+VGlsOjwvYj4gTWFydGluIFRob21zb248YnI+DQo8Yj5DYzo8L2I+ IElFVEYgUVVJQyBXRzxicj4NCjxiPkVtbmU6PC9iPiBSZTogQ29uc2Vuc3VzIENhbGxzIGZvciBU cmFuc3BvcnQvVExTIGlzc3VlcywgcG9zdC1DdXBlcnRpbm8gPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTk8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7lubQ8L3NwYW4+MTA8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7mnIg8L3NwYW4+MjI8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ml6U8L3NwYW4+KDxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPueBqzwvc3Bhbj4pIDExOjM4 IE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bXRAbG93ZW50cm9weS5uZXQiIHRh cmdldD0iX2JsYW5rIj5tdEBsb3dlbnRyb3B5Lm5ldDwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBPY3QgMjIs IDIwMTksIGF0IDEyOjM5LCBOaWNrIEJhbmtzIHdyb3RlOjxicj4NCiZndDsmbmJzcDsgSSdkIGFs c28gcHJlZmVyIHRvIGZpeCB0aGUgcHJvYmxlbSwgZXZlbiBpZiBpdCBtZWFucyBicmluZ2luZyBi YWNrIDxicj4NCiZndDsgc29tZXRoaW5nIGxpa2UgUkVUSVJFX0tFWS48YnI+DQo8YnI+DQpJIHdv dWxkIHByZWZlciB0byB0aGluayBvZiB0aGlzIHByb3Bvc2VkIHJlc29sdXRpb24gYXMgYSB0ZW1w b3Jhcnkgb25lLiZuYnNwOyBJIGRvbid0IHRoaW5rIHRoYXQgd2UgYWdyZWVkIHRvIGtlZXAgdGhl IGhhbmRzaGFrZSBrZXlzIGluZGVmaW5pdGVseSwgb25seSB0aGF0IHdlIHdvdWxkIHVzZSB0aGF0 IG9wdGlvbiBhcyBhIGZhbGxiYWNrIHBvc2l0aW9uIHVudGlsIHdlIGZvdW5kIGEgYmV0dGVyIHNv bHV0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBtaWdodCBwb2ludCBvdXQgdGhhdCAjMzEyMSBpcyBub3QgcHJvcG9zYWwt cmVhZHkgYXMgYSB3YXkgdG8gcmVzb2x2ZSAjMjg2My4gVGhhdCBpcyBiZWNhdXNlIGl0IGRvZXMg bm90IGRlZmluZSBob3cgdG8gc2VuZCBhbmQgcmVjZWl2ZSBIYW5kc2hha2UgcGFja2V0cyB1bnRp bCBvciBhZnRlciBtaWdyYXRpb24gaGFwcGVucy4gVGhlcmUgd291bGQgYmUgYSBkZWFkbG9jayB1 bmxlc3MgYm90aCBlbmRwb2ludHMNCiBhZ3JlZSBvbiBob3cgdGhhdCBzaG91bGQgYmUgZG9uZSAo ZS5nLiwgaG93IHRvIHNlbGVjdCBTQ0lELCB3aGV0aGVyIHRoZSBwYXRoIHVzZWQgZm9yIEhhbmRz aGFrZSBwYWNrZXRzIG1pZ3JhdGVzIHRvbykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGhvdXQgdGhhdCBiZWluZyBjbGFyaWZpZWQsIGNh biB3ZSBzYXkgdGhhdCB3ZSBhcmUgcmVhZHkgZm9yIGEgY29uc2Vuc3VzJm5ic3A7Y2FsbD88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiB0aGF0IGJhc2lzLCBJIHRoaW5r IHRoYXQgaXQgd291bGQgYmUgYmVzdCBpZiB3ZSBvcGVuIGEgbmV3IGlzc3VlIHRoYXQgc2F5cyAm cXVvdDtIYW5kc2hha2Uga2V5cyBjYW4ndCBldmVyIGJlIGRyb3BwZWQmcXVvdDsuJm5ic3A7DQo8 YnI+DQo8YnI+DQpXZSBtaWdodCBzdGlsbCBjb25jbHVkZSBub3QgdG8gYWRkcmVzcyB0aGF0IGlz c3VlLCBidXQgdGhlIGltcG9ydGFudCB0aGluZyBpcyB0byBlbnN1cmUgdGhhdCBhbnkgc29sdXRp b24gd29ya3MgcHJvcGVybHkuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5LYXp1aG8gT2t1PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR2201MB17008576E4F8400B5DDB696FDA6B0BN6PR2201MB1700_-- From nobody Wed Oct 23 12:26:44 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082CA1208CE for ; Wed, 23 Oct 2019 12:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (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 eUV47A8l-2JM for ; Wed, 23 Oct 2019 12:26:41 -0700 (PDT) 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 3C89E12087B for ; Wed, 23 Oct 2019 12:26:41 -0700 (PDT) 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 x9NJLm0M007869; Wed, 23 Oct 2019 12:26:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=qd8XKqP2bi42LxLGCpeZd0spgkAnOaIO/RQl5deI2Dw=; b=lcBOBBguftziLAFV3HOszH23aL1kcCmZdLCg9ZpFgehuyVXXsOw2WeWvm7MJewtjXtgF 4bPkAyjddbpyy9+ZfVEX3zzfsFdr21oUSv4RTHbD51cJ8NRHkf8P7DwjIUlV/41ST46W kpcke2/Xa0dLUfs42cQSxyavqfjRyOsIihQOxdN1Be9qfrMxmB3cPPeOz1kTZJhBQa9U c+ddA0Ozubp9iw18KtpiSKmtYAnJMxBjQjXe94ANsGJPqoe/LxMFjO+naz3KByehV1LS Zq3gX8UMwUuZxRUKK74lYDjtqdwDpFE0lXTo1PED39fzFbc1VduD3UnxKQ4FwfqSkL9X dw== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2vrjr4r8ch-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 23 Oct 2019 12:26:39 -0700 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PZU008ONE0EMRD0@ma1-mtap-s01.corp.apple.com>; Wed, 23 Oct 2019 12:26:38 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PZU00M00DRWYZ00@nwk-mmpp-sz09.apple.com>; Wed, 23 Oct 2019 12:26:38 -0700 (PDT) X-Va-A: X-Va-T-CD: c23d783ab285e2e2724c3baee78f3ad6 X-Va-E-CD: 5e699a591861157762edff7cdffac528 X-Va-R-CD: 1f5da5ec67fe3e2c57041029748c0f93 X-Va-CD: 0 X-Va-ID: 3bbfb244-2b77-40fb-9de6-cbbe49994a4a X-V-A: X-V-T-CD: c23d783ab285e2e2724c3baee78f3ad6 X-V-E-CD: 5e699a591861157762edff7cdffac528 X-V-R-CD: 1f5da5ec67fe3e2c57041029748c0f93 X-V-CD: 0 X-V-ID: e2bb7b4e-9020-4f8c-aa0c-823324e1368a X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-23_04:,, signatures=0 Received: from [17.234.44.100] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PZU0097QE0DLP70@nwk-mmpp-sz09.apple.com>; Wed, 23 Oct 2019 12:26:38 -0700 (PDT) Sender: rpaulo@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Re: Updates to QUIC Datagrams From: Rui Paulo In-reply-to: <7ac87af3-b49b-4e93-8f70-db35a74419a8@www.fastmail.com> Date: Wed, 23 Oct 2019 12:26:35 -0700 Cc: quic@ietf.org Content-transfer-encoding: quoted-printable Message-id: References: <7ac87af3-b49b-4e93-8f70-db35a74419a8@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3594.4.19) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-23_04:, , 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, 23 Oct 2019 19:26:43 -0000 On Oct 22, 2019, at 17:22, Martin Thomson wrote: >=20 > Thanks for doing this, I think that this is a reasonable approach. >=20 > On Wed, Oct 23, 2019, at 08:19, David Schinazi wrote: >> https://tools.ietf.org/html/draft-pauly-quic-datagram-04 >=20 > Simple is good. >=20 > This probably need to say more about 0-RTT. That is, explain that = protocols that use DATAGRAM in 0-RTT need to define a protocol-specific = profile that explains what usage patterns are safe and what anti-replay = countermeasures are recommended. That=E2=80=99s a valid point and I brought up other 0-RTT considerations = in July: https://github.com/tfpauly/draft-pauly-quic-datagram/issues/14 > Is it illegal to send an empty DATAGRAM frame? With the removal of the flow identifiers from the transport, I don=E2=80=99= t see reason why it=E2=80=99s even needed. That said, I don=E2=80=99t = oppose it being legal. =E2=80=94 Rui Paulo From nobody Wed Oct 23 19:40:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8793512012C for ; Wed, 23 Oct 2019 19:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8L8s5hst_igy for ; Wed, 23 Oct 2019 19:39:58 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8926612010D for ; Wed, 23 Oct 2019 19:39:57 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id y3so23249131ljj.6 for ; Wed, 23 Oct 2019 19:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Th5AG/vWegVisQSq7p4pmGi5zbClVC85aokif97HsQM=; b=HrIfDKLlySYjhQGA9qNyOxBuySR56OvOgA7+dg+M7GNsBLh3Z72i4oixcjYSCMEdW3 HBSkTsvB81xVgjb/OFweoQG6Sjdmja3Ibs2pJZ3zXVmu5Guneo1iFCasd+yOzNilfboi wF6oGJM6PdV+eLAnplsJGHu8GlVTophIVCUF9DK37rajCVOsKdNT56eDIn/j9KaX95YZ 5p1iMj3yymV3fsEGcjEU3umHlQZ7h8RoU1F1NlhuIClVKRF0SDL+yBY24aemkDFpsbN1 3Fhbgiy0hZ88c/70oY3cV3lpNznsDrbcUXWsxB7LcudIHS/RhvlHubqroEimm5Cz/3Gh RhtA== 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=Th5AG/vWegVisQSq7p4pmGi5zbClVC85aokif97HsQM=; b=GzwZoYf8IrJTOiRqu6JRjD3lS3u+DTnNkBeMIV4OWJAUyzmYrlk7eUVPR0xVHe8rP1 2ps/HVEMJRLdF71phqAcCBlWode50GbAtsQVNEhKDHRFu4ulNUBlqbqSCfKL+1X2Chsh jRFmPp5ADhtAOt/VGNtadtVREorkbRI86J1nM0xts/KZE1KP7FXq2+uCo8vDqx9p03hn qwU+uTJ4Sr74H1JHjY73oMNWKBPSZWBeoqI18wYR/dvdqqovebmv/7H8oXQtWh2Wo/ks DgLPjq1q586ZSj9vjwfT5evWMBBvNmb09rngHiy8WrlC8ifsNvuRdqAiwmcEVDE37v3t K0Bg== X-Gm-Message-State: APjAAAX1ATO/ydZAP0jmb3TkGuR40jYL01xiWT2rwmlWhPnpbK07SaPL 4GyEyuF0mXpeOaywfdHcCBLe51aIfMrU/664Nhs= X-Google-Smtp-Source: APXvYqxY1Rvp40lITOVXoDw8IAibJTTDc0jy7SLsdavbB+YAOP3PyWqbUgHs9RTPxfaVVBHcEqSH5ejnmWXnpWenzac= X-Received: by 2002:a2e:88d0:: with SMTP id a16mr24349851ljk.39.1571884795669; Wed, 23 Oct 2019 19:39:55 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> In-Reply-To: From: Jana Iyengar Date: Thu, 24 Oct 2019 11:39:44 +0900 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Mike Bishop Cc: David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000dfb0a805959ef244" 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, 24 Oct 2019 02:40:01 -0000 --000000000000dfb0a805959ef244 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yup. We need to get this over with in the dumbest way possible. On Thu, Oct 24, 2019 at 3:53 AM Mike Bishop wrote: > I think we=E2=80=99ve amply demonstrated that implicit signals don=E2=80= =99t work. I=E2=80=99d > like to see an explicit confirmation of handshake completion that happens > at 1-RTT. > > > > *From:* QUIC *On Behalf Of * David Schinazi > *Sent:* Tuesday, October 22, 2019 4:07 PM > *To:* Jana Iyengar > *Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen ; IETF QUIC W= G < > quic@ietf.org>; Martin Thomson ; Kazuho Oku < > kazuhooku@gmail.com> > *Subject:* Re: Consensus Calls for Transport/TLS issues, post-Cupertino > > > > +1 > > > > I think the text we have in the spec today is better than the proposal to > never discard the handshake keys. > > My preference would be to spend the time to fix the issue, and not add a > temporary workaround for now. > > > > On Tue, Oct 22, 2019 at 12:51 AM Jana Iyengar wrote: > > I agree with Kazuho here. The issue of migration was not one we had > considered. I was going through this with Kazuho, and we may have > identified yet another issue with handshake retransmissions and migration= , > which is present in the current spec. > > > > Sadly, I don't think we can call this issue done. > > > > On Tue, Oct 22, 2019 at 2:14 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > > Without a way to move to a single PN space I find this a deal breaker. I > might do a custom version of the protocol. > > > > > ------------------------------ > > *Fra:* QUIC p=C3=A5 vegne af Kazuho Oku < > kazuhooku@gmail.com> > *Sendt:* tirsdag, oktober 22, 2019 6:58 AM > *Til:* Martin Thomson > *Cc:* IETF QUIC WG > *Emne:* Re: Consensus Calls for Transport/TLS issues, post-Cupertino > > > > > > > > 2019=E5=B9=B410=E6=9C=8822=E6=97=A5(=E7=81=AB) 11:38 Martin Thomson : > > On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote: > > I'd also prefer to fix the problem, even if it means bringing back > > something like RETIRE_KEY. > > I would prefer to think of this proposed resolution as a temporary one. = I > don't think that we agreed to keep the handshake keys indefinitely, only > that we would use that option as a fallback position until we found a > better solution. > > > > I might point out that #3121 is not proposal-ready as a way to resolve > #2863. That is because it does not define how to send and receive Handsha= ke > packets until or after migration happens. There would be a deadlock unles= s > both endpoints agree on how that should be done (e.g., how to select SCID= , > whether the path used for Handshake packets migrates too). > > > > Without that being clarified, can we say that we are ready for a > consensus call? > > > > > On that basis, I think that it would be best if we open a new issue that > says "Handshake keys can't ever be dropped". > > We might still conclude not to address that issue, but the important thin= g > is to ensure that any solution works properly. > > > > > -- > > Kazuho Oku > > --000000000000dfb0a805959ef244 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yup. We need to get this over with in the dumbest way poss= ible.

On Thu, Oct 24, 2019 at 3:53 AM Mike Bishop <mbishop@evequefou.be> wrote:

I think we=E2=80=99ve amply demonstrated that implic= it signals don=E2=80=99t work.=C2=A0 I=E2=80=99d like to see an explicit co= nfirmation of handshake completion that happens at 1-RTT.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = David Schinazi
Sent: Tuesday, October 22, 2019 4:07 PM
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; IETF QUIC WG <= quic@ietf.org>; M= artin Thomson <mt= @lowentropy.net>; Kazuho Oku <kazuhooku@gmail.com>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertin= o

=C2=A0

+1

=C2=A0

I think the text we have in the spec today is better= than the proposal to never discard the handshake keys.

My preference would be to spend the time to fix the = issue, and not add a temporary workaround for now.

=C2=A0

On Tue, Oct 22, 2019 at 12:51 AM Jana Iyengar <jri.ietf@gmail.com> wrote:

I agree with Kazuho here. The issue of migration was= not one we had considered. I was going through this with Kazuho, and we ma= y have identified yet another issue with handshake retransmissions and migr= ation, which is present in the current spec.

=C2=A0

Sadly, I don't think we can call this issue done= .

=C2=A0

On Tue, Oct 22, 2019 at 2:14 PM Mikkel Fahn=C3=B8e J= =C3=B8rgensen <m= ikkelfj@gmail.com> wrote:

Without a way to move to a single PN space I find th= is a deal breaker. I might do a custom version of the protocol.

=C2=A0

=C2=A0

Fra: QUIC <quic-bounces@ietf.org> p=C3=A5 vegne af = Kazuho Oku <kaz= uhooku@gmail.com>
Sendt: tirsdag, oktober 22, 2019 6:58 AM
Til: Martin Thomson
Cc: IETF QUIC WG
Emne: Re: Consensus Calls for Transport/TLS issues, post-Cupertino <= u>

=C2=A0

=C2=A0

=C2=A0

2019=E6= =9C=8822=E6=97=A5<= /span>(=E7=81=AB) = 11:38 Martin Thomson <mt@lowentropy.net>:

On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote: >=C2=A0 I'd also prefer to fix the problem, even if it means bringin= g back
> something like RETIRE_KEY.

I would prefer to think of this proposed resolution as a temporary one.=C2= =A0 I don't think that we agreed to keep the handshake keys indefinitel= y, only that we would use that option as a fallback position until we found= a better solution.

=C2=A0

I might point out that #3121 is not proposal-ready a= s a way to resolve #2863. That is because it does not define how to send an= d receive Handshake packets until or after migration happens. There would b= e a deadlock unless both endpoints agree on how that should be done (e.g., how to select SCID, whether the pa= th used for Handshake packets migrates too).

=C2=A0

Without that being clarified, can we say that we are= ready for a consensus=C2=A0call?

=C2=A0


On that basis, I think that it would be best if we open a new issue that sa= ys "Handshake keys can't ever be dropped".=C2=A0

We might still conclude not to address that issue, but the important thing = is to ensure that any solution works properly.


=C2=A0

--

Kazuho Oku

--000000000000dfb0a805959ef244-- From nobody Wed Oct 23 20:27:18 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD0312010D for ; Wed, 23 Oct 2019 20:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Uuv+Tg9j; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sM7i2X7R Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j894Yh5_vaPk for ; Wed, 23 Oct 2019 20:27:14 -0700 (PDT) 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 B54F41200F6 for ; Wed, 23 Oct 2019 20:27:14 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 404554A3 for ; Wed, 23 Oct 2019 23:27:13 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 23 Oct 2019 23:27:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm3; bh=9d1lFnk1NK6sQdbM9Uh7sWE0rsVQ8GvW+zoU4ES+TgM=; b=Uuv+Tg9j 29xzQI3R57CBSV8+uQv1ZohC+CdsHsWhcxQWzEnGf7xEUoP9k56+Tep//20iE3ME vJF29fHzAnw4SOlJm/pd2/IhM9FeBlrrSmxHozUI0Vgc/jY7h3WF9Ddr0+PRdNXo RSIUWLrb6w0kY/tkDPWqq9vdjQ0vC8e7zOM8OYFBydmmnJcwsaRYslJhUuX5360t vGmRHC9Z49V/HMZFTG05bB7Rg7ZL4QMu72hZEKizwkHpCPokuIKScDc7dHpe/MrL MGpnFYv5XBQPDv3Mo0xKp7aPe4vrV5dgOFwAoAFYFgjEj4bYigJ/wDuqqeiCtVig qfirxyQpyCpFww== 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=9d1lFnk1NK6sQdbM9Uh7sWE0rsVQ8 GvW+zoU4ES+TgM=; b=sM7i2X7RJAfZbUevTpws0Ts/BThyCpdeTOqCAv9rj5J0z hwrN56+I/8FkPANRudkbazVZ7z2LslTKwU+W/pSvmuuRJ4QsnXnVM4/mNQbi3Yms CyLwrFa2SHSeZ5fRYBb3Y4ivl5CIPRI2YgQrR/n5i4wUzwRaMD4jP3Wg+bP2ZGBw gF5RYihMxx3wsHGMczuPxmdofwulXYKCPSJY92cHnQYqnz0MBPSqnbnHvFwyfmLB 6qvz/dR+DsN8+u05hHDfnCH3+YcuKnNfL+YAfXQufvFci0lXBaZOik6CUJetfIc0 3xY1IhXzLXEW6Cvw0PH5RWcQK9MkCQ6WZ7pn0dT5w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrledtgdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 69083E00A5; Wed, 23 Oct 2019 23:27:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: Date: Thu, 24 Oct 2019 14:26:52 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Making QUIC less constraining for innovation 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: Thu, 24 Oct 2019 03:27:17 -0000 Issue 3020 (https://github.com/quicwg/base-drafts/issues/3020) raises the question of IANA registration policies in the core drafts. The thesis is that the constraints on registrations pushes people into a small space of available numbers (in that specific case the space is 256 values) or has registration requirements that are too onerous. We aim to address this in most places in QUIC and h3 with varints, which all have a similar registration scheme. I think that David's intent with #3020 was to push more of our code to use varints. But we're nothing if not consistent when it comes to these things and after lengthy discussion in Cupertino the group decided not to use varints for transport parameters. Instead, we want to revise the registration policies to better allow implementations to experiment with new features (which is what I think David intended by the use of the word "innovation"). For varints, we divide the space into three partitions: 0-63 = Standards Action 64-16383 = Specification Required 16384+ = Private Use David's PR #3109 (https://github.com/quicwg/base-drafts/pull/3109) proposes the same split for transport parameters. That greatly increases the size of the Private Use space. The Private Use section is still a lot smaller than with varints, but the cut points are the same and the belief is that ~2^16 values is plenty of room to play with. The main problem with all of these policies is described in RFC 6648, namely that a codepoint from Private Use space can get wide adoption. RFC 6648 basically concludes that these can be impossible to move to a registered portion of the codepoint space. Furthermore, RFC 8126 says that IANA doesn't register these codepoints and so no mechanism exists to prevent collisions. That's a shame, because that's what registries are for. --- I propose that we instead remove Private Use space from specifications and instead adopt a Specification Required policy for all codepoints except the first 64 values of a varint value (we can keep that as Standards Action). To allow for experimentation and proprietary extensions, add the ability to provisionally register any codepoint. Provisional registrations are registrations can omit values that would be required for a permanent registration, include an expiry date, and operate on First-Come, First-Served basis. This is intentionally lightweight so that anyone can initiate registration, even without complete information. A Designated Expert will be assigned to ensure that the registries don't end up crammed with junk and to discourage use of codepoints with small encodings, large blocks of codepoints, or codepoints that are likely to be used by future standardization (those that are adjacent the first contiguous block of allocated values, which we might want to use later). I emphasize discourage intentionally, because this can't be a hard rule - this is why we use a human for this job and not a machine. To recognize that people will inevitably use values before they even provisionally register them, we should encourage people to select from the space at random. Random selection from a larger space greatly reduces the chances of collision. For varints, people will be encouraged to choose values that have the longest encoding tolerable for their use case. In particular, extensions that are fully proprietary will be encouraged to use values that encode to 4 or 8 bytes. I recognize that this might not avoid people having inflated notions of the value of their extension. And maybe it's not worth protecting the 2 byte space on the basis that we might never run out of the 16320 values available. Either way, I think that it's worth providing some text to help the expert in case this protocol gets unexpectedly busy. Registrants are specify the codepoint they want when registering, rather than have IANA make an allocation on request. For standards that want to use codepoints that are adjacent the first set of values, we might still use TBD in specifications to avoid having the same value specified in multiple specifications. The TLS working group had the same codepoint in three different drafts last year, which wasn't great. Provisional registrations can be removed or refreshed after a year (period negotiable) after consultation with the expert, who is encouraged to consult with the broader community. Experts would be advised to refresh registrations unless there is evidence that the value is no longer in use and there is a need to free up space for new registrations. The motivation behind this proposal is to recognize that the overriding goal of a protocol registry is to avoid the interoperability failures that arise from codepoint collisions. In particular, registries are not an access control mechanism. From nobody Wed Oct 23 21:33:27 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B155120114 for ; Wed, 23 Oct 2019 21:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=RBui3yN2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OArvCv2R Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCMEfqUGGpMw for ; Wed, 23 Oct 2019 21:33:22 -0700 (PDT) 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 05F8612006E for ; Wed, 23 Oct 2019 21:33:22 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1E73C20D0F; Thu, 24 Oct 2019 00:33:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 24 Oct 2019 00:33:21 -0400 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=t wKUcL32C5+fp9zSA6He1Nik34Qln7YZbsSaOWYH2Tc=; b=RBui3yN2CPYT8hoVF ZroJkMUxAtctka1GT4uo8Za9oiqpZuNbAwaSqgIHtMDmoWT83kpB1UmmwmztKuOO 5HTLNy2U97Da5spNO9gQE2jSta8TEvWg0iMFgMFfeNWyW9dRrZXk2D5WDEP2jGbs EN+9hC7wz2MT7sg4mqw6WgpNNOZruATxVumDUERWrzi1eyLBJXJFwbw+ojDPjudq UFhl2q2Ie1ERy/7H7megcqqr7ke+KcmuHCaMUKaPAAji9qeOf/M6SaycEYosUB59 MCQM1Jr+01v5mjqMA7jDvADDuisBLxqmqlmc6En6lGlG5g8PqH5z7etVK4VO/q/s u69Yw== 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=fm1; bh=twKUcL32C5+fp9zSA6He1Nik34Qln7YZbsSaOWYH2 Tc=; b=OArvCv2R9L6JDRf4PKTy4oPkzTh3xm5AFhS5k9fGRSO65gjbZcypjwDTA W4rSYq+xviCE/giYcMHmdmDsYqeXu8iqAY7LW70uoqQzW2X4lJ7vhTXNVJucg8gH b5QiTjqiRRt3YJvJBYk7WYMYIYEtpKFkjLvpSmdt4BLYBIs0G8Nuqy29rTMNrBF/ Q+1hISSKpaXyeZ+F54wyY6ME5dM38Y/OJK1pkQxaFvdZXBa8+yvKHlUYUgyX3lKq SB+ClIKUS+5e6E0pJFbyJhYHL91sBL5TBmL0E+Fd0r4qHo6LiqgXB2a5htNHCNgX xObBpD5KIdSgUtsIX+2Ou+IkoYotQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrledtgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedr vdehudenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id AE6B18005A; Thu, 24 Oct 2019 00:33:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Re: Making QUIC less constraining for innovation From: Mark Nottingham In-Reply-To: Date: Thu, 24 Oct 2019 15:33:16 +1100 Cc: quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3594.4.19) 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, 24 Oct 2019 04:33:25 -0000 Personally - ISTM that the biggest problem here is the tendency for people to choose = the "next" value available when starting to prototype; since it's a = linear space, that greatly increases the chances of collisions. That implies that reducing the friction of registration should be a = primary goal. I think Martin's proposal gets a fair way towards that. Another way of reducing friction is to require less of registrants, and = to use tools familiar to them. With my Expert hat on, I've been = experimenting with using Github repositories to manage registries; e.g., = see . Doing something like = this might be worth considering (and I'm working with IANA to make it = easier). Cheers, > On 24 Oct 2019, at 2:26 pm, Martin Thomson wrote: >=20 > Issue 3020 (https://github.com/quicwg/base-drafts/issues/3020) raises = the question of IANA registration policies in the core drafts. The = thesis is that the constraints on registrations pushes people into a = small space of available numbers (in that specific case the space is 256 = values) or has registration requirements that are too onerous. >=20 > We aim to address this in most places in QUIC and h3 with varints, = which all have a similar registration scheme. I think that David's = intent with #3020 was to push more of our code to use varints. But = we're nothing if not consistent when it comes to these things and after = lengthy discussion in Cupertino the group decided not to use varints for = transport parameters. >=20 > Instead, we want to revise the registration policies to better allow = implementations to experiment with new features (which is what I think = David intended by the use of the word "innovation"). For varints, we = divide the space into three partitions: >=20 > 0-63 =3D Standards Action > 64-16383 =3D Specification Required > 16384+ =3D Private Use >=20 > David's PR #3109 (https://github.com/quicwg/base-drafts/pull/3109) = proposes the same split for transport parameters. That greatly = increases the size of the Private Use space. The Private Use section is = still a lot smaller than with varints, but the cut points are the same = and the belief is that ~2^16 values is plenty of room to play with. >=20 > The main problem with all of these policies is described in RFC 6648, = namely that a codepoint from Private Use space can get wide adoption. = RFC 6648 basically concludes that these can be impossible to move to a = registered portion of the codepoint space. Furthermore, RFC 8126 says = that IANA doesn't register these codepoints and so no mechanism exists = to prevent collisions. That's a shame, because that's what registries = are for. >=20 > --- > I propose that we instead remove Private Use space from specifications = and instead adopt a Specification Required policy for all codepoints = except the first 64 values of a varint value (we can keep that as = Standards Action). >=20 > To allow for experimentation and proprietary extensions, add the = ability to provisionally register any codepoint. Provisional = registrations are registrations can omit values that would be required = for a permanent registration, include an expiry date, and operate on = First-Come, First-Served basis. =20 >=20 > This is intentionally lightweight so that anyone can initiate = registration, even without complete information. A Designated Expert = will be assigned to ensure that the registries don't end up crammed with = junk and to discourage use of codepoints with small encodings, large = blocks of codepoints, or codepoints that are likely to be used by future = standardization (those that are adjacent the first contiguous block of = allocated values, which we might want to use later). I emphasize = discourage intentionally, because this can't be a hard rule - this is = why we use a human for this job and not a machine. >=20 > To recognize that people will inevitably use values before they even = provisionally register them, we should encourage people to select from = the space at random. Random selection from a larger space greatly = reduces the chances of collision. For varints, people will be = encouraged to choose values that have the longest encoding tolerable for = their use case. In particular, extensions that are fully proprietary = will be encouraged to use values that encode to 4 or 8 bytes. I = recognize that this might not avoid people having inflated notions of = the value of their extension. And maybe it's not worth protecting the 2 = byte space on the basis that we might never run out of the 16320 values = available. Either way, I think that it's worth providing some text to = help the expert in case this protocol gets unexpectedly busy. >=20 > Registrants are specify the codepoint they want when registering, = rather than have IANA make an allocation on request. For standards that = want to use codepoints that are adjacent the first set of values, we = might still use TBD in specifications to avoid having the same value = specified in multiple specifications. The TLS working group had the = same codepoint in three different drafts last year, which wasn't great. >=20 > Provisional registrations can be removed or refreshed after a year = (period negotiable) after consultation with the expert, who is = encouraged to consult with the broader community. Experts would be = advised to refresh registrations unless there is evidence that the value = is no longer in use and there is a need to free up space for new = registrations. >=20 > The motivation behind this proposal is to recognize that the = overriding goal of a protocol registry is to avoid the interoperability = failures that arise from codepoint collisions. In particular, = registries are not an access control mechanism. >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Oct 23 22:21:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73B412000F for ; Wed, 23 Oct 2019 22:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=LLIz0T8l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qwyvNZ0F Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOsn-g-8QBwx for ; Wed, 23 Oct 2019 22:21:30 -0700 (PDT) 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 9D5D3120220 for ; Wed, 23 Oct 2019 22:21:30 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D70CA452; Thu, 24 Oct 2019 01:21:29 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 24 Oct 2019 01:21:30 -0400 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 :cc:subject:content-type; s=fm3; bh=ey6U9ioENhspYUYOq5S91kdfBaGm msjxThn7umXPQlU=; b=LLIz0T8ly5E8Zayu/uO5G8xhrBPBlcfNtiVJyST2t/nh cTuPVlhAHrl2/PjVOFWbLSyyyoZtg0UUvudmd6LNM9hXOJPIJQOnhoTygJ+XjvWL VeajL5N9y1HS7KH2zggxqUx3aqkUyPGgORyXIH6utIRzwSRdMxTKtwzDhJiAMuEQ JAatHbL/iQHca73m8HEegajSeJgXGe3J580pUM0bge+AVA9p94ZreALSfmDbRpJm /lEaf+EWuoMB/1K/Futg4t5o1KsCkolJqFKAEDDxhGiB+W33xNDvJNW4JBvacKQQ 49MkhFSq+ImUQButB/YdJ9/8ouYWs09UhFu6nX0R/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=ey6U9i oENhspYUYOq5S91kdfBaGmmsjxThn7umXPQlU=; b=qwyvNZ0FfBaKMBrzkIq5Jg ENHh7OB2offdn3hHxo93ZDsPCHNILpOCSv8v57z/Wj+JDZPPSjIgRTu4s6+urCbU t+cokGn+rhZHQEQjNB94pl5F1sYQqhvMrGHgzx5TUUt5H1UITZGSgXVnI2SZWgbJ joJ7enO6dKBoS1plMAe8HwdNMXKODu4piPIeuyUUuqxguWYTyikuMEYpRh6QIIT0 X2uaz1F4GAu3hc+9MOk4MRCGFlkXLnSZ2JTr9ilbbUFGxHpJY5VxufDg0d1vYVLY 2m1zmmtIDKGv7oJQyVo7lLyqTLB3MuNWs0Kjldtgn5hB8/RTGi1lDpN2iKhzjrng == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrledtgdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucffoh hmrghinhepghhithhhuhgsrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmthes lhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 02FE4E00A3; Thu, 24 Oct 2019 01:21:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 24 Oct 2019 16:21:08 +1100 From: "Martin Thomson" To: "Mark Nottingham" Cc: quic@ietf.org Subject: Re: Making QUIC less constraining for innovation 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: Thu, 24 Oct 2019 05:21:32 -0000 On Thu, Oct 24, 2019, at 15:33, Mark Nottingham wrote: > Another way of reducing friction is to require less of registrants, and > to use tools familiar to them. With my Expert hat on, I've been > experimenting with using Github repositories to manage registries; > e.g., see . Doing something > like this might be worth considering (and I'm working with IANA to make > it easier). Do you think that that process is mature enough to have QUIC use it? If it is, then I would be supportive of lowering the embarkation ramp further. From nobody Wed Oct 23 22:41:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DD612020A for ; Wed, 23 Oct 2019 22:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=sWQLUTNZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yck+pwQG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VM8SIeV2vWY for ; Wed, 23 Oct 2019 22:40:58 -0700 (PDT) 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 3304212000F for ; Wed, 23 Oct 2019 22:40:58 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8170E20319; Thu, 24 Oct 2019 01:40:57 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 24 Oct 2019 01:40:57 -0400 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=N UwdTfnm1H7JOcCEj82rT7wG1eEBowEJqCfiBMILnNA=; b=sWQLUTNZ3Dji2XJyN Tc3pXDv5QaeL1qsh+wbAovvgBYZTPeVPpLD0q6vumc8tVzQtYAEIeUg4NYEV8nmt W7HzQTIZ+EAlKd5Wkm1+mDKJax1OS5ThAPjEtbQeHXqATlhfvsXnBbt5RHZeeaig zxizrv3rXjjhP87p1oRpE3Q8sqrBbbbSjlA9OoL33xbvdEamaJopfF9/RKXp75Rj SrwIBCFMgaCeOil2FHZ+rO7gtzDRnAauMI4gZ5AFUU1pFAMnFNFdj2T7/nqTYoHR 7Y9/9r9yPc2bfEr3pmTdLDRYoEK9uPbj3Hony5B3WwtNuqWdO0hsNRjD0f8jaB6y 5qUBA== 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=fm1; bh=NUwdTfnm1H7JOcCEj82rT7wG1eEBowEJqCfiBMILn NA=; b=yck+pwQG3wWuCbREMZMv60eG0NQBJbWs4xNNmc6R3jORBGX71sv/Eoqqe sB2IBA/pmoxpEAok0r5YTnTVvTZ54xKphAnybHAl54R2r4KFZqO5vMKPaf3bUCRY p+B7zjSSMtP6GI3qp7oxe49w3VH60p8gWtfVEVZDkVgiVOr9uFBQQJcZQMNZqZPh w8NNacKWkmXJ890Iys/06mMYBQXKHCNqf3EFpAE6XoaEC2ISGpSIpHYIlO6aDDWL LtQY57dcL1u4gHJQO2yF8lsDpt0ozl/L2SZh4gumRzaPxj4ix7hJeb3x89xGalwc qg2v+oJpyavxcwi83Z1dGNcVXKzdQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrledtgdeliecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedr vdehudenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id E098DD60057; Thu, 24 Oct 2019 01:40:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Re: Making QUIC less constraining for innovation From: Mark Nottingham In-Reply-To: Date: Thu, 24 Oct 2019 16:40:52 +1100 Cc: quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3594.4.19) 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, 24 Oct 2019 05:41:00 -0000 On 24 Oct 2019, at 4:21 pm, Martin Thomson wrote: >=20 > On Thu, Oct 24, 2019, at 15:33, Mark Nottingham wrote: >> Another way of reducing friction is to require less of registrants, = and=20 >> to use tools familiar to them. With my Expert hat on, I've been=20 >> experimenting with using Github repositories to manage registries;=20 >> e.g., see . Doing = something=20 >> like this might be worth considering (and I'm working with IANA to = make=20 >> it easier). >=20 > Do you think that that process is mature enough to have QUIC use it? = If it is, then I would be supportive of lowering the embarkation ramp = further. It's not a process so much as an alternate path (to using a mailing = list). I think it's worth considering -- but the nice part is that you = don't have to specify anything, just leave it up to the experts. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Oct 23 23:25:21 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD199120178 for ; Wed, 23 Oct 2019 23:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBtbEVQx-Xk7 for ; Wed, 23 Oct 2019 23:25:19 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9886D12000F for ; Wed, 23 Oct 2019 23:25:18 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id l21so23680040lje.4 for ; Wed, 23 Oct 2019 23:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NfDmQOjaV2r0IRdBXAdXo9i2GwuVq0AsfbM/wcnW8LU=; b=ufElsWQ/QLkgqGiFGS0YpfPQkRHTK/W7+DMfeUbI+iFsX6l9dCNj1ruEbXxuKkxhEO vWrtrGNfv/XPVv5B4KlZwxM863kZY1rW9GkgXiFfPmAxieD/L35vsds2ZNI0Aqzs+4Fk 6rJuXyDOxs7QwQOiHSbHgPI+tc9ueyBCnDY/gWtV6vLA1ao48ifaP3Jr96TfBl0MfWrF QlFxTBNpW1DQ0TILMQxDC4UOWfcnxQ84n/ySz5RWJLxOoNK4SVt7AkURa88qHIxKe9FI DpOrunqg1LTjtOSWDOX/xKFB++ocvKjE2bkQR3YbD1zuHU6E2FqqYAVbytj+XE478DUV Hb2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NfDmQOjaV2r0IRdBXAdXo9i2GwuVq0AsfbM/wcnW8LU=; b=ogg2Y1zVwsCMyjqTdF0blZlW5oDjoZ5b0lWWs4vmAHBBVFbNkOAGG0hcm+zYCdmOWG 4CCqzgIuXlXvvyKBOOS30A1t8PXR4KPeTMXdPQ4FikKDIRwjMjmNpqMSYWiYpfAh2css zwU6+2Dy+9GcWyiOXJwS9B0n7yDwgruTMgc1Kkl4CjntrklBqTxvhmlMKtWY8YksONkG CNVsG4iCMtAvaoGRRCsnpH5F38whoysW+nqXwHGxucvsI9ObE4/yCbctZPzHnh7e0JmW F2Y5hVWHutW3bHnc1TVmI3wTFSRva0C0ikG70rHWWJm1uZYSecjqH63eqj2/KwnWcF7a A6ow== X-Gm-Message-State: APjAAAXH2kK00iwr+jOmFOo6CPU+CpFsQzJWSTLMhgRmxYIOghe1gBZe 2WUZq9aTER1UHtQeWN8qvkkNY+NoiLLaGstl/ss= X-Google-Smtp-Source: APXvYqyWpnXlxyxlROxn2TfX8ED1pWOOFzDDaf+TbU3ry+wMH7DfqHFWZEHYGLunzrUrAhMdF82xk3lWf7CmrggJL5U= X-Received: by 2002:a2e:a166:: with SMTP id u6mr24936825ljl.209.1571898316529; Wed, 23 Oct 2019 23:25:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Thu, 24 Oct 2019 15:25:05 +0900 Message-ID: Subject: Re: Making QUIC less constraining for innovation To: Mark Nottingham Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="000000000000c7a3030595a21848" 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, 24 Oct 2019 06:25:21 -0000 --000000000000c7a3030595a21848 Content-Type: text/plain; charset="UTF-8" Martin, I'm not familiar with the RFCs and the policies here, so it took me a little while of thinking to understand your proposal. Now that I do, I like it. That said, there's one thing I'd change. According to RFC 8126, Standards Action is limited to Standards-track RFCs and BCPs, and I'd like to see Experimental included in this space as well. I think RFC Required is what I'd prefer. - jana On Thu, Oct 24, 2019 at 2:41 PM Mark Nottingham wrote: > On 24 Oct 2019, at 4:21 pm, Martin Thomson wrote: > > > > On Thu, Oct 24, 2019, at 15:33, Mark Nottingham wrote: > >> Another way of reducing friction is to require less of registrants, and > >> to use tools familiar to them. With my Expert hat on, I've been > >> experimenting with using Github repositories to manage registries; > >> e.g., see . Doing > something > >> like this might be worth considering (and I'm working with IANA to make > >> it easier). > > > > Do you think that that process is mature enough to have QUIC use it? If > it is, then I would be supportive of lowering the embarkation ramp further. > > It's not a process so much as an alternate path (to using a mailing list). > I think it's worth considering -- but the nice part is that you don't have > to specify anything, just leave it up to the experts. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > --000000000000c7a3030595a21848 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Martin,

I'm not familiar with the R= FCs and the policies here, so it took me a little while of thinking to unde= rstand your proposal. Now that I do, I like it.

Th= at said, there's one thing I'd change. According to RFC 8126, Stand= ards Action is limited to Standards-track RFCs and BCPs, and I'd like t= o see Experimental included in this space as well. I think RFC Required is = what I'd prefer.

- jana
=
On Thu= , Oct 24, 2019 at 2:41 PM Mark Nottingham <mnot@mnot.net> wrote:
On 24 Oct 2019, at 4:21 pm, Martin Thomson <mt@lowentropy.net> wrote= :
>
> On Thu, Oct 24, 2019, at 15:33, Mark Nottingham wrote:
>> Another way of reducing friction is to require less of registrants= , and
>> to use tools familiar to them. With my Expert hat on, I've bee= n
>> experimenting with using Github repositories to manage registries;=
>> e.g., see <https://github.com/link-relations/r= egistry>. Doing something
>> like this might be worth considering (and I'm working with IAN= A to make
>> it easier).
>
> Do you think that that process is mature enough to have QUIC use it?= =C2=A0 If it is, then I would be supportive of lowering the embarkation ram= p further.

It's not a process so much as an alternate path (to using a mailing lis= t). I think it's worth considering -- but the nice part is that you don= 't have to specify anything, just leave it up to the experts.

Cheers,

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

--000000000000c7a3030595a21848-- From nobody Thu Oct 24 05:54:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A47612010E for ; Thu, 24 Oct 2019 05:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 JCj8ZteQoiDg for ; Thu, 24 Oct 2019 05:54:35 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 BE523120105 for ; Thu, 24 Oct 2019 05:54:35 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9OCqnAp001692; Thu, 24 Oct 2019 13:54:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=laZ0JM1+4oCatek7gFroVg0GKMcbgkfsSqhwVxsJZ5Y=; b=WEgpbc+42ipbTmIwbmIXl460uQXAh4VKJCxYin1eejLUfcn7cGgW3/jejA6W8T0BCXSV pOU+SIsowoAsZc5XrU6CzVjJjhgbdy0bRp5E35Msr0KRi8U/iFUkzRegakEh5TeVuFWH mE822n102v1qHH1+oHypvJuKeseSO4P+WiQNGZ8ff+OMSQ2t3Nz38Z8wvoTc+sTLUxaf i7EwOsylqYF366Y83SR06GAPljcdLEz8TGZr0WbK2Yy6W1b7tlB1crKZzh1EcELTn0DZ O5TPOGycXY6aWnH6AD4D21ZtLDekaPzxFxOBzUelnXJqDIWoPYx0CNToBOVenQbg76/J SQ== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2vsyugj9hy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 Oct 2019 13:54:32 +0100 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 x9OCl836000683; Thu, 24 Oct 2019 08:54:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint8.akamai.com with ESMTP id 2vqwtxbhcc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 24 Oct 2019 08:54:30 -0400 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, 24 Oct 2019 08:54:28 -0400 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, 24 Oct 2019 08:54:28 -0400 From: "Salz, Rich" To: Martin Thomson , "quic@ietf.org" Subject: Re: Making QUIC less constraining for innovation Thread-Topic: Making QUIC less constraining for innovation Thread-Index: AQHVihr0wKOBWmevhU2YcAoLtno5GKdpwCEA Date: Thu, 24 Oct 2019 12:54:27 +0000 Message-ID: <536FE05C-0F89-4468-8C37-F66C320430A6@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.29] Content-Type: text/plain; charset="utf-8" Content-ID: <73553AEBE717FF43890B612941D35BD6@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-24_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=455 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910240123 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-24_08:2019-10-23,2019-10-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 clxscore=1011 priorityscore=1501 malwarescore=0 mlxscore=0 bulkscore=0 mlxlogscore=446 adultscore=0 suspectscore=0 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910240124 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, 24 Oct 2019 12:54:38 -0000 DQo+ICAgICBJIHByb3Bvc2UgdGhhdCB3ZSBpbnN0ZWFkIHJlbW92ZSBQcml2YXRlIFVzZSBzcGFj ZSBmcm9tIHNwZWNpZmljYXRpb25zIGFuZCBpbnN0ZWFkIGFkb3B0IGEgU3BlY2lmaWNhdGlvbiBS ZXF1aXJlZCBwb2xpY3kgZm9yIGFsbCBjb2RlcG9pbnRzIGV4Y2VwdCB0aGUgZmlyc3QgNjQgdmFs dWVzIG9mIGEgdmFyaW50IHZhbHVlICh3ZSBjYW4ga2VlcCB0aGF0IGFzIFN0YW5kYXJkcyBBY3Rp b24pLg0KICAgDQpJIGxpa2UgdGhpcyBpZGVhLg0KDQo= From nobody Thu Oct 24 09:11:00 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7D120965; Thu, 24 Oct 2019 09:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 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, UNPARSEABLE_RELAY=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 cRfzqf2GIZnG; Thu, 24 Oct 2019 09:10:55 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D90120979; Thu, 24 Oct 2019 09:10:55 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 46zXKT64zXz10GR; Thu, 24 Oct 2019 18:10:53 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 46zXKT51sgzDq7l; Thu, 24 Oct 2019 18:10:53 +0200 (CEST) Received: from OPEXCAUBM44.corporate.adroot.infra.ftgroup ([fe80::e8a4:8bb:d7c2:f4e2]) by OPEXCAUBM5C.corporate.adroot.infra.ftgroup ([fe80::393d:418c:3f1d:991d%21]) with mapi id 14.03.0468.000; Thu, 24 Oct 2019 18:10:53 +0200 From: To: "Gorry Fairhurst (gorry@erg.abdn.ac.uk)" , tsvwg-chairs , "Black, David" CC: "saag@ietf.org" , "opsawg@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , "quic@ietf.org" , "tsvwg@ietf.org" , "etosat@ietf.org" Subject: RE: TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019 Thread-Topic: TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019 Thread-Index: AdV+HJIZhebOrRcXTIK6bGArgFWweQEbzmAgAfqMkPA= Date: Thu, 24 Oct 2019 16:10:53 +0000 Message-ID: <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup> References: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0OPEXCAUBM44corp_" MIME-Version: 1.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, 24 Oct 2019 16:10:58 -0000 --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0OPEXCAUBM44corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, My view on the draft is that a section is missing. I suggest adding a section 7 named "end-to-end interdomain OAM" to bridge i= OAM and OAM of end-to-end encrypted flows. The content of the section might= relies on the following: Fast interdomain troubleshooting requires a minimal interoperability to est= imate delay and packet loss. QUIC spinbit approach is an example which supports end-to-end interdomain O= AM. The signal exposed is end-to-end protected and not encrypted; its enfor= cement is under the control of the endpoint; its activation is limited to a= small percentage of the flows. Here are other comments on the draft. I read the draft very quickly so seve= ral ones might be inappropriate: =B7 Encryption and protection should be clearly separated; o TCPcrypt header protection (part end-to-end encrypted, part end-to-end= protected and on-path readable) mechanism ; o QUIC spinbit protection (end-to-end protected and on-path readable); =B7 QUIC spinbit on-path troubleshooting properties : applies to in= terdomain; =B7 DTLS on-path troubleshooting properties might be described; =B7 Not sure that the draft recall transport proxies usage, like fo= r satco; =B7 Security section should highlight the privacy risk when on-path= probes have to do whole packet decryption to get header information ; Regards Emile De : saag [mailto:saag-bounces@ietf.org] De la part de Black, David Envoy=E9 : mardi 8 octobre 2019 23:09 =C0 : saag@ietf.org; opsawg@ietf.org Cc : tsvwg-chairs Objet : [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23= October 2019 FYI - some OPS area and SEC area eyes on this TSVWG draft now (during WGLC)= would be a good thing ;-). Thanks, --David (TSVWG co-chair) From: Black, David Sent: Tuesday, October 8, 2019 5:06 PM To: tsvwg@ietf.org Cc: Black, David Subject: WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019 This email announces a TSVWG Working Group Last Call (WGLC) on: The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet draft-ietf-tsvwg-transport-encrypt-08 https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ This draft is intended to become an Informational RFC. This WGLC will run through the end of the day on Wednesday, October 23. That should allow time before the Singapore draft submission cutoff for the authors to revise the draft with any changes that result from WGLC. Comments should be sent to the tsvwg@ietf.org list, = although purely editorial comments may be sent directly to the authors. Please cc: the WG chairs at tsvwg-chairs@ietf.org if you wo= uld like the chairs to track such editorial comments as part of the WGLC process. No IPR disclosures have been submitted directly on this draft. Thanks, David, Gorry and Wes (TSVWG Co-Chairs) ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0OPEXCAUBM44corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

My view on the= draft is that a section is missing.

 

I suggest addi= ng a section 7 named “end-to-end interdomain OAM” to bridge iOA= M and OAM of end-to-end encrypted flows. The content of the section might relies on the following:

 

Fast interdomain troubleshooting requires a minimal interope= rability to estimate delay and packet loss.

QUIC spinbit approach is an example which supports end-to-en= d interdomain OAM. The signal exposed is end-to-end protected and not encrypted; its enforcement is under the control of the endpoint; its activation is limited to a = small percentage of the flows.

 

Here are other comments on the draft. I read the draft very quickly = so several ones might be inappropriate<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Arial"= ,"sans-serif";color:black">:

=B7    &n= bsp;    Encryp= tion and protection should be clearly separated;  

o=     TCPcrypt header protection (part end-to-end encrypted, part end-to-end protected and on-path readable= ) mechanism ;

o=     QUIC s= pinbit protection (end-to-end protected and on-path readable= );

=B7    &n= bsp;    QUIC s= pinbit on-path troubleshooting properties : applies to interdomain;

=B7    &n= bsp;    DTLS o= n-path troubleshooting properties might be described;

=B7    &n= bsp;    Not su= re that the draft recall trans= port proxies usage, like for satco;

=B7    &n= bsp;    Securi= ty section should highlight the privacy risk when on-path probes have= to do whole packet decryption to get header information ;

 

Regards=

Emile

 

 

De : saag= [mailto:saag-bounces@ietf.org] De la part de Black, David
Envoy=E9 : mardi 8 octobre 2019 23:09
=C0 : saag@ietf.org; opsawg@ietf.org
Cc : tsvwg-chairs
Objet : [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-0= 8, closes 23 October 2019

 

FYI = 211; some OPS area and SEC area eyes on this TSVWG draft now (during WGLC) = would be a good thing ;-).

&n= bsp;

Thanks,= --David (TSVWG co-chair)

&n= bsp;

From: Black, David <david.black@emc.com>
Sent: Tuesday, October 8, 2019 5:06 PM
To: tsvwg@ietf.org
Cc: Black, David
Subject: WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 Octo= ber 2019

 

This email announces a TSVWG= Working Group Last Call (WGLC) on:

 

The Impact of Transport Head= er Confidentiality on Network Operation and

    &nbs= p;            &= nbsp;     Evolution of the Internet

    &nbs= p;            draft-= ietf-tsvwg-transport-encrypt-08

https://datatracker.ie= tf.org/doc/draft-ietf-tsvwg-transport-encrypt/

 

This draft is intended to be= come an Informational RFC.

 

This WGLC will run through t= he end of the day on Wednesday, October 23.

That should allow time befor= e the Singapore draft submission cutoff for

the authors to revise the dr= aft with any changes that result from WGLC.

 

Comments should be sent to t= he tsvwg@ietf.org list, although purely

editorial comments may be se= nt directly to the authors. Please cc: the

WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs to<= /span>

track such editorial comment= s as part of the WGLC process.

 

No IPR disclosures have been= submitted directly on this draft.

 

Thanks,

David, Gorry and Wes

(TSVWG Co-Chairs)=

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0OPEXCAUBM44corp_-- From nobody Thu Oct 24 12:01:00 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73059120838 for ; Thu, 24 Oct 2019 12:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT5TKDSEYdpf for ; Thu, 24 Oct 2019 12:00:42 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 03624120859 for ; Thu, 24 Oct 2019 12:00:42 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id c11so21723286iom.10 for ; Thu, 24 Oct 2019 12:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LWDslHKALiHEIFPEyi+us6px5aLSYGirHINYFdq4+D0=; b=eCMhXnCekcT394gdDeC7TvLo5lnhErj37NFERoWimPiOIJ9Gw7+yEtm/YPZEnjptPg 5Cw+IF2fZl+fBlbP7Vh/4bh7pJuP7lKhoxf9j+9AKXr9ZgtMg61ibVYk5Q+MBqzjAEzJ i6sNTDvoJ0Us2EZulgW7tOoQ4Wv3wShxgnPOjG0qFAcxsgpAHwyWaFm2rYRjZe9fGYjB bND1wSg6ZdWvL2vB7691Kc9X0e+AoYhVCt7AwQT+tq47gEZ2pXRZW59Ajz7tGAo11lfs g8apQK4JloU6S1x6lnYP35DLr1eVVGTtohXGIukKS9RImLBsCj5E9PLuqcIHA4I4WSrw p0Yg== 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=LWDslHKALiHEIFPEyi+us6px5aLSYGirHINYFdq4+D0=; b=j5u41vhGlQeXpavog0uPWVCvwjUH7ZvUK94UL0SOueiaxLtyUN9CVjyfb/Nf6S8Ax6 eXn8/xuGoehBEfE+APkEM7mUEHzANw3EZKpZShuhsqwkNcwoc9XHwd1SrsPl8XHix1RH iRyWS68ua7ugkHDRCdQKedBX4uDKT7zFHKqX9ldPINwmLw1SzLjeofGVrc3r9RywUM0S +mbzkyB9chAW7TUxRQLrwL6qT/oY2Hh1mNUobxuSkiidga+nM+L4nAQJF872oFNyJWfO 5xXhgoHZtyc9z6o0cVCOUmJk2V9KpG7WLmM+/DhLDHhuVwkkYqobLTTsjb/w5z/n6zz5 IA0w== X-Gm-Message-State: APjAAAXnS7KWL23b+6fHXgUYQYIQAdaA3sNincdTVKpViqiWnYGES9cr ykn8PvVWiNXASa9q0om4WA4RhqleumtShuEIp5g= X-Google-Smtp-Source: APXvYqwtRqAtomf5yxyzFcejQyuRKr1um64NU/yzTkwypxjxnRk2iO04wTBQ7Kt9RewV7Hd09bopdf2v9Ni7GuiUJtU= X-Received: by 2002:a02:c78d:: with SMTP id n13mr15787411jao.11.1571943640884; Thu, 24 Oct 2019 12:00:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Thu, 24 Oct 2019 12:00:14 -0700 Message-ID: Subject: Re: Making QUIC less constraining for innovation To: Jana Iyengar Cc: Mark Nottingham , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000526b590595aca6a8" 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, 24 Oct 2019 19:00:59 -0000 --000000000000526b590595aca6a8 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 23, 2019 at 11:25 PM Jana Iyengar wrote: > Martin, > > I'm not familiar with the RFCs and the policies here, so it took me a > little while of thinking to understand your proposal. Now that I do, I like > it. > > That said, there's one thing I'd change. According to RFC 8126, Standards > Action is limited to Standards-track RFCs and BCPs, and I'd like to see > Experimental included in this space as well. I think RFC Required is what > I'd prefer. > > I think that if you want to include experimental RFCs you'd also want to increase the size of the reserved pool some small amount. I'm also not sure it's a great idea over all. Specification required covers experimental RFCs and distinguishing between those experiments and other specified experiments seems to expect that different range will get different treatment by networks/middleboxes/etc. If the main goal of this is to reconfirm "In particular, registries are not an access control mechanism.", a secondary goal should probably be "Placement in the range is not a useful signal". We want to avoid collision, so we need a code point mapping to a spec--but we don't want people inferring much from where the code point lies. To me, the only point of a standards action reserved space is to make sure that the IETF always has some unconficted area to deploy into; it's otherwise no guarantee at all. If we think the space is large enough to avoid a risk there, I'd say make it all specification required and leave it at that. Two cents as an individual, Ted > - jana > > On Thu, Oct 24, 2019 at 2:41 PM Mark Nottingham wrote: > >> On 24 Oct 2019, at 4:21 pm, Martin Thomson wrote: >> > >> > On Thu, Oct 24, 2019, at 15:33, Mark Nottingham wrote: >> >> Another way of reducing friction is to require less of registrants, >> and >> >> to use tools familiar to them. With my Expert hat on, I've been >> >> experimenting with using Github repositories to manage registries; >> >> e.g., see . Doing >> something >> >> like this might be worth considering (and I'm working with IANA to >> make >> >> it easier). >> > >> > Do you think that that process is mature enough to have QUIC use it? >> If it is, then I would be supportive of lowering the embarkation ramp >> further. >> >> It's not a process so much as an alternate path (to using a mailing >> list). I think it's worth considering -- but the nice part is that you >> don't have to specify anything, just leave it up to the experts. >> >> Cheers, >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> --000000000000526b590595aca6a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 23, 2019 at 11:25 PM Jana Iye= ngar <jri.ietf@gmail.com> w= rote:
Martin,

I'm not fa= miliar with the RFCs and the policies here, so it took me a little while of= thinking to understand your proposal. Now that I do, I like it.
=
That said, there's one thing I'd change. According t= o RFC 8126, Standards Action is limited to Standards-track RFCs and BCPs, a= nd I'd like to see Experimental included in this space as well. I think= RFC Required is what I'd prefer.


I think that if you want to include experimental RFCs= you'd also want to increase the size of the reserved pool some small a= mount.=C2=A0

I'm also not sure it's a= great idea over all.=C2=A0 Specification required covers experimental RFCs= and distinguishing between those experiments and other specified experimen= ts seems to expect that different range will get different treatment by net= works/middleboxes/etc.=C2=A0 If the main goal of this is to reconfirm "= ;In particular, registries are not an access control mechanism.", a se= condary goal should probably be "Placement in the range is not a usefu= l signal".=C2=A0 We want to avoid collision, so we need a code point m= apping to a spec--but we don't want people inferring much from where th= e code point lies.=C2=A0 To me, the only point of a standards action reserv= ed space is to make sure that the IETF always has some unconficted area to = deploy into; it's otherwise no guarantee at all. If we think the space = is large enough to avoid a risk there, I'd say make it all specificatio= n required and leave it at that.

Two cents as an i= ndividual,

Ted

=C2=A0=
- jana

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 24, 2019 at 2:41 PM Mark N= ottingham <mnot@mnot.= net> wrote:
On 24 Oct 2019, at 4:21 pm, Martin Thomson <mt@lowentropy.net> wrote:
>
> On Thu, Oct 24, 2019, at 15:33, Mark Nottingham wrote:
>> Another way of reducing friction is to require less of registrants= , and
>> to use tools familiar to them. With my Expert hat on, I've bee= n
>> experimenting with using Github repositories to manage registries;=
>> e.g., see <https://github.com/link-relations/r= egistry>. Doing something
>> like this might be worth considering (and I'm working with IAN= A to make
>> it easier).
>
> Do you think that that process is mature enough to have QUIC use it?= =C2=A0 If it is, then I would be supportive of lowering the embarkation ram= p further.

It's not a process so much as an alternate path (to using a mailing lis= t). I think it's worth considering -- but the nice part is that you don= 't have to specify anything, just leave it up to the experts.

Cheers,

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

--000000000000526b590595aca6a8-- From nobody Thu Oct 24 17:23:12 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D650B12001A for ; Thu, 24 Oct 2019 17:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=v7vcHwI+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=f+McXZAj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIlJzycLtSRz for ; Thu, 24 Oct 2019 17:23:09 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5459D120019 for ; Thu, 24 Oct 2019 17:23:09 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A405521650 for ; Thu, 24 Oct 2019 20:23:08 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 24 Oct 2019 20:23:08 -0400 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=fm3; bh=Psx9POlJque73OCBRTigHNiLLzN4ipV KKAV8B3hhFqE=; b=v7vcHwI+2742YEEK+z5KQMKOaaHRHnkt950+8Nl51Ux7h9Y pRZ8CZTBjJ6vIPqk8PTg84rvMN7b/ewIIO62bAGAbfJOLD/gKAAk4ILsjLHytpE/ lHKa5PtW/9EtG0JCXFP8CLt9te0wTlUcrquiZW8U422i8pQh+jn6TSI+QyMPR+8p MqZQ1ByzQh9EXJRs+srT9dQqdiy5QRz/I0PIRUAK75FvQZOwJJide5Em/92Vimiu fa5sqM6c/i9+/qYUQ7UJzoiPOifETU+EZdbSx8dbpcOnn4a1bsBXm0WRMHPm+izw BG+2VE4Wl/26oxFVLkZJffwDuKWIOZvuIJm3VZQ== 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=fm1; bh=Psx9PO lJque73OCBRTigHNiLLzN4ipVKKAV8B3hhFqE=; b=f+McXZAj1msqaZ7SfbuoYh k/UBBMpHDbv44iydqi2YAIHRZmNlBAR9I/z2UNkt5WbKhXYH3of2fnwMkO7eq8mL /E2VOPMEz+si8fDoQ8Y1bZAlugk+054M9ZhYKlyDU/lf71dA8JkUO68Uf3fVqI2I 3yc+Y1hhjuQ9eLZTBFXkYRskd4APAMxpLUyIoCqrSVUTCWleB44WkW9uPqFccZl+ EQzalMC4QSwNtaIJtZiYmmv+V9KVNme62pENHUkN1bFnUg2JQBLUXfBKq/4Swrki e0YbyXdFRLVReDsYpr8Gb+z8lKxt9/grGvOC1YxKThb6pzc2+RAknOpFhvBJbk4Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrledvgdefvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 56A20E00AB; Thu, 24 Oct 2019 20:23:08 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> In-Reply-To: References: Date: Fri, 25 Oct 2019 11:22:50 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Making QUIC less constraining for innovation 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: Fri, 25 Oct 2019 00:23:11 -0000 On Fri, Oct 25, 2019, at 06:00, Ted Hardie wrote: > On Wed, Oct 23, 2019 at 11:25 PM Jana Iyengar wrote: > > That said, there's one thing I'd change. According to RFC 8126, Standards Action is limited to Standards-track RFCs and BCPs, and I'd like to see Experimental included in this space as well. I think RFC Required is what I'd prefer. > > To me, the only > point of a standards action reserved space is to make sure that the > IETF always has some unconficted area to deploy into; it's otherwise no > guarantee at all. If we think the space is large enough to avoid a risk > there, I'd say make it all specification required and leave it at that. My thinking was along the same lines as Ted. As much of the space has the much lower bar of Specification Required, those experiments can use that space freely. The only experiments that wouldn't be permitted would be those that want one-byte codepoints (and provisional registrations would still be available, though discouraged). And yeah, I'd be OK if someone said that the whole space should be Specification Required. But I've seen 256-value spaces chewed up very fast in the past, and our 64-value space could be more appealing. From nobody Thu Oct 24 21:35:08 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619A01200E7 for ; Thu, 24 Oct 2019 21:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds8qiF4J_DUl for ; Thu, 24 Oct 2019 21:35:05 -0700 (PDT) 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 1847312003F for ; Thu, 24 Oct 2019 21:35:05 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id d1so1078830ljl.13 for ; Thu, 24 Oct 2019 21:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jtLIg72rDXNBR6faHz65LVASEMecT1gasoNo0ONAGNI=; b=rkgVt3fZaxt6/oJyGbAVz/SrWq0j0QtN4giEDszch+9HDt1/zx7trb2jX7ZfFcR1Py xqmCXWVNBLhvf4sO24wA2Rfk9haIZVqNTdbKNhJgtFqNiLWUmmPbtNZaDRg1uxsy76G4 DF960TB/+Qny7D5ZtJKkFdTOUcH2DKqDcXO4Ba2g67HxTCMurXc0YqU1dv0OL5rAmTBD hR5Ogmes7CY7inrJtrzl209IjfBkB9pDhWs5LT2wEuqy8uTEuR3KeofymPo2IrPKr6fP x8+A+kutTEMpmkrIiByaamP2YhNgRFvmD28Sh+FCw9bCCvb6ZixcYtoMbi2Bl8lr2iXJ IcnQ== 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=jtLIg72rDXNBR6faHz65LVASEMecT1gasoNo0ONAGNI=; b=EkzZ1iR7mxaUaD5X2+ZREzFX3vl1wTrVFJGXy7WwFmVBmpXsevpcK8kpBdY5L9wLVz Yn6mKaFPRBjTROJxKuAz/HVNYNzuuwKs5oOWGo5GV61a22tpKXqAw63zPYfbrjmOtr3Y YoAFlNYdFawU7EkungtVj/gCiZVcj9UKrWYihi2HVijz0j+nBuST2DBYWmk4Zq1YK/wU 5sEFBWsWNBvTYaL1kBGSHg3cRq503DH2zKhsTjcgciMrIxveXesdOGfDtJpkp/fjSfQ+ wSoWcUojRF4CkX7109KKNCCFvHAdQrkY5VFjrCq6xOogCpibHP0KLTcMVMuD9TjuOVy/ tvZw== X-Gm-Message-State: APjAAAWKV4KmhGI29Dadz2tt7rS7WzMD7JQ1QvUg1Kb5k22tfRtenEKa DetOfe6B/J/9PbvDmTv1BgBQqVym8ZpP/fKDkfjxgjmh X-Google-Smtp-Source: APXvYqycvG1/+oJzkBpUsCHQIzZMng3a0s2Wj2QkF+obrl4gcP0B0lYla3dnadVZ10Vfo/GnvjbxVu/qxs5/tx2kbpU= X-Received: by 2002:a2e:8084:: with SMTP id i4mr740020ljg.137.1571978103011; Thu, 24 Oct 2019 21:35:03 -0700 (PDT) MIME-Version: 1.0 References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> In-Reply-To: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> From: David Schinazi Date: Thu, 24 Oct 2019 21:34:51 -0700 Message-ID: Subject: Re: Making QUIC less constraining for innovation To: Martin Thomson Cc: QUIC Content-Type: multipart/alternative; boundary="0000000000006cc0ae0595b4ac1e" 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, 25 Oct 2019 04:35:07 -0000 --0000000000006cc0ae0595b4ac1e Content-Type: text/plain; charset="UTF-8" I think I'm mostly in agreement with Martin here. My intent with PR 3109 was to make the overhead for experimentation as low as possible. Based on the ideas in this thread, I'm thinking about perhaps tweaking it as follows: [0-63] Standards Action or IESG Approval This gives the IETF a little protected garden and that means that folks developing extensions and experiments won't use the next available value from here. [64-16383] Specification Required This creates a carveout with an intentional overhead of requiring writing a draft. This ensures that we'll never run out of this space. Experimental RFCs would use this registry. [16384+] First Come First Serve This allows anyone to request a code-point and register it without overhead, as IANA does not review the request. This means that we can use the registry simply as a collision-avoidance mechanism. We should strongly encourage customers of the [64+] registries to generate their desired codepoint randomly. I agree with removing Private Use for the reasons stated by others, but I do think that if someone wants to build a proprietary extension, they should be able to do so without having to document it publicly - because in reality people will be building undocumented proprietary extensions, so we can either give them a part of the registry that works for them, or they'll resort to squatting. And I think First Come First Serve will get us what we want here. I don't think Provisional Registrations fit the bill here because these proprietary extensions have no reason to be time-limited. David On Thu, Oct 24, 2019 at 5:23 PM Martin Thomson wrote: > > On Fri, Oct 25, 2019, at 06:00, Ted Hardie wrote: > > On Wed, Oct 23, 2019 at 11:25 PM Jana Iyengar > wrote: > > > That said, there's one thing I'd change. According to RFC 8126, > Standards Action is limited to Standards-track RFCs and BCPs, and I'd like > to see Experimental included in this space as well. I think RFC Required is > what I'd prefer. > > > > To me, the only > > point of a standards action reserved space is to make sure that the > > IETF always has some unconficted area to deploy into; it's otherwise no > > guarantee at all. If we think the space is large enough to avoid a risk > > there, I'd say make it all specification required and leave it at that. > > My thinking was along the same lines as Ted. As much of the space has the > much lower bar of Specification Required, those experiments can use that > space freely. The only experiments that wouldn't be permitted would be > those that want one-byte codepoints (and provisional registrations would > still be available, though discouraged). And yeah, I'd be OK if someone > said that the whole space should be Specification Required. But I've seen > 256-value spaces chewed up very fast in the past, and our 64-value space > could be more appealing. > > --0000000000006cc0ae0595b4ac1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think I'm mostly in agreement with Martin here.
=
My intent with PR 3109 was to make the overhead for experimentati= on as low as possible.
Based on the ideas in this thread, I'm= thinking about perhaps tweaking it as follows:

=C2=A0 =C2=A0 This gives the IETF a little prot= ected garden and that means that folks developing
=C2=A0 =C2=A0 e= xtensions and experiments won't use the next available value from here.=

=C2=A0 =C2=A0 Th= is creates a carveout with an intentional overhead of requiring writing a d= raft.
=C2=A0 =C2=A0 This ensures that we'll never run out of = this space. Experimental RFCs would
=C2=A0 =C2=A0 use this regist= ry.

=C2=A0 =C2=A0 T= his allows anyone to request a code-point and register it without overhead,=
=C2=A0 =C2=A0 as IANA does not review the request. This means th= at we can use the registry
=C2=A0 =C2=A0 simply as a collision-av= oidance mechanism.

We should strongly encoura= ge customers of the [64+] registries to generate
their desired co= depoint randomly.

I agree with removing Private Use for= the reasons stated by others, but I do think
that if someone wan= ts to build a proprietary extension, they should be able to
do so= without having to document it publicly - because in reality people will
be building undocumented proprietary extensions, so we can either g= ive them
a part of the registry that works for them, or they'= ll resort to squatting. And
I think First Come First Serve will get us what = we want here. I don't think
Provisional Registrations fit the bill here= because these proprietary extensions
have no reason to be time-l= imited.

David

On Thu, Oct 24, 2019 at 5:23 PM= Martin Thomson <mt@lowentropy.net<= /a>> wrote:
<= br> On Fri, Oct 25, 2019, at 06:00, Ted Hardie wrote:
> On Wed, Oct 23, 2019 at 11:25 PM Jana Iyengar <jri.ietf@gmail.com> wrote:
> > That said, there's one thing I'd change. According to RFC= 8126, Standards Action is limited to Standards-track RFCs and BCPs, and I&= #39;d like to see Experimental included in this space as well. I think RFC = Required is what I'd prefer.
>
> To me, the only
> point of a standards action reserved space is to make sure that the > IETF always has some unconficted area to deploy into; it's otherwi= se no
> guarantee at all. If we think the space is large enough to avoid a ris= k
> there, I'd say make it all specification required and leave it at = that.

My thinking was along the same lines as Ted.=C2=A0 As much of the space has= the much lower bar of Specification Required, those experiments can use th= at space freely.=C2=A0 The only experiments that wouldn't be permitted = would be those that want one-byte codepoints (and provisional registrations= would still be available, though discouraged).=C2=A0 And yeah, I'd be = OK if someone said that the whole space should be Specification Required.= =C2=A0 But I've seen 256-value spaces chewed up very fast in the past, = and our 64-value space could be more appealing.

--0000000000006cc0ae0595b4ac1e-- From nobody Thu Oct 24 23:38:59 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1BF1200F8 for ; Thu, 24 Oct 2019 23:38:57 -0700 (PDT) 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 xUI2e0pjS0aS for ; Thu, 24 Oct 2019 23:38:54 -0700 (PDT) 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 D8EEA1200F7 for ; Thu, 24 Oct 2019 23:38:53 -0700 (PDT) Received: from xse400.mail2web.com ([66.113.197.146] helo=xse.mail2web.com) by mx114.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iNtFL-000DKZ-Ni for quic@ietf.org; Fri, 25 Oct 2019 08:38:52 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 46zvZx3v7Vz4g3V for ; Thu, 24 Oct 2019 23:38:49 -0700 (PDT) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iNtFJ-0002uD-EA for quic@ietf.org; Thu, 24 Oct 2019 23:38:49 -0700 Received: (qmail 22480 invoked from network); 25 Oct 2019 06:32:09 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.43.199]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Oct 2019 06:32:08 -0000 Subject: Re: Making QUIC less constraining for innovation To: David Schinazi , Martin Thomson Cc: QUIC References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.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= Message-ID: Date: Thu, 24 Oct 2019 23:32:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B5132A6FA5D036233E910014" Content-Language: en-US X-Originating-IP: 66.113.197.146 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/gcnlw0QRKNbAP+Q7R/EWH3Kru/cipSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fteglptZWAExbt6ewZdk60cU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/d/hBjqsxautjlVXfyJaQKbyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8SnwqlUrBK2R/GBg9vCpMGFHw53FxnHnL50HZvyS1o3x98IkV0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm1iez9GB/vVI PBTzV+UYoQ4Bc7wE8nvxN4jxcWf/+0bYhC+eCyolhgCfLviKvzYmEiR/ISaldqzWGocHtEVp6OLv 5pWb82qAoDl3ILGSF0vmDvI0DEihOd7XzCAIcFZdY11677oPXF7r5zsW33ZNliqQWXiK63IBlEyx 50xFFL1+Pbw/1QCLpp89wymCao3AxtQ84QG89JN6MvpNdzLqW7oDDO68PcT0XKjXrRhmv2XnHHAS JNUmoOHSoqgqxfHmWRWcrRhLeB34s3hUb32GO+2hI6SQIS4arCxOi9TQDWuq08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine9.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, 25 Oct 2019 06:38:57 -0000 This is a multi-part message in MIME format. --------------B5132A6FA5D036233E910014 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 10/24/2019 9:34 PM, David Schinazi wrote: > [0-63] Standards Action > or IESG Approval > >     This gives the IETF a little protected garden and that means that > folks developing >     extensions and experiments won't use the next available value from > here. > > [64-16383] Specification Required > >     This creates a carveout with an intentional overhead of requiring > writing a draft. >     This ensures that we'll never run out of this space. Experimental > RFCs would >     use this registry. > > [16384+] First Come First Serve > >     This allows anyone to request a code-point and register it without > overhead, >     as IANA does not review the request. This means that we can use > the registry >     simply as a collision-avoidance mechanism. > > We should strongly encourage customers of the [64+] registries to generate > their desired codepoint randomly. > > I agree with removing Private Use > for the reasons > stated by others, but I do think > that if someone wants to build a proprietary extension, they should be > able to > do so without having to document it publicly - because in reality > people will > be building undocumented proprietary extensions, so we can either give > them > a part of the registry that works for them, or they'll resort to > squatting. And > I think First Come First Serve > will get us what we > want here. I don't think > Provisional Registrations > fit the bill here > because these proprietary extensions > have no reason to be time-limited. I think I like Martin's proposal better. My reasoning is that there is no practical difference between the numbers as long as TP are encoded on 16 bits, and I have a hard time believing that any IANA registry could efficiently manage more than a few thousand code points. Plus specification required is really nice for the community. -- Christian Huitema --------------B5132A6FA5D036233E910014 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 10/24/2019 9:34 PM, David Schinazi wrote:
    This gives the IETF a little protected garden and that means that folks developing
    extensions and experiments won't use the next available value from here.

    This creates a carveout with an intentional overhead of requiring writing a draft.
    This ensures that we'll never run out of this space. Experimental RFCs would
    use this registry.

    This allows anyone to request a code-point and register it without overhead,
    as IANA does not review the request. This means that we can use the registry
    simply as a collision-avoidance mechanism.

We should strongly encourage customers of the [64+] registries to generate
their desired codepoint randomly.

I agree with removing Private Use for the reasons stated by others, but I do think
that if someone wants to build a proprietary extension, they should be able to
do so without having to document it publicly - because in reality people will
be building undocumented proprietary extensions, so we can either give them
a part of the registry that works for them, or they'll resort to squatting. And
I think First Come First Serve will get us what we want here. I don't think
Provisional Registrations fit the bill here because these proprietary extensions
have no reason to be time-limited.


I think I like Martin's proposal better. My reasoning is that there is no practical difference between the numbers as long as TP are encoded on 16 bits, and I have a hard time believing that any IANA registry could efficiently manage more than a few thousand code points. Plus specification required is really nice for the community.

-- Christian Huitema

--------------B5132A6FA5D036233E910014-- From nobody Fri Oct 25 05:19:15 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D73120874 for ; Fri, 25 Oct 2019 05:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 JafauUSN4Nn4 for ; Fri, 25 Oct 2019 05:19:11 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50075.outbound.protection.outlook.com [40.107.5.75]) (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 9112812007C for ; Fri, 25 Oct 2019 05:19:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WSqy1ZNLern9ICp9Sp3LQealJc+g0GcWbrAkUPPUv+qgW1fkV4c71pdpBgItOsZurGmg++MyF0y3QDVycnX4HYOzEoVi8lVfHLL+hizZqiJYQxD+xYINFFpAao9VfoG6DxsoXbzdw8nqdnDd2cFOQoMS4gwspSM8RXyKope9V2eYZzBbPNQzR+q/jineOdfXre9IjIdSqpjuPEdiice3KeJInxj4Eky4JABQgpLLC5JvAyYnlb0pQHfxetDnbbpALuOcAhZOW4DhU3azBQqpQyiyxlkPJtDh5qLZ+yqtTD2x0YFGsGo/BJWapkM90JQugl1BOKM7eLPu92u+lu88Yg== 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=4x8WBypPZkVMduX7HzgmR4vbTBRN6BWsuwOG3rYRV64=; b=R6FZCvzl8tlFeI7RT4j09rA7sWo2p99rJSh/lDWCuf7x1QqrkV4Am8Am9/17iqAH8275ANEHhG5BpuQ5dtvzEJMKTtskiTrNkuPAtT2Sl2n5QLEOdIWeMbZO+BKMfXQ2Z3pRKQ7I8hgXgqxDMKMQZaOGTbYCtnvRlb+rQuuogOcCxL2eNhdUtBvWJgQpM8zPw8RJ2Zzcxf0srMzY3ruLJ2oeAE8h2rQ+cKKLnAxOgCv5io0gkDXn97c3yoFnmt3Z8oQBGHmaRYi6GTIG3H9wKG5/fCuSPAhL+VgsAcdSkVEpDWwme5Y233JlB33sIkiVrB5pJU6zMsj2DOmz3ZCLKQ== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4x8WBypPZkVMduX7HzgmR4vbTBRN6BWsuwOG3rYRV64=; b=RFIV3qrIuXDWGEON0RmLI6bHQJJmIGxen5ct6M1WVI/1XrV0/FHK1xyRPmNYbl4U9XQZJwa0SxOioQQiKXMLJzRqMTxXfcDqdVFvhFWMnFxXGuqP2PIeXweEnjf5p/JfOsXMmDTA1ptIz0vmECOB2rn7MXRCWr6/pr6MmnoxOTA= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB6435.eurprd07.prod.outlook.com (10.186.174.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.14; Fri, 25 Oct 2019 12:19:08 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4573:6a4c:8bb5:1456]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4573:6a4c:8bb5:1456%5]) with mapi id 15.20.2387.021; Fri, 25 Oct 2019 12:19:07 +0000 From: Mirja Kuehlewind To: Christian Huitema , David Schinazi , Martin Thomson CC: QUIC Subject: Re: Making QUIC less constraining for innovation Thread-Topic: Making QUIC less constraining for innovation Thread-Index: AQHVihr5J4TvUgA3aU+ZJMysrDnj9KdpNBgAgAANYACAAAWDAIAADFuAgADS/ACAAFojAIAARmmAgAAgxQCAAIJ5gA== Date: Fri, 25 Oct 2019 12:19:07 +0000 Message-ID: <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.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:24dd:3600:24f5:b472:c7ca:8356] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d9ad048f-3c7d-48f7-1044-08d7594588d6 x-ms-traffictypediagnostic: AM0PR07MB6435: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02015246A9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(136003)(376002)(366004)(396003)(189003)(199004)(51444003)(53754006)(8676002)(33656002)(561944003)(81166006)(81156014)(36756003)(2906002)(25786009)(256004)(14444005)(478600001)(8936002)(606006)(5660300002)(316002)(110136005)(229853002)(76176011)(486006)(46003)(102836004)(53546011)(6506007)(44832011)(7736002)(86362001)(99286004)(6116002)(446003)(11346002)(2616005)(6306002)(54896002)(6512007)(64756008)(71200400001)(76116006)(6246003)(66446008)(6436002)(66556008)(66476007)(14454004)(71190400001)(66946007)(186003)(476003)(236005)(4326008)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6435; 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: swoXCBe67G7BT+p7HwtbdIcBE+npJWrpJW6WP3X1K3CoFf8rM8E4dx1RTEcLDXg0A0ZAGuq3AfZPS6N6CL+YW7bDY0wENHtQ3bPWV1h9TH/kE44UXsoMS+ShZ3eNUY6mjfRHH5H9s72/6T4B018pUbjq74q4hBozlzcrXiEXkfQ/oNfxHf5LgAZmTFxCGtDXXUYmoBA3VajRjFf2AANfFgur97iCRvjewkXmxhfNBtx6f/z474cJyx9EqnNKCXk0RFJ5TdBvBdQq21sebw4OL3IPug5+SR8Qi93fb4oLpFqeum+U3InHdM750lLFbS8jaC32IcS4Z/FeAv1kQmrS/4bHDGLnEaYkD/GbCiNXjM8p3ixbvRGjuVqpCNsjvdOWPRnTSOeR9zN7KjUFAE/dIQEFfh5NDEYYIDPKcC+fKLnBWC2rKM4GGvK+dgwS/QqaHUsZ2oC4dYmfvcnGWF88oxSqOt3XpEg1uPNdNvQHH6E= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3DDC7ED2B9E44FF2B8BB7F84D4A049FCericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d9ad048f-3c7d-48f7-1044-08d7594588d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2019 12:19:07.8720 (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: Jc7rL8vhU1Q+0EK3Fvbu6gc6xg2PdmOO9JY67CCl1GK7SVZfd+XZzWMntch0jxOG6dbB/J0ZXHX1DhXNv0LNV6u2vh5QcqDnsSowmi1hZ6M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6435 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, 25 Oct 2019 12:19:14 -0000 --_000_3DDC7ED2B9E44FF2B8BB7F84D4A049FCericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluLCBoaSBhbGwsDQoNCmp1c3QgcmVwbHlpbmcgdG8gdGhlIGxhc3QgbWFpbCBpbiB0 aGlzIHRocmVhZCwgYnV0IEkgaGF2ZSB0d28gcG9pbnRzICh3aGljaCB0byBzb21lIGV4dGVuZCBt YXkgcmVsYXRlIHRvIG90aGVyIHBvaW50cyBhbHJlYWR5IG1hZGUpOg0KDQoNCiAgMS4gIFByaXZh dGUgdXNlOiBEYXZpZCBzYWlkIHNvbWV0aGluZyB0aGF0IGhlIHN0aWxsIHdvdWxkIGxpa2UgcHJp dmF0ZSB1c2UgZm9yIGNhc2VzIHdoZXJlIHNvbWVvbmUgZG9u4oCZdCB3YW50IHRvIHJldmVhbCBh bnl0aGluZyAoPykuIEkgdGhpbmsganVzdCByZWdpc3RlcmluZyBhIGNvZGVwb2ludCB3aXRoIGEg cmFuZG9tIG5hbWUgYW5kIHdpdGhvdXQgYW55IGRvY3VtZW50YXRpb24gd291bGRu4oCZdCBhY3R1 YWxseSByZXZlYWwgYW55dGhpbmcgYnV0IHN0aWxsIGhlbHBzIHRoZSByZXF1ZXN0ZXIgIHRoYXQg bm9ib2R5IGVsc2Ugd2lsbCBldmVyeSB1c2UgdGhlIHNhbWUgY29kZSBmb3IgYSBkaWZmZXJlbnQg cGFyYW1ldGVyIGluIGZ1dHVyZSB3aGljaCB3b3VsZCBjYXNlIHRoZSByZXF1ZXN0IHRvIHVwZGF0 ZSB0aGVpciBjb2RlLiBJIHRoaW5rIHRoYXTigJlzIGV4YWN0bHkgdGhlIHBvaW50IG9mIHRoZSBy ZWdpc3RyeS4gSG93ZXZlciwgSSB3b3VsZCBzdGlsbCBsaWtlIHRvIHJlc2VydmUgb25lIG9yIHR3 byBjb2RlcG9pbnRzIGZvciAocHJpdmF0ZSkgZXhwZXJpbWVudGF0aW9uLiBUaGF04oCZcyBiYXNp Y2FsbHkgdGhlIGNvZGVwb2ludCB5b3Ugd291bGQgdXNlIGluIHlvdXIgaW5pdGlhbCBpbXBsZW1l bnRhdGlvbiBmb3IgeW91ciBpbml0aWFsIHRlc3RpbmcgYmVjYXVzZSBzb21ldGhpbmcgdGhlc2Ug Y29kZSBmcmFnbWVudCBqdXN0IGhhbmcgYXJvdW5kIHdpdGhvdXQgdXNhZ2UgdW50aWwgc29tZW9u ZSBzdWRkZW5seSBmaW5kcyBpdCBhbmQgdGhhdCB3b3VsZCBpbmNyZWFzZSB0aGUgbmVlZCB0byBh Y3R1YWxseSBnbyBhbmQgcmVnaXN0ZXIgaWYgeW91IHJlYWxseSB3YW50IHRvIHVzZSBpdC4gTm90 IHN1cmUgaWYgaXQgaGVscHMsIGJ1dCBJIHdvdWxkIGxpa2UgdG8gdHJ5Lg0KICAyLiAgSeKAmW0g YWZyYWlkIHRoYXQgaWYgd2UgaGF2ZSB0aGUgcHJvdmlzaW9uYWwgRkNGUyB0aGF0IHRoZXJlIGlz IGFjdHVhbGx5IG5vIHBlcmNlaXZlZCBuZWVkIGFueSBtb3JlIHRvIG1ha2UgYSByZWFsIHJlZ2lz dHJhdGlvbiBhdCBzb21lIHBvaW50LiBBbHNvIEZDRlMgaXMgdXN1YWxseSB3aXRob3V0IGFueSBl eHBlcnQgcmV2aWV3IGJlY2F1c2UgdGhlIHRhc2sgb2YgcmVtb3ZpbmcganVuayBvciBkb3ViZS1j aGVja2luZyBpZiB0b28gbWFueSByZXF1ZXN0IGFyZSBzZW5kIGF0IG9uY2UgZnJvbSB0aGUgc2Ft ZSBwYXJ0eSBpcyB1c3VhbGx5IHNvbWV0aGluZyBJQU5BIGNhbiBkbyBvbiBpdHMgb3duLiBTbyBJ IHdvbmRlcmluZyBpZiBoYXZpbmcgZXhwZXJ0cyBhbmQgaGF2aW5nIHRoZSBTcGVjIHJlcXVpcmVk IHBhcnQgaXMgYWN0dWFsbHkgdXNlZnVsLCBpZiB0aGlzIG1vZGVsIHdpbGwgZW5kIHVwIGFueXdh eSBzdWNoIHRoYXQgZXZlcnlib2R5IGNhbiBnZXQgYSByZWdpc3RyYXRpb24gbm8gbWF0dGVyIHdo YXQuIE9uIHRoZSBvdGhlciBoYW5kIGl0IHdvdWxkIGJlIG5pY2UgdG8gcHJvdmlkZSBhbiBpbmNl bnRpdmUgdG8gYWxzbyBwcm92aWRlIGEgcG9pbnRlciB0byBhIHNwZWMgKHdoaWNoIGJ0dyBkb2Vz IG5vdCBoYXZlIHRvIGJlIGFuIEktRCksIGhvd2V2ZXIsIEkgZG9u4oCZdCBzZWUgdGhhdCB0aGUg ZGlmZmVyZW5jZSBiZXR3ZWVuIGEgdGhlb3JldGljYWwgcGVybWFuZW50IG9yIOKAnG9ubHnigJ0g cHJvdmlzaW9uYWwgcmVnaXN0cmF0aW9uIHdpbGwgcHJvdmlkZSB0aGlzIGluY2VudGl2ZS4gTXkg Z3Vlc3MgaXMgcmF0aGVyIHRoYXQgaWYgd2UgaGF2ZSBhIGZpZWxkIGZvciBhIHJlZmVyZW5jZSBs aW5rIGluIHRoZSByZWdpc3RyeSB0aGF0IHBlb3BsZSB3aWxsIHByb3ZpZGUgdGhhdCBwb2ludGVy IGFueXdheSBpZiBhdmFpbGFibGUuDQoNCk1pcmphDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRl bWEubmV0Pg0KRGF0ZTogRnJpZGF5LCAyNS4gT2N0b2JlciAyMDE5IGF0IDA4OjM5DQpUbzogRGF2 aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT4sIE1hcnRpbiBUaG9tc29uIDxt dEBsb3dlbnRyb3B5Lm5ldD4NCkNjOiBRVUlDIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IE1ha2luZyBRVUlDIGxlc3MgY29uc3RyYWluaW5nIGZvciBpbm5vdmF0aW9uDQoNCg0KDQpPbiAx MC8yNC8yMDE5IDk6MzQgUE0sIERhdmlkIFNjaGluYXppIHdyb3RlOg0KWzAtNjNdIFN0YW5kYXJk cyBBY3Rpb248aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxMjYjc2VjdGlvbi00Ljk+ IG9yIElFU0cgQXBwcm92YWw8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxMjYjc2Vj dGlvbi00LjEwPg0KICAgIFRoaXMgZ2l2ZXMgdGhlIElFVEYgYSBsaXR0bGUgcHJvdGVjdGVkIGdh cmRlbiBhbmQgdGhhdCBtZWFucyB0aGF0IGZvbGtzIGRldmVsb3BpbmcNCiAgICBleHRlbnNpb25z IGFuZCBleHBlcmltZW50cyB3b24ndCB1c2UgdGhlIG5leHQgYXZhaWxhYmxlIHZhbHVlIGZyb20g aGVyZS4NCg0KWzY0LTE2MzgzXSBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM4MTI2I3NlY3Rpb24tNC42Pg0KICAgIFRoaXMgY3JlYXRlcyBhIGNh cnZlb3V0IHdpdGggYW4gaW50ZW50aW9uYWwgb3ZlcmhlYWQgb2YgcmVxdWlyaW5nIHdyaXRpbmcg YSBkcmFmdC4NCiAgICBUaGlzIGVuc3VyZXMgdGhhdCB3ZSdsbCBuZXZlciBydW4gb3V0IG9mIHRo aXMgc3BhY2UuIEV4cGVyaW1lbnRhbCBSRkNzIHdvdWxkDQogICAgdXNlIHRoaXMgcmVnaXN0cnku DQoNClsxNjM4NCtdIEZpcnN0IENvbWUgRmlyc3QgU2VydmU8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzgxMjYjc2VjdGlvbi00LjQ+DQogICAgVGhpcyBhbGxvd3MgYW55b25lIHRvIHJl cXVlc3QgYSBjb2RlLXBvaW50IGFuZCByZWdpc3RlciBpdCB3aXRob3V0IG92ZXJoZWFkLA0KICAg IGFzIElBTkEgZG9lcyBub3QgcmV2aWV3IHRoZSByZXF1ZXN0LiBUaGlzIG1lYW5zIHRoYXQgd2Ug Y2FuIHVzZSB0aGUgcmVnaXN0cnkNCiAgICBzaW1wbHkgYXMgYSBjb2xsaXNpb24tYXZvaWRhbmNl IG1lY2hhbmlzbS4NCg0KV2Ugc2hvdWxkIHN0cm9uZ2x5IGVuY291cmFnZSBjdXN0b21lcnMgb2Yg dGhlIFs2NCtdIHJlZ2lzdHJpZXMgdG8gZ2VuZXJhdGUNCnRoZWlyIGRlc2lyZWQgY29kZXBvaW50 IHJhbmRvbWx5Lg0KDQpJIGFncmVlIHdpdGggcmVtb3ZpbmcgUHJpdmF0ZSBVc2U8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzgxMjYjc2VjdGlvbi00LjE+IGZvciB0aGUgcmVhc29ucyBz dGF0ZWQgYnkgb3RoZXJzLCBidXQgSSBkbyB0aGluaw0KdGhhdCBpZiBzb21lb25lIHdhbnRzIHRv IGJ1aWxkIGEgcHJvcHJpZXRhcnkgZXh0ZW5zaW9uLCB0aGV5IHNob3VsZCBiZSBhYmxlIHRvDQpk byBzbyB3aXRob3V0IGhhdmluZyB0byBkb2N1bWVudCBpdCBwdWJsaWNseSAtIGJlY2F1c2UgaW4g cmVhbGl0eSBwZW9wbGUgd2lsbA0KYmUgYnVpbGRpbmcgdW5kb2N1bWVudGVkIHByb3ByaWV0YXJ5 IGV4dGVuc2lvbnMsIHNvIHdlIGNhbiBlaXRoZXIgZ2l2ZSB0aGVtDQphIHBhcnQgb2YgdGhlIHJl Z2lzdHJ5IHRoYXQgd29ya3MgZm9yIHRoZW0sIG9yIHRoZXknbGwgcmVzb3J0IHRvIHNxdWF0dGlu Zy4gQW5kDQpJIHRoaW5rIEZpcnN0IENvbWUgRmlyc3QgU2VydmU8aHR0cHM6Ly90b29scy5pZXRm Li5vcmcvaHRtbC9yZmM4MTI2I3NlY3Rpb24tNC40PiB3aWxsIGdldCB1cyB3aGF0IHdlIHdhbnQg aGVyZS4gSSBkb24ndCB0aGluaw0KUHJvdmlzaW9uYWwgUmVnaXN0cmF0aW9uczxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjODEyNiNzZWN0aW9uLTQuMTM+IGZpdCB0aGUgYmlsbCBoZXJl IGJlY2F1c2UgdGhlc2UgcHJvcHJpZXRhcnkgZXh0ZW5zaW9ucw0KaGF2ZSBubyByZWFzb24gdG8g YmUgdGltZS1saW1pdGVkLg0KDQoNCg0KSSB0aGluayBJIGxpa2UgTWFydGluJ3MgcHJvcG9zYWwg YmV0dGVyLiBNeSByZWFzb25pbmcgaXMgdGhhdCB0aGVyZSBpcyBubyBwcmFjdGljYWwgZGlmZmVy ZW5jZSBiZXR3ZWVuIHRoZSBudW1iZXJzIGFzIGxvbmcgYXMgVFAgYXJlIGVuY29kZWQgb24gMTYg Yml0cywgYW5kIEkgaGF2ZSBhIGhhcmQgdGltZSBiZWxpZXZpbmcgdGhhdCBhbnkgSUFOQSByZWdp c3RyeSBjb3VsZCBlZmZpY2llbnRseSBtYW5hZ2UgbW9yZSB0aGFuIGEgZmV3IHRob3VzYW5kIGNv ZGUgcG9pbnRzLiBQbHVzIHNwZWNpZmljYXRpb24gcmVxdWlyZWQgaXMgcmVhbGx5IG5pY2UgZm9y IHRoZSBjb21tdW5pdHkuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQo= --_000_3DDC7ED2B9E44FF2B8BB7F84D4A049FCericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjkxMjA3NTg2Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTUxODk3NTg1NCAxMzQ4MDc1NzUgMTM0 ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1Njcg MTM0ODA3NTc3IDEzNDgwNzU3OTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBNYXJ0aW4s IGhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5qdXN0IHJlcGx5aW5nIHRv IHRoZSBsYXN0IG1haWwgaW4gdGhpcyB0aHJlYWQsIGJ1dCBJIGhhdmUgdHdvIHBvaW50cyAod2hp Y2ggdG8gc29tZSBleHRlbmQgbWF5IHJlbGF0ZSB0byBvdGhlciBwb2ludHMgYWxyZWFkeSBtYWRl KTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iMSIgdHlw ZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow Y207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlByaXZhdGUgdXNlOiBEYXZpZCBzYWlkIHNvbWV0aGlu ZyB0aGF0IGhlIHN0aWxsIHdvdWxkIGxpa2UgcHJpdmF0ZSB1c2UgZm9yIGNhc2VzIHdoZXJlIHNv bWVvbmUgZG9u4oCZdCB3YW50IHRvIHJldmVhbCBhbnl0aGluZyAoPykuDQogSSB0aGluayBqdXN0 IHJlZ2lzdGVyaW5nIGEgY29kZXBvaW50IHdpdGggYSByYW5kb20gbmFtZSBhbmQgd2l0aG91dCBh bnkgZG9jdW1lbnRhdGlvbiB3b3VsZG7igJl0IGFjdHVhbGx5IHJldmVhbCBhbnl0aGluZyBidXQg c3RpbGwgaGVscHMgdGhlIHJlcXVlc3RlciAmbmJzcDt0aGF0IG5vYm9keSBlbHNlIHdpbGwgZXZl cnkgdXNlIHRoZSBzYW1lIGNvZGUgZm9yIGEgZGlmZmVyZW50IHBhcmFtZXRlciBpbiBmdXR1cmUg d2hpY2ggd291bGQgY2FzZSB0aGUgcmVxdWVzdA0KIHRvIHVwZGF0ZSB0aGVpciBjb2RlLiBJIHRo aW5rIHRoYXTigJlzIGV4YWN0bHkgdGhlIHBvaW50IG9mIHRoZSByZWdpc3RyeS4gSG93ZXZlciwg SSB3b3VsZCBzdGlsbCBsaWtlIHRvIHJlc2VydmUgb25lIG9yIHR3byBjb2RlcG9pbnRzIGZvciAo cHJpdmF0ZSkgZXhwZXJpbWVudGF0aW9uLiBUaGF04oCZcyBiYXNpY2FsbHkgdGhlIGNvZGVwb2lu dCB5b3Ugd291bGQgdXNlIGluIHlvdXIgaW5pdGlhbCBpbXBsZW1lbnRhdGlvbiBmb3IgeW91ciBp bml0aWFsDQogdGVzdGluZyBiZWNhdXNlIHNvbWV0aGluZyB0aGVzZSBjb2RlIGZyYWdtZW50IGp1 c3QgaGFuZyBhcm91bmQgd2l0aG91dCB1c2FnZSB1bnRpbCBzb21lb25lIHN1ZGRlbmx5IGZpbmRz IGl0IGFuZCB0aGF0IHdvdWxkIGluY3JlYXNlIHRoZSBuZWVkIHRvIGFjdHVhbGx5IGdvIGFuZCBy ZWdpc3RlciBpZiB5b3UgcmVhbGx5IHdhbnQgdG8gdXNlIGl0LiBOb3Qgc3VyZSBpZiBpdCBoZWxw cywgYnV0IEkgd291bGQgbGlrZSB0byB0cnkuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPknigJltIGFmcmFpZCB0aGF0IGlmIHdlIGhhdmUgdGhlIHByb3Zpc2lvbmFsIEZD RlMgdGhhdCB0aGVyZSBpcyBhY3R1YWxseSBubyBwZXJjZWl2ZWQgbmVlZCBhbnkgbW9yZSB0byBt YWtlIGEgcmVhbCByZWdpc3RyYXRpb24NCiBhdCBzb21lIHBvaW50LiBBbHNvIEZDRlMgaXMgdXN1 YWxseSB3aXRob3V0IGFueSBleHBlcnQgcmV2aWV3IGJlY2F1c2UgdGhlIHRhc2sgb2YgcmVtb3Zp bmcganVuayBvciBkb3ViZS1jaGVja2luZyBpZiB0b28gbWFueSByZXF1ZXN0IGFyZSBzZW5kIGF0 IG9uY2UgZnJvbSB0aGUgc2FtZSBwYXJ0eSBpcyB1c3VhbGx5IHNvbWV0aGluZyBJQU5BIGNhbiBk byBvbiBpdHMgb3duLiBTbyBJIHdvbmRlcmluZyBpZiBoYXZpbmcgZXhwZXJ0cyBhbmQgaGF2aW5n DQogdGhlIFNwZWMgcmVxdWlyZWQgcGFydCBpcyBhY3R1YWxseSB1c2VmdWwsIGlmIHRoaXMgbW9k ZWwgd2lsbCBlbmQgdXAgYW55d2F5IHN1Y2ggdGhhdCBldmVyeWJvZHkgY2FuIGdldCBhIHJlZ2lz dHJhdGlvbiBubyBtYXR0ZXIgd2hhdC4gT24gdGhlIG90aGVyIGhhbmQgaXQgd291bGQgYmUgbmlj ZSB0byBwcm92aWRlIGFuIGluY2VudGl2ZSB0byBhbHNvIHByb3ZpZGUgYSBwb2ludGVyIHRvIGEg c3BlYyAod2hpY2ggYnR3IGRvZXMgbm90IGhhdmUgdG8NCiBiZSBhbiBJLUQpLCBob3dldmVyLCBJ IGRvbuKAmXQgc2VlIHRoYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHRoZW9yZXRpY2FsIHBl cm1hbmVudCBvciDigJxvbmx54oCdIHByb3Zpc2lvbmFsIHJlZ2lzdHJhdGlvbiB3aWxsIHByb3Zp ZGUgdGhpcyBpbmNlbnRpdmUuIE15IGd1ZXNzIGlzIHJhdGhlciB0aGF0IGlmIHdlIGhhdmUgYSBm aWVsZCBmb3IgYSByZWZlcmVuY2UgbGluayBpbiB0aGUgcmVnaXN0cnkgdGhhdCBwZW9wbGUgd2ls bCBwcm92aWRlIHRoYXQNCiBwb2ludGVyIGFueXdheSBpZiBhdmFpbGFibGUuPG86cD48L286cD48 L3NwYW4+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWlyamE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJv bToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PlFVSUMgJmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIENocmlzdGlh biBIdWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5G cmlkYXksIDI1LiBPY3RvYmVyIDIwMTkgYXQgMDg6Mzk8YnI+DQo8Yj5UbzogPC9iPkRhdmlkIFNj aGluYXppICZsdDtkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20mZ3Q7LCBNYXJ0aW4gVGhvbXNvbiAm bHQ7bXRAbG93ZW50cm9weS5uZXQmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5RVUlDICZsdDtxdWljQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogTWFraW5nIFFVSUMgbGVzcyBjb25z dHJhaW5pbmcgZm9yIGlubm92YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMTAvMjQvMjAxOSA5OjM0IFBNLCBEYXZpZCBTY2hpbmF6 aSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+WzAtNjNdIDxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTI2I3NlY3Rpb24tNC45Ij4NClN0YW5kYXJkcyBBY3Rp b248L2E+IG9yIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTI2I3Nl Y3Rpb24tNC4xMCI+DQpJRVNHIEFwcHJvdmFsPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5i c3A7ICZuYnNwOyBUaGlzIGdpdmVzIHRoZSBJRVRGIGEgbGl0dGxlIHByb3RlY3RlZCBnYXJkZW4g YW5kIHRoYXQgbWVhbnMgdGhhdCBmb2xrcyBkZXZlbG9waW5nPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4mbmJzcDsgJm5ic3A7IGV4dGVuc2lvbnMgYW5kIGV4cGVyaW1lbnRzIHdvbid0IHVzZSB0aGUg bmV4dCBhdmFpbGFibGUgdmFsdWUgZnJvbSBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5bNjQtMTYzODNdIDxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTI2I3NlY3Rpb24tNC42Ij4NClNwZWNpZmljYXRpb24gUmVx dWlyZWQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsgJm5ic3A7IFRoaXMgY3JlYXRl cyBhIGNhcnZlb3V0IHdpdGggYW4gaW50ZW50aW9uYWwgb3ZlcmhlYWQgb2YgcmVxdWlyaW5nIHdy aXRpbmcgYSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyAmbmJzcDsgVGhpcyBl bnN1cmVzIHRoYXQgd2UnbGwgbmV2ZXIgcnVuIG91dCBvZiB0aGlzIHNwYWNlLiBFeHBlcmltZW50 YWwgUkZDcyB3b3VsZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7ICZuYnNwOyB1c2UgdGhp cyByZWdpc3RyeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+WzE2Mzg0JiM0MztdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM4MTI2I3NlY3Rpb24tNC40Ij4NCkZpcnN0IENvbWUgRmlyc3QgU2VydmU8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mbmJzcDsgJm5ic3A7IFRoaXMgYWxsb3dzIGFueW9uZSB0byByZXF1ZXN0 IGEgY29kZS1wb2ludCBhbmQgcmVnaXN0ZXIgaXQgd2l0aG91dCBvdmVyaGVhZCw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZuYnNwOyAmbmJzcDsgYXMgSUFOQSBkb2VzIG5vdCByZXZpZXcgdGhlIHJl cXVlc3QuIFRoaXMgbWVhbnMgdGhhdCB3ZSBjYW4gdXNlIHRoZSByZWdpc3RyeTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jm5ic3A7ICZuYnNwOyBzaW1wbHkgYXMgYSBjb2xsaXNpb24tYXZvaWRhbmNl IG1lY2hhbmlzbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPldlIHNob3VsZCBzdHJvbmdseSBlbmNvdXJhZ2UgY3VzdG9tZXJzIG9mIHRo ZSBbNjQmIzQzO10gcmVnaXN0cmllcyB0byBnZW5lcmF0ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ dGhlaXIgZGVzaXJlZCBjb2RlcG9pbnQgcmFuZG9tbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSBhZ3JlZSB3aXRoIHJlbW92aW5n IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTI2I3NlY3Rpb24tNC4x Ij4NClByaXZhdGUgVXNlPC9hPiBmb3IgdGhlIHJlYXNvbnMgc3RhdGVkIGJ5IG90aGVycywgYnV0 IEkgZG8gdGhpbms8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnRoYXQgaWYgc29tZW9uZSB3YW50cyB0 byBidWlsZCBhIHByb3ByaWV0YXJ5IGV4dGVuc2lvbiwgdGhleSBzaG91bGQgYmUgYWJsZSB0bzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ZG8gc28gd2l0aG91dCBoYXZpbmcgdG8gZG9jdW1lbnQgaXQg cHVibGljbHkgLSBiZWNhdXNlIGluIHJlYWxpdHkgcGVvcGxlIHdpbGw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPmJlIGJ1aWxkaW5nIHVuZG9jdW1lbnRlZCBwcm9wcmlldGFyeSBleHRlbnNpb25zLCBz byB3ZSBjYW4gZWl0aGVyIGdpdmUgdGhlbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+YSBwYXJ0IG9m IHRoZSByZWdpc3RyeSB0aGF0IHdvcmtzIGZvciB0aGVtLCBvciB0aGV5J2xsIHJlc29ydCB0byBz cXVhdHRpbmcuIEFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSB0aGluayA8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYuLm9yZy9odG1sL3JmYzgxMjYjc2VjdGlvbi00LjQiPg0KRmlyc3QgQ29t ZSBGaXJzdCBTZXJ2ZTwvYT4gd2lsbCBnZXQgdXMgd2hhdCB3ZSB3YW50IGhlcmUuIEkgZG9uJ3Qg dGhpbms8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM4MTI2I3NlY3Rpb24tNC4xMyI+UHJvdmlzaW9uYWwgUmVnaXN0cmF0aW9uczwv YT4gZml0IHRoZSBiaWxsIGhlcmUgYmVjYXVzZSB0aGVzZSBwcm9wcmlldGFyeSBleHRlbnNpb25z PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5oYXZlIG5vIHJlYXNvbiB0byBiZSB0aW1lLWxpbWl0ZWQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+SSB0aGluayBJIGxpa2UgTWFydGluJ3MgcHJvcG9zYWwgYmV0dGVyLiBNeSByZWFz b25pbmcgaXMgdGhhdCB0aGVyZSBpcyBubyBwcmFjdGljYWwgZGlmZmVyZW5jZSBiZXR3ZWVuIHRo ZSBudW1iZXJzIGFzIGxvbmcgYXMgVFAgYXJlIGVuY29kZWQgb24gMTYgYml0cywgYW5kIEkgaGF2 ZSBhIGhhcmQgdGltZSBiZWxpZXZpbmcgdGhhdCBhbnkgSUFOQSByZWdpc3RyeSBjb3VsZCBlZmZp Y2llbnRseQ0KIG1hbmFnZSBtb3JlIHRoYW4gYSBmZXcgdGhvdXNhbmQgY29kZSBwb2ludHMuIFBs dXMgc3BlY2lmaWNhdGlvbiByZXF1aXJlZCBpcyByZWFsbHkgbmljZSBmb3IgdGhlIGNvbW11bml0 eS48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0tIENocmlz dGlhbiBIdWl0ZW1hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3DDC7ED2B9E44FF2B8BB7F84D4A049FCericssoncom_-- From nobody Fri Oct 25 05:30:32 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC2B120878 for ; Fri, 25 Oct 2019 05:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, 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 dL8Sx6fXeZOf for ; Fri, 25 Oct 2019 05:30:30 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 83C12120877 for ; Fri, 25 Oct 2019 05:30:30 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9PCRK9r004432; Fri, 25 Oct 2019 13:30:25 +0100 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=qZX3eYEcrWzV7mYRDfKCfii45qSlusqZ08RSfcMu3LA=; b=ocX3S0K3XGRu2bf7jijkqQ5FxIuYyF2YKbHRGOxKdlRGVGvtNaLpbhdWw8pztX7in/73 alb5u6PjkG+TWCYmeErX6V7+FZlePJVUbu9qr5D+wvfHWVMzF7Nz73urB/eE1QfTapqa dmie8uNRlU2qWXrbYrbGt/CKLPXJ2ydogKtun4uq2SKjC7le+ROfxf9dfeVW79NkbWmE C2K2hvvWraTdELRckHFCBp7jrWa4XxBc+2d/Q+KCjnTdcVCK3M5p7/Yz51UpgDDwYo++ BJ77EF3xzJ5SWQBKQw/1A5Mj6qXItb9NCegKvFoon6Liypg932AUeifQPYlnGcMA44B0 sw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2vqt14f14u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Oct 2019 13:30:25 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9PCH4lq011608; Fri, 25 Oct 2019 08:30:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2vqwtwuqpf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 25 Oct 2019 08:30:24 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 08:30:23 -0400 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; Fri, 25 Oct 2019 08:30:23 -0400 From: "Salz, Rich" To: Mirja Kuehlewind , Christian Huitema , David Schinazi , Martin Thomson CC: QUIC Subject: Re: Making QUIC less constraining for innovation Thread-Topic: Making QUIC less constraining for innovation Thread-Index: AQHVihr0wKOBWmevhU2YcAoLtno5GKdpdyYAgAANYACAAAWDAIAADFuAgADS/QCAAFoiAIAARmmAgAAgxQCAAGDygP//wBaA Date: Fri, 25 Oct 2019 12:30:22 +0000 Message-ID: <35A5A8D0-9E1D-44A8-8DCB-8D1AC689A916@akamai.com> References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> In-Reply-To: <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.80.204] Content-Type: multipart/alternative; boundary="_000_35A5A8D09E1D44A88DCB8D1AC689A916akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-25_07:, , 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=629 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910250117 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-25_07:2019-10-25,2019-10-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 mlxlogscore=609 spamscore=0 lowpriorityscore=0 phishscore=0 suspectscore=0 malwarescore=0 impostorscore=0 priorityscore=1501 mlxscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910250119 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, 25 Oct 2019 12:30:31 -0000 --_000_35A5A8D09E1D44A88DCB8D1AC689A916akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgUHJpdmF0ZSB1c2U6IERhdmlkIHNhaWQgc29tZXRoaW5nIHRoYXQgaGUgc3RpbGwgd291 bGQgbGlrZSBwcml2YXRlIHVzZSBmb3IgY2FzZXMgd2hlcmUgc29tZW9uZSBkb27igJl0IHdhbnQg dG8gcmV2ZWFsIGFueXRoaW5nICg/KS4NCg0KSSBkb27igJl0IHRoaW5rIHdlIGhhdmUgdG8gc3Vw cG9ydCB0aGF0LiAgSWYgeW91IHdhbnQgc29tZXRoaW5nIHJlc2VydmVkIGZvciB5b3Vyc2VsZiwg YW5kIHlvdSB3YW50IHRvIGF2b2lkIGNvbGxpc2lvbnMsIHRoZW4gc2F5aW5nIHlvdSBoYXZlIHRv IGRlc2NyaWJlIHRoaW5ncyDigJMgdGhhdOKAmXMgYSBmYWlyIHRyYWRlLW9mZi4NCg0KSWYgdGhl IFdHIHdhbnRzIHRvIHNldCBhc2lkZSBwcml2YXRlIGNvZGUtcG9pbnRzLCB3aXRoIG5vIGd1YXJh bnRlZSBhYm91dCBjb25mbGljdHMgaWYgZm91bmQgb24gdGhlIHB1YmxpYyBpbnRlcm5ldCwgdGhh dOKAmXMgYWxzbyByZWFzb25hYmxlIHRvIG1lLg0KDQpJZiB5b3Ugd2FudCBwYWNrZXRzIG9uIHRo ZSBJbnRlcm5ldCwgYW5kIHlvdSB3YW50IHRoZW0gdG8gYXZvaWQgY29uZmxpY3Qgd2l0aCBhbnlv bmUgZWxzZeKAmXMgcGFja2V0cyBvbiB0aGUgSW50ZXJuZXQsIHRoZW4geW91IGhhdmUgdG8gZG9j dW1lbnQgdGhlbSBvciBlbmNyeXB0IHRoZW0uDQo= --_000_35A5A8D09E1D44A88DCB8D1AC689A916akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <2E70CFBDEDB09F4080EAA1E0AD426211@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNTYuN3B0IDcwLjg1cHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxODY0NTYxNTQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi01Mzc3MzIwNTg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMQ0KCXtt c28tbGlzdC1pZDoxMTg3NDQ3ODQ3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotNDM0MTg4ODkyIDEzMjE2MjU0OTAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxp c3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMjkxMjA3NTg2Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTUxODk3NTg1NCAxMzQ4MDc1 NzUgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4 MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OTt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+UHJpdmF0ZSB1c2U6IERhdmlkIHNh aWQgc29tZXRoaW5nIHRoYXQgaGUgc3RpbGwgd291bGQgbGlrZSBwcml2YXRlIHVzZSBmb3IgY2Fz ZXMgd2hlcmUgc29tZW9uZSBkb27igJl0IHdhbnQgdG8gcmV2ZWFsIGFueXRoaW5nICg/KS48bzpw PjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27igJl0IHRoaW5rIHdlIGhhdmUgdG8gc3Vw cG9ydCB0aGF0LiZuYnNwOyBJZiB5b3Ugd2FudCBzb21ldGhpbmcgcmVzZXJ2ZWQgZm9yIHlvdXJz ZWxmLCBhbmQgeW91IHdhbnQgdG8gYXZvaWQgY29sbGlzaW9ucywgdGhlbiBzYXlpbmcgeW91IGhh dmUgdG8gZGVzY3JpYmUgdGhpbmdzIOKAkyB0aGF04oCZcyBhIGZhaXIgdHJhZGUtb2ZmLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgV0cgd2FudHMgdG8gc2V0IGFzaWRlIHByaXZhdGUg Y29kZS1wb2ludHMsIHdpdGggbm8gZ3VhcmFudGVlIGFib3V0IGNvbmZsaWN0cyBpZiBmb3VuZCBv biB0aGUgcHVibGljIGludGVybmV0LCB0aGF04oCZcyBhbHNvIHJlYXNvbmFibGUgdG8gbWUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSB3YW50IHBhY2tldHMgb24gdGhlIEludGVybmV0 LCBhbmQgeW91IHdhbnQgdGhlbSB0byBhdm9pZCBjb25mbGljdCB3aXRoIGFueW9uZSBlbHNl4oCZ cyBwYWNrZXRzIG9uIHRoZSBJbnRlcm5ldCwgdGhlbiB5b3UgaGF2ZSB0byBkb2N1bWVudCB0aGVt IG9yIGVuY3J5cHQgdGhlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_35A5A8D09E1D44A88DCB8D1AC689A916akamaicom_-- From nobody Fri Oct 25 09:36:21 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFCF1208C0 for ; Fri, 25 Oct 2019 09:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x3Ioy_bQ0yf for ; Fri, 25 Oct 2019 09:36:19 -0700 (PDT) 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 04D17120219 for ; Fri, 25 Oct 2019 09:36:19 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id q13so3032181wrs.12 for ; Fri, 25 Oct 2019 09:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u9QgNEnx4+PRg67aqqiej3SLndQIor5fqHi7GAN5S9k=; b=pvFAToNoG7EPbKAXQ/81SKgk1HOEJPSSEljquv5EYFnuCT10bW9hGWUZpGaec2rwKD 7/T+EGim8J88fZZKK69oFtl7EQDQG6MqlXoOSl3voNgjmgWBV27nyCfQuo6tyMeHDGZw 8vRN/xwBLAhqFoyioKZ+8Xdul5EXB1V9StBJZGzT70R1Q04YHMPydBQyU9usoOooK86o 7ELNaibP2WmbBGsf4sjlqMYQHFtnX94KABwqg3mzlQ8vZMdaPNHcM7T1W31hrjL2qvqN b7qlmFItotwCHLVZ/2xqzAFjMbU+U/k+rNFs0l6I1/h9jxRUHp5n0nr5JV6lJMGQ4XC4 gpqw== 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=u9QgNEnx4+PRg67aqqiej3SLndQIor5fqHi7GAN5S9k=; b=ufH5AumZiRPOICJxeVrIBdtdp1s/tV6gY1Oz1o8HLv29B3sQXVf8X2DADinX+j9qsz MSN34qGoEa1ActP4vIxwMYThTNQ9n0T+WFU12z8P8Q6Boi+M28Dbwy7LmNtYC0SSdwZh baWyGvi/AaRd4yK/tHwO3jPVkyzT+oqzqs/C5Qq4mpvWG5MFMrlmOQO9X42hDYmiXdao WeGuV99NZ0xHccqxkJiSOYz/iaTcnUqj0Uo3dpP2u935tUWVm9N3I2CNNyKtcwOMjkBn JPvCtkrkhsQU8/Cqvs0Hc3C+Mxvi1FIeA/jDOP4vizqA5qDXpZAMmQkwtUP51J0Ba5HL 4RDQ== X-Gm-Message-State: APjAAAWsGZilcc5o92mHHOA7h6gcRy0kYVHdvC3UYIfmqzTNrzMv5OGD BoNnOVTdmTmtFiFLQF3Ij3HHZKAHR6+JJxme5WY= X-Google-Smtp-Source: APXvYqyDNZhuq7tQ2QFtTczJUpma43E16n6j83c5fTEfxnmb3f+dY49Z5JkWhq64FxcvYpZOHZ5dhPetdXujVdwdqPk= X-Received: by 2002:a5d:5282:: with SMTP id c2mr1317636wrv.64.1572021377452; Fri, 25 Oct 2019 09:36:17 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> In-Reply-To: From: Martin Duke Date: Fri, 25 Oct 2019 09:36:05 -0700 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Jana Iyengar Cc: Mike Bishop , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000c84cbf0595bebf4d" 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, 25 Oct 2019 16:36:21 -0000 --000000000000c84cbf0595bebf4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with the dissenters. The current spec works in the HTTP3 use case, though I think we should fix it. Keeping keys forever is unsatisfactory for several reasons. We should use an explicit signal, and there is no reason to kick the can down the road. Let's just leave #2863 open till we resolve it. On Wed, Oct 23, 2019 at 7:40 PM Jana Iyengar wrote: > Yup. We need to get this over with in the dumbest way possible. > > On Thu, Oct 24, 2019 at 3:53 AM Mike Bishop wrote: > >> I think we=E2=80=99ve amply demonstrated that implicit signals don=E2=80= =99t work. I=E2=80=99d >> like to see an explicit confirmation of handshake completion that happen= s >> at 1-RTT. >> >> >> >> *From:* QUIC *On Behalf Of * David Schinazi >> *Sent:* Tuesday, October 22, 2019 4:07 PM >> *To:* Jana Iyengar >> *Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen ; IETF QUIC = WG < >> quic@ietf.org>; Martin Thomson ; Kazuho Oku < >> kazuhooku@gmail.com> >> *Subject:* Re: Consensus Calls for Transport/TLS issues, post-Cupertino >> >> >> >> +1 >> >> >> >> I think the text we have in the spec today is better than the proposal t= o >> never discard the handshake keys. >> >> My preference would be to spend the time to fix the issue, and not add a >> temporary workaround for now. >> >> >> >> On Tue, Oct 22, 2019 at 12:51 AM Jana Iyengar wrote= : >> >> I agree with Kazuho here. The issue of migration was not one we had >> considered. I was going through this with Kazuho, and we may have >> identified yet another issue with handshake retransmissions and migratio= n, >> which is present in the current spec. >> >> >> >> Sadly, I don't think we can call this issue done.. >> >> >> >> On Tue, Oct 22, 2019 at 2:14 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen < >> mikkelfj@gmail.com> wrote: >> >> Without a way to move to a single PN space I find this a deal breaker. I >> might do a custom version of the protocol. >> >> >> >> >> ------------------------------ >> >> *Fra:* QUIC p=C3=A5 vegne af Kazuho Oku < >> kazuhooku@gmail.com> >> *Sendt:* tirsdag, oktober 22, 2019 6:58 AM >> *Til:* Martin Thomson >> *Cc:* IETF QUIC WG >> *Emne:* Re: Consensus Calls for Transport/TLS issues, post-Cupertino >> >> >> >> >> >> >> >> 2019=E5=B9=B410=E6=9C=8822=E6=97=A5(=E7=81=AB) 11:38 Martin Thomson : >> >> On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote: >> > I'd also prefer to fix the problem, even if it means bringing back >> > something like RETIRE_KEY. >> >> I would prefer to think of this proposed resolution as a temporary one. >> I don't think that we agreed to keep the handshake keys indefinitely, on= ly >> that we would use that option as a fallback position until we found a >> better solution. >> >> >> >> I might point out that #3121 is not proposal-ready as a way to resolve >> #2863. That is because it does not define how to send and receive Handsh= ake >> packets until or after migration happens. There would be a deadlock unle= ss >> both endpoints agree on how that should be done (e.g., how to select SCI= D, >> whether the path used for Handshake packets migrates too). >> >> >> >> Without that being clarified, can we say that we are ready for a >> consensus call? >> >> >> >> >> On that basis, I think that it would be best if we open a new issue that >> says "Handshake keys can't ever be dropped". >> >> We might still conclude not to address that issue, but the important >> thing is to ensure that any solution works properly. >> >> >> >> >> -- >> >> Kazuho Oku >> >> --000000000000c84cbf0595bebf4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with the dissenters. The current spec works in the= HTTP3 use case, though I think we should fix it. Keeping keys forever is u= nsatisfactory for several reasons. We should use an explicit signal, and th= ere is no reason to kick the can down the road. Let's just leave #2863 = open till we resolve it.

On Wed, Oct 23, 2019 at 7:40 PM Jana Iyengar = <jri.ietf@gmail.com> wrote:=
Yup. We need to get this over with in the dumbest way possible.

=
On Thu, Oc= t 24, 2019 at 3:53 AM Mike Bishop <mbishop@evequefou.be> wrote:

I think we=E2=80=99ve amply demonstrated that implic= it signals don=E2=80=99t work.=C2=A0 I=E2=80=99d like to see an explicit co= nfirmation of handshake completion that happens at 1-RTT.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = David Schinazi
Sent: Tuesday, October 22, 2019 4:07 PM
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; IETF QUIC WG <= quic@ietf.org>; M= artin Thomson <mt= @lowentropy.net>; Kazuho Oku <kazuhooku@gmail.com>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertin= o

=C2=A0

+1

=C2=A0

I think the text we have in the spec today is better= than the proposal to never discard the handshake keys.

My preference would be to spend the time to fix the = issue, and not add a temporary workaround for now.

=C2=A0

On Tue, Oct 22, 2019 at 12:51 AM Jana Iyengar <jri.ietf@gmail.com> wrote:

I agree with Kazuho here. The issue of migration was= not one we had considered. I was going through this with Kazuho, and we ma= y have identified yet another issue with handshake retransmissions and migr= ation, which is present in the current spec.

=C2=A0

Sadly, I don't think we can call this issue done= ..

=C2=A0

On Tue, Oct 22, 2019 at 2:14 PM Mikkel Fahn=C3=B8e J= =C3=B8rgensen <m= ikkelfj@gmail.com> wrote:

Without a way to move to a single PN space I find th= is a deal breaker. I might do a custom version of the protocol.

=C2=A0

=C2=A0

Fra: QUIC <quic-bounces@ietf.org> p=C3=A5 vegne af = Kazuho Oku <kaz= uhooku@gmail.com>
Sendt: tirsdag, oktober 22, 2019 6:58 AM
Til: Martin Thomson
Cc: IETF QUIC WG
Emne: Re: Consensus Calls for Transport/TLS issues, post-Cupertino <= u>

=C2=A0

=C2=A0

=C2=A0

2019=E6= =9C=8822=E6=97=A5<= /span>(=E7=81=AB) = 11:38 Martin Thomson <mt@lowentropy.net>:

On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote: >=C2=A0 I'd also prefer to fix the problem, even if it means bringin= g back
> something like RETIRE_KEY.

I would prefer to think of this proposed resolution as a temporary one.=C2= =A0 I don't think that we agreed to keep the handshake keys indefinitel= y, only that we would use that option as a fallback position until we found= a better solution.

=C2=A0

I might point out that #3121 is not proposal-ready a= s a way to resolve #2863. That is because it does not define how to send an= d receive Handshake packets until or after migration happens. There would b= e a deadlock unless both endpoints agree on how that should be done (e.g., how to select SCID, whether the pa= th used for Handshake packets migrates too).

=C2=A0

Without that being clarified, can we say that we are= ready for a consensus=C2=A0call?

=C2=A0


On that basis, I think that it would be best if we open a new issue that sa= ys "Handshake keys can't ever be dropped".=C2=A0

We might still conclude not to address that issue, but the important thing = is to ensure that any solution works properly.


=C2=A0

--

Kazuho Oku

--000000000000c84cbf0595bebf4d-- From nobody Fri Oct 25 09:42:09 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B897120219 for ; Fri, 25 Oct 2019 09:42:07 -0700 (PDT) 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, 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 (1024-bit key) header.d=fb.com header.b=RgGRPPSD; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=UpvySTLP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRleNoQp4qxq for ; Fri, 25 Oct 2019 09:42:05 -0700 (PDT) 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 09E77120843 for ; Fri, 25 Oct 2019 09:42:04 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.42/8.16.0.42) with SMTP id x9PGfsWl024447; Fri, 25 Oct 2019 09:41:57 -0700 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=Q+I1t9WB1bFKlCrThNJng5PP5XbyI1In5YIK9XU/tmQ=; b=RgGRPPSDLWA6s5gSdm5kQx4jmKXHVsnrgzk9UNKeXvTrNzY4N8BRv9IhpE/l+X0H8j5P VKNtpDyf0j1/9xna2Zse+U1klgk9CUxNiqDOUgLbNFeUpC4sYm2PpwKdRBkQORJTiYnL atKdrWR6d+j+IdA99xk2tQz+GFhVQu6H8xk= Received: from maileast.thefacebook.com ([163.114.130.16]) by m0001303.ppops.net with ESMTP id 2vuy22sq8p-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 25 Oct 2019 09:41:56 -0700 Received: from ash-exhub101.TheFacebook.com (2620:10d:c0a8:82::e) by ash-exhub104.TheFacebook.com (2620:10d:c0a8:82::d) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 25 Oct 2019 09:41:37 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.35.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Fri, 25 Oct 2019 09:41:37 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q4SnMfQ6J+D6hkHiQg/4teykD/+EYGyi0RwicNamT8Y1e1+HqfsgZN/8TU0Cq2fqYiDV4Yf8A1wR0vZ2lYEIHl2k4irb8KQ084trJC2suiSbn6W6XXjnH8kmZ1ybJpfC+0lQvZfKHTBx6JX/6p9HvI7uikNTRgDlG3My3WbDv5lxhMU8k3MtcYprRNqVWLBIodgAP6smu9pR67tiFqyq9OPTfbnpw/TU7QXjmWK+nlIk5PEM7QXmpNsTASDXAB2qbBChPVjKNSHgq9mSeXxeOAOwbTBhnzka6plOuqdSxODC0ppiH+b2XpbGViCxAeQVxg9OrY/GiXbf8Y5dh1lXRw== 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=Q+I1t9WB1bFKlCrThNJng5PP5XbyI1In5YIK9XU/tmQ=; b=FgMqJ9yap9Ke14DFNgXRAQIQ+ms+Dom9on7ZUHhEiqIHqTB3luSoKUs6yR8ITVc51AIHNgv9iZrL8NQyMsk+arM5vrz7iQxuAJc8VZP0R0kkWljqUEQAcU06KFo+zLcilV7Y8levppMCA84x83NsbriYg3DkFUE04WomRQhD5tsF3Masn7RR5kozwkhZ6O4bDFCv3icqsgJR1h32zUJREXfusJEj9y+5+mNrE5cyoPOtp7g2odz2NdHbKXcNHxO0XWXkV2B2a5pDwHouQDaVC1Fc8GY7kexZB/u5iSp9p2BuvE3cAcMxZP//cU/VWQoLLqghoXgz/EwK8C1QZ8gDtQ== 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=Q+I1t9WB1bFKlCrThNJng5PP5XbyI1In5YIK9XU/tmQ=; b=UpvySTLPVogWoEIKmr8pJ2E9EDMJa3sJ9odRY5Bsmg4MSRzyFEvF2lHTPfD6OCNOSDFOtCG4DaqRYQlPq0lT3cA4tZh9j1FyAEHgzbahGFisHnYaSUEbwWqsObmPuCLKmpkewknukr8pvKS7S/YWJbVwsBGNuEAKfuTJri/2Uvk= Received: from CY4PR15MB1542.namprd15.prod.outlook.com (10.172.160.9) by CY4PR15MB1832.namprd15.prod.outlook.com (10.174.54.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.22; Fri, 25 Oct 2019 16:41:36 +0000 Received: from CY4PR15MB1542.namprd15.prod.outlook.com ([fe80::402f:bad9:499:3990]) by CY4PR15MB1542.namprd15.prod.outlook.com ([fe80::402f:bad9:499:3990%7]) with mapi id 15.20.2387.023; Fri, 25 Oct 2019 16:41:36 +0000 From: Roberto Peon To: Mirja Kuehlewind , Christian Huitema , David Schinazi , Martin Thomson CC: QUIC Subject: Re: Making QUIC less constraining for innovation Thread-Topic: Making QUIC less constraining for innovation Thread-Index: AQHVihr1cM/+CX/2UE69WExhGw4ztqdpNBgAgAANYACAAAWDAIAADFuAgADS/ACAAFojAIAARmmAgAAgxQCAAGDygP//0/2A Date: Fri, 25 Oct 2019 16:41:35 +0000 Message-ID: References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> In-Reply-To: <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-originating-ip: [2620:10d:c090:200::dee6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 639e4ded-49aa-48f4-901e-08d7596a33da x-ms-traffictypediagnostic: CY4PR15MB1832: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02015246A9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(396003)(366004)(39860400002)(376002)(53754006)(51444003)(189003)(199004)(2906002)(14454004)(110136005)(99286004)(86362001)(606006)(54896002)(236005)(6512007)(229853002)(561944003)(6306002)(33656002)(36756003)(91956017)(76116006)(66476007)(66946007)(6486002)(6116002)(66446008)(66556008)(64756008)(6436002)(7736002)(25786009)(5660300002)(4326008)(8936002)(58126008)(316002)(71200400001)(76176011)(102836004)(256004)(46003)(186003)(6506007)(2616005)(53546011)(14444005)(486006)(446003)(11346002)(81156014)(478600001)(81166006)(8676002)(71190400001)(476003)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1832; H:CY4PR15MB1542.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: OEfjMqjnoO7T3eWxPTqM33Lak7HLnX7q/F8Jw+iZNBXcjbYRNbsdKy+OIKK8gkC/72Nl9Rm38o0y6ixPGgJXrV0SnbI6ZzWCsxT/dgqZEeSdBIv9JfmdgQ+XpMBaO2dc9ElJNyS3mugYMLqPFkuRpNb1jFnvj73id3/Kvz5hwnNV/dVDiezGT/XaS9C/5Cj+Z/z1ZRUyGHlJMRhfm7ATF5BY277ZpZghLDQtepPMiIuGxhDslP3xdxswgD0Vt3tTOLPvfszgOQwvJ0l85KAeOlZrnOx3hkaZYwf6bnUaAgCPKAbO5pyDczaNFHs3PnwEnxa85OvaiTGPpfs6qPT86F0hsVUqlYWHx6mkcB844dU6zeq/eaXg83GNhzxEHr6r0YHwotOkUTivC6ljIsN3hTs04B6fOq713aptI5rQkt5ztCgmMl4tT8tEQQRED8Ybb0ke5naOHafwhKrXnoG8MGm/VDA0PfCfOLHV0MV+LxM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AA3FE762639A41AFBB9F5604AD82CDBBfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 639e4ded-49aa-48f4-901e-08d7596a33da X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2019 16:41:36.6112 (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: XCJN8qntAAUWEESn6AFac41vaBDK7dUHb+6psk2p1yuKz1N9MDxuYqC1vI1j6NEK X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1832 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-25_08:2019-10-25,2019-10-25 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 adultscore=0 clxscore=1011 impostorscore=0 phishscore=0 lowpriorityscore=0 mlxscore=0 bulkscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910250153 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: Fri, 25 Oct 2019 16:42:07 -0000 --_000_AA3FE762639A41AFBB9F5604AD82CDBBfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUg4oCcYeKAnTogTXkgc3VzcGljaW9uIGlzIHRoYXQgaWYgaXQgaGFzIHRvIGJlIHJlZ2lzdGVy ZWQsIGl0IHdvbuKAmXQgYmUgcHJpdmF0ZS0tIGlmIGl0IGlzIGluIGFuIGltcGxlbWVudGF0aW9u IHRoYXQgaXMgaW50ZXJvcGVyYXRpbmcgYnJvYWRseSB3aXRoIG90aGVycywgaXQgd29u4oCZdCBy ZW1haW4gcHJpdmF0ZS4NCi09Ug0KDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiBNaXJqYSBLdWVobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kPTQwZXJpY3Nz b24uY29tQGRtYXJjLmlldGYub3JnPg0KRGF0ZTogRnJpZGF5LCBPY3RvYmVyIDI1LCAyMDE5IGF0 IDU6MTkgQU0NClRvOiBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4sIERh dmlkIFNjaGluYXppIDxkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+LCBNYXJ0aW4gVGhvbXNvbiA8 bXRAbG93ZW50cm9weS5uZXQ+DQpDYzogUVVJQyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBNYWtpbmcgUVVJQyBsZXNzIGNvbnN0cmFpbmluZyBmb3IgaW5ub3ZhdGlvbg0KDQpIaSBNYXJ0 aW4sIGhpIGFsbCwNCg0KanVzdCByZXBseWluZyB0byB0aGUgbGFzdCBtYWlsIGluIHRoaXMgdGhy ZWFkLCBidXQgSSBoYXZlIHR3byBwb2ludHMgKHdoaWNoIHRvIHNvbWUgZXh0ZW5kIG1heSByZWxh dGUgdG8gb3RoZXIgcG9pbnRzIGFscmVhZHkgbWFkZSk6DQoNCg0KICAxLiAgUHJpdmF0ZSB1c2U6 IERhdmlkIHNhaWQgc29tZXRoaW5nIHRoYXQgaGUgc3RpbGwgd291bGQgbGlrZSBwcml2YXRlIHVz ZSBmb3IgY2FzZXMgd2hlcmUgc29tZW9uZSBkb27igJl0IHdhbnQgdG8gcmV2ZWFsIGFueXRoaW5n ICg/KS4gSSB0aGluayBqdXN0IHJlZ2lzdGVyaW5nIGEgY29kZXBvaW50IHdpdGggYSByYW5kb20g bmFtZSBhbmQgd2l0aG91dCBhbnkgZG9jdW1lbnRhdGlvbiB3b3VsZG7igJl0IGFjdHVhbGx5IHJl dmVhbCBhbnl0aGluZyBidXQgc3RpbGwgaGVscHMgdGhlIHJlcXVlc3RlciAgdGhhdCBub2JvZHkg ZWxzZSB3aWxsIGV2ZXJ5IHVzZSB0aGUgc2FtZSBjb2RlIGZvciBhIGRpZmZlcmVudCBwYXJhbWV0 ZXIgaW4gZnV0dXJlIHdoaWNoIHdvdWxkIGNhc2UgdGhlIHJlcXVlc3QgdG8gdXBkYXRlIHRoZWly IGNvZGUuIEkgdGhpbmsgdGhhdOKAmXMgZXhhY3RseSB0aGUgcG9pbnQgb2YgdGhlIHJlZ2lzdHJ5 LiBIb3dldmVyLCBJIHdvdWxkIHN0aWxsIGxpa2UgdG8gcmVzZXJ2ZSBvbmUgb3IgdHdvIGNvZGVw b2ludHMgZm9yIChwcml2YXRlKSBleHBlcmltZW50YXRpb24uIFRoYXTigJlzIGJhc2ljYWxseSB0 aGUgY29kZXBvaW50IHlvdSB3b3VsZCB1c2UgaW4geW91ciBpbml0aWFsIGltcGxlbWVudGF0aW9u IGZvciB5b3VyIGluaXRpYWwgdGVzdGluZyBiZWNhdXNlIHNvbWV0aGluZyB0aGVzZSBjb2RlIGZy YWdtZW50IGp1c3QgaGFuZyBhcm91bmQgd2l0aG91dCB1c2FnZSB1bnRpbCBzb21lb25lIHN1ZGRl bmx5IGZpbmRzIGl0IGFuZCB0aGF0IHdvdWxkIGluY3JlYXNlIHRoZSBuZWVkIHRvIGFjdHVhbGx5 IGdvIGFuZCByZWdpc3RlciBpZiB5b3UgcmVhbGx5IHdhbnQgdG8gdXNlIGl0LiBOb3Qgc3VyZSBp ZiBpdCBoZWxwcywgYnV0IEkgd291bGQgbGlrZSB0byB0cnkuDQogIDIuICBJ4oCZbSBhZnJhaWQg dGhhdCBpZiB3ZSBoYXZlIHRoZSBwcm92aXNpb25hbCBGQ0ZTIHRoYXQgdGhlcmUgaXMgYWN0dWFs bHkgbm8gcGVyY2VpdmVkIG5lZWQgYW55IG1vcmUgdG8gbWFrZSBhIHJlYWwgcmVnaXN0cmF0aW9u IGF0IHNvbWUgcG9pbnQuIEFsc28gRkNGUyBpcyB1c3VhbGx5IHdpdGhvdXQgYW55IGV4cGVydCBy ZXZpZXcgYmVjYXVzZSB0aGUgdGFzayBvZiByZW1vdmluZyBqdW5rIG9yIGRvdWJlLWNoZWNraW5n IGlmIHRvbyBtYW55IHJlcXVlc3QgYXJlIHNlbmQgYXQgb25jZSBmcm9tIHRoZSBzYW1lIHBhcnR5 IGlzIHVzdWFsbHkgc29tZXRoaW5nIElBTkEgY2FuIGRvIG9uIGl0cyBvd24uIFNvIEkgd29uZGVy aW5nIGlmIGhhdmluZyBleHBlcnRzIGFuZCBoYXZpbmcgdGhlIFNwZWMgcmVxdWlyZWQgcGFydCBp cyBhY3R1YWxseSB1c2VmdWwsIGlmIHRoaXMgbW9kZWwgd2lsbCBlbmQgdXAgYW55d2F5IHN1Y2gg dGhhdCBldmVyeWJvZHkgY2FuIGdldCBhIHJlZ2lzdHJhdGlvbiBubyBtYXR0ZXIgd2hhdC4gT24g dGhlIG90aGVyIGhhbmQgaXQgd291bGQgYmUgbmljZSB0byBwcm92aWRlIGFuIGluY2VudGl2ZSB0 byBhbHNvIHByb3ZpZGUgYSBwb2ludGVyIHRvIGEgc3BlYyAod2hpY2ggYnR3IGRvZXMgbm90IGhh dmUgdG8gYmUgYW4gSS1EKSwgaG93ZXZlciwgSSBkb27igJl0IHNlZSB0aGF0IHRoZSBkaWZmZXJl bmNlIGJldHdlZW4gYSB0aGVvcmV0aWNhbCBwZXJtYW5lbnQgb3Ig4oCcb25seeKAnSBwcm92aXNp b25hbCByZWdpc3RyYXRpb24gd2lsbCBwcm92aWRlIHRoaXMgaW5jZW50aXZlLiBNeSBndWVzcyBp cyByYXRoZXIgdGhhdCBpZiB3ZSBoYXZlIGEgZmllbGQgZm9yIGEgcmVmZXJlbmNlIGxpbmsgaW4g dGhlIHJlZ2lzdHJ5IHRoYXQgcGVvcGxlIHdpbGwgcHJvdmlkZSB0aGF0IHBvaW50ZXIgYW55d2F5 IGlmIGF2YWlsYWJsZS4NCg0KTWlyamENCg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+ DQpEYXRlOiBGcmlkYXksIDI1LiBPY3RvYmVyIDIwMTkgYXQgMDg6MzkNClRvOiBEYXZpZCBTY2hp bmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPiwgTWFydGluIFRob21zb24gPG10QGxvd2Vu dHJvcHkubmV0Pg0KQ2M6IFFVSUMgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogTWFraW5n IFFVSUMgbGVzcyBjb25zdHJhaW5pbmcgZm9yIGlubm92YXRpb24NCg0KDQoNCk9uIDEwLzI0LzIw MTkgOTozNCBQTSwgRGF2aWQgU2NoaW5hemkgd3JvdGU6DQpbMC02M10gU3RhbmRhcmRzIEFjdGlv bjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rv b2xzLmlldGYub3JnX2h0bWxfcmZjODEyNi0yM3NlY3Rpb24tMkQ0LjkmZD1Ed01HYVEmYz01VkQw UlR0TmxUaDN5Y2Q0MWIzTVV3JnI9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZtPUtxNmF3cFdKdUVR ZFlrV0Ryc0YzZ25vVXNtVkNudUY2cWdWVkxpZEN6TGcmcz1iOFFkUDlSYVZBdTdNbDZpUHdrd1dV cjhFbjdPRDNidW9aQzVpWDZKc1NjJmU9PiBvciBJRVNHIEFwcHJvdmFsPGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRt bF9yZmM4MTI2LTIzc2VjdGlvbi0yRDQuMTAmZD1Ed01HYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIz TVV3JnI9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZtPUtxNmF3cFdKdUVRZFlrV0Ryc0YzZ25vVXNt VkNudUY2cWdWVkxpZEN6TGcmcz02Sm9jempzdWpLaWZTTGxZbXFUSXF1NEpvOE9IWVdTeGZhQVpO MlRhT1RBJmU9Pg0KICAgIFRoaXMgZ2l2ZXMgdGhlIElFVEYgYSBsaXR0bGUgcHJvdGVjdGVkIGdh cmRlbiBhbmQgdGhhdCBtZWFucyB0aGF0IGZvbGtzIGRldmVsb3BpbmcNCiAgICBleHRlbnNpb25z IGFuZCBleHBlcmltZW50cyB3b24ndCB1c2UgdGhlIG5leHQgYXZhaWxhYmxlIHZhbHVlIGZyb20g aGVyZS4NCg0KWzY0LTE2MzgzXSBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkPGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRt bF9yZmM4MTI2LTIzc2VjdGlvbi0yRDQuNiZkPUR3TUdhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNN VXcmcj1DMHNVby1MRk5CYVlmeW9hQ3NmNlRBJm09S3E2YXdwV0p1RVFkWWtXRHJzRjNnbm9Vc21W Q251RjZxZ1ZWTGlkQ3pMZyZzPWVNNUVPb2VvYmNkQ3YzYTJpZlJNRDg0WUc2Yk0teWFKdHdrOXl6 WEdDdGcmZT0+DQogICAgVGhpcyBjcmVhdGVzIGEgY2FydmVvdXQgd2l0aCBhbiBpbnRlbnRpb25h bCBvdmVyaGVhZCBvZiByZXF1aXJpbmcgd3JpdGluZyBhIGRyYWZ0Lg0KICAgIFRoaXMgZW5zdXJl cyB0aGF0IHdlJ2xsIG5ldmVyIHJ1biBvdXQgb2YgdGhpcyBzcGFjZS4gRXhwZXJpbWVudGFsIFJG Q3Mgd291bGQNCiAgICB1c2UgdGhpcyByZWdpc3RyeS4NCg0KWzE2Mzg0K10gRmlyc3QgQ29tZSBG aXJzdCBTZXJ2ZTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjODEyNi0yM3NlY3Rpb24tMkQ0LjQmZD1Ed01H YVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZtPUtx NmF3cFdKdUVRZFlrV0Ryc0YzZ25vVXNtVkNudUY2cWdWVkxpZEN6TGcmcz1veUFwemNmY2FFUmt1 enJzdExvOV9vYllRNDJNSXpkbmg0OXdhLVl6bnlRJmU9Pg0KICAgIFRoaXMgYWxsb3dzIGFueW9u ZSB0byByZXF1ZXN0IGEgY29kZS1wb2ludCBhbmQgcmVnaXN0ZXIgaXQgd2l0aG91dCBvdmVyaGVh ZCwNCiAgICBhcyBJQU5BIGRvZXMgbm90IHJldmlldyB0aGUgcmVxdWVzdC4gVGhpcyBtZWFucyB0 aGF0IHdlIGNhbiB1c2UgdGhlIHJlZ2lzdHJ5DQogICAgc2ltcGx5IGFzIGEgY29sbGlzaW9uLWF2 b2lkYW5jZSBtZWNoYW5pc20uDQoNCldlIHNob3VsZCBzdHJvbmdseSBlbmNvdXJhZ2UgY3VzdG9t ZXJzIG9mIHRoZSBbNjQrXSByZWdpc3RyaWVzIHRvIGdlbmVyYXRlDQp0aGVpciBkZXNpcmVkIGNv ZGVwb2ludCByYW5kb21seS4NCg0KSSBhZ3JlZSB3aXRoIHJlbW92aW5nIFByaXZhdGUgVXNlPGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMu aWV0Zi5vcmdfaHRtbF9yZmM4MTI2LTIzc2VjdGlvbi0yRDQuMSZkPUR3TUdhUSZjPTVWRDBSVHRO bFRoM3ljZDQxYjNNVXcmcj1DMHNVby1MRk5CYVlmeW9hQ3NmNlRBJm09S3E2YXdwV0p1RVFkWWtX RHJzRjNnbm9Vc21WQ251RjZxZ1ZWTGlkQ3pMZyZzPWZXMUJGaFVqdHlsZFM5alIwTHVHb0NmU2xa YzNSZVJQMGYwVmlCWXJOR3MmZT0+IGZvciB0aGUgcmVhc29ucyBzdGF0ZWQgYnkgb3RoZXJzLCBi dXQgSSBkbyB0aGluaw0KdGhhdCBpZiBzb21lb25lIHdhbnRzIHRvIGJ1aWxkIGEgcHJvcHJpZXRh cnkgZXh0ZW5zaW9uLCB0aGV5IHNob3VsZCBiZSBhYmxlIHRvDQpkbyBzbyB3aXRob3V0IGhhdmlu ZyB0byBkb2N1bWVudCBpdCBwdWJsaWNseSAtIGJlY2F1c2UgaW4gcmVhbGl0eSBwZW9wbGUgd2ls bA0KYmUgYnVpbGRpbmcgdW5kb2N1bWVudGVkIHByb3ByaWV0YXJ5IGV4dGVuc2lvbnMsIHNvIHdl IGNhbiBlaXRoZXIgZ2l2ZSB0aGVtDQphIHBhcnQgb2YgdGhlIHJlZ2lzdHJ5IHRoYXQgd29ya3Mg Zm9yIHRoZW0sIG9yIHRoZXknbGwgcmVzb3J0IHRvIHNxdWF0dGluZy4gQW5kDQpJIHRoaW5rIEZp cnN0IENvbWUgRmlyc3QgU2VydmU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLi5vcmdfaHRtbF9yZmM4MTI2LTIzc2VjdGlvbi0y RDQuNCZkPUR3TUdhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1DMHNVby1MRk5CYVlmeW9h Q3NmNlRBJm09S3E2YXdwV0p1RVFkWWtXRHJzRjNnbm9Vc21WQ251RjZxZ1ZWTGlkQ3pMZyZzPVpS SmMyWmU0TENxUjZzeFQ3QnE0UHk4aDl2WHRNNXo1VmhoRHpCNmxtUDQmZT0+IHdpbGwgZ2V0IHVz IHdoYXQgd2Ugd2FudCBoZXJlLiBJIGRvbid0IHRoaW5rDQpQcm92aXNpb25hbCBSZWdpc3RyYXRp b25zPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f dG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM4MTI2LTIzc2VjdGlvbi0yRDQuMTMmZD1Ed01HYVEmYz01 VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZtPUtxNmF3cFdK dUVRZFlrV0Ryc0YzZ25vVXNtVkNudUY2cWdWVkxpZEN6TGcmcz0xaHdFaG42bTlxZnpTaks2ZHVy cWR5N3EtQjBvLWg5QVFTd2dMSEVsd0xrJmU9PiBmaXQgdGhlIGJpbGwgaGVyZSBiZWNhdXNlIHRo ZXNlIHByb3ByaWV0YXJ5IGV4dGVuc2lvbnMNCmhhdmUgbm8gcmVhc29uIHRvIGJlIHRpbWUtbGlt aXRlZC4NCg0KDQoNCkkgdGhpbmsgSSBsaWtlIE1hcnRpbidzIHByb3Bvc2FsIGJldHRlci4gTXkg cmVhc29uaW5nIGlzIHRoYXQgdGhlcmUgaXMgbm8gcHJhY3RpY2FsIGRpZmZlcmVuY2UgYmV0d2Vl biB0aGUgbnVtYmVycyBhcyBsb25nIGFzIFRQIGFyZSBlbmNvZGVkIG9uIDE2IGJpdHMsIGFuZCBJ IGhhdmUgYSBoYXJkIHRpbWUgYmVsaWV2aW5nIHRoYXQgYW55IElBTkEgcmVnaXN0cnkgY291bGQg ZWZmaWNpZW50bHkgbWFuYWdlIG1vcmUgdGhhbiBhIGZldyB0aG91c2FuZCBjb2RlIHBvaW50cy4g UGx1cyBzcGVjaWZpY2F0aW9uIHJlcXVpcmVkIGlzIHJlYWxseSBuaWNlIGZvciB0aGUgY29tbXVu aXR5Lg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0K --_000_AA3FE762639A41AFBB9F5604AD82CDBBfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <0D98EA8301CE6346940ACE3D50B0DA72@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDU2LjdwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6MTAxODEwNTY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDI5NTUw NTYyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTI5 MTIwNzU4NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTE1MTg5NzU4NTQgMTM0ODA3NTc1IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgw NzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1Nzk7fQ0KQGxpc3QgbDE6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UmUg4oCcYeKAnTogTXkgc3VzcGljaW9uIGlzIHRoYXQgaWYgaXQgaGFz IHRvIGJlIHJlZ2lzdGVyZWQsIGl0IHdvbuKAmXQgYmUgcHJpdmF0ZS0tIGlmIGl0IGlzIGluIGFu IGltcGxlbWVudGF0aW9uIHRoYXQgaXMgaW50ZXJvcGVyYXRpbmcgYnJvYWRseSB3aXRoIG90aGVy cywgaXQgd29u4oCZdCByZW1haW4gcHJpdmF0ZS48YnI+DQotPVI8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlFVSUMgJmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZn dDsgb24gYmVoYWxmIG9mIE1pcmphIEt1ZWhsZXdpbmQgJmx0O21pcmphLmt1ZWhsZXdpbmQ9NDBl cmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwg T2N0b2JlciAyNSwgMjAxOSBhdCA1OjE5IEFNPGJyPg0KPGI+VG86IDwvYj5DaHJpc3RpYW4gSHVp dGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDssIERhdmlkIFNjaGluYXppICZsdDtkc2No aW5hemkuaWV0ZkBnbWFpbC5jb20mZ3Q7LCBNYXJ0aW4gVGhvbXNvbiAmbHQ7bXRAbG93ZW50cm9w eS5uZXQmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5RVUlDICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SZTogTWFraW5nIFFVSUMgbGVzcyBjb25zdHJhaW5pbmcgZm9yIGlu bm92YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGkgTWFydGluLCBoaSBhbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmp1c3QgcmVw bHlpbmcgdG8gdGhlIGxhc3QgbWFpbCBpbiB0aGlzIHRocmVhZCwgYnV0IEkgaGF2ZSB0d28gcG9p bnRzICh3aGljaCB0byBzb21lIGV4dGVuZCBtYXkgcmVsYXRlIHRvIG90aGVyIHBvaW50cyBhbHJl YWR5IG1hZGUpOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0i YSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPlByaXZhdGUgdXNlOiBEYXZpZCBzYWlkIHNvbWV0aGlu ZyB0aGF0IGhlIHN0aWxsIHdvdWxkIGxpa2UgcHJpdmF0ZSB1c2UgZm9yIGNhc2VzIHdoZXJlIHNv bWVvbmUgZG9u4oCZdCB3YW50IHRvIHJldmVhbCBhbnl0aGluZyAoPykuIEkgdGhpbmsganVzdCBy ZWdpc3RlcmluZyBhIGNvZGVwb2ludCB3aXRoIGEgcmFuZG9tDQogbmFtZSBhbmQgd2l0aG91dCBh bnkgZG9jdW1lbnRhdGlvbiB3b3VsZG7igJl0IGFjdHVhbGx5IHJldmVhbCBhbnl0aGluZyBidXQg c3RpbGwgaGVscHMgdGhlIHJlcXVlc3RlciAmbmJzcDt0aGF0IG5vYm9keSBlbHNlIHdpbGwgZXZl cnkgdXNlIHRoZSBzYW1lIGNvZGUgZm9yIGEgZGlmZmVyZW50IHBhcmFtZXRlciBpbiBmdXR1cmUg d2hpY2ggd291bGQgY2FzZSB0aGUgcmVxdWVzdCB0byB1cGRhdGUgdGhlaXIgY29kZS4gSSB0aGlu ayB0aGF04oCZcyBleGFjdGx5DQogdGhlIHBvaW50IG9mIHRoZSByZWdpc3RyeS4gSG93ZXZlciwg SSB3b3VsZCBzdGlsbCBsaWtlIHRvIHJlc2VydmUgb25lIG9yIHR3byBjb2RlcG9pbnRzIGZvciAo cHJpdmF0ZSkgZXhwZXJpbWVudGF0aW9uLiBUaGF04oCZcyBiYXNpY2FsbHkgdGhlIGNvZGVwb2lu dCB5b3Ugd291bGQgdXNlIGluIHlvdXIgaW5pdGlhbCBpbXBsZW1lbnRhdGlvbiBmb3IgeW91ciBp bml0aWFsIHRlc3RpbmcgYmVjYXVzZSBzb21ldGhpbmcgdGhlc2UgY29kZSBmcmFnbWVudA0KIGp1 c3QgaGFuZyBhcm91bmQgd2l0aG91dCB1c2FnZSB1bnRpbCBzb21lb25lIHN1ZGRlbmx5IGZpbmRz IGl0IGFuZCB0aGF0IHdvdWxkIGluY3JlYXNlIHRoZSBuZWVkIHRvIGFjdHVhbGx5IGdvIGFuZCBy ZWdpc3RlciBpZiB5b3UgcmVhbGx5IHdhbnQgdG8gdXNlIGl0LiBOb3Qgc3VyZSBpZiBpdCBoZWxw cywgYnV0IEkgd291bGQgbGlrZSB0byB0cnkuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEg bGZvMyI+SeKAmW0gYWZyYWlkIHRoYXQgaWYgd2UgaGF2ZSB0aGUgcHJvdmlzaW9uYWwgRkNGUyB0 aGF0IHRoZXJlIGlzIGFjdHVhbGx5IG5vIHBlcmNlaXZlZCBuZWVkIGFueSBtb3JlIHRvIG1ha2Ug YSByZWFsIHJlZ2lzdHJhdGlvbiBhdCBzb21lIHBvaW50LiBBbHNvIEZDRlMgaXMgdXN1YWxseSB3 aXRob3V0IGFueSBleHBlcnQNCiByZXZpZXcgYmVjYXVzZSB0aGUgdGFzayBvZiByZW1vdmluZyBq dW5rIG9yIGRvdWJlLWNoZWNraW5nIGlmIHRvbyBtYW55IHJlcXVlc3QgYXJlIHNlbmQgYXQgb25j ZSBmcm9tIHRoZSBzYW1lIHBhcnR5IGlzIHVzdWFsbHkgc29tZXRoaW5nIElBTkEgY2FuIGRvIG9u IGl0cyBvd24uIFNvIEkgd29uZGVyaW5nIGlmIGhhdmluZyBleHBlcnRzIGFuZCBoYXZpbmcgdGhl IFNwZWMgcmVxdWlyZWQgcGFydCBpcyBhY3R1YWxseSB1c2VmdWwsIGlmIHRoaXMNCiBtb2RlbCB3 aWxsIGVuZCB1cCBhbnl3YXkgc3VjaCB0aGF0IGV2ZXJ5Ym9keSBjYW4gZ2V0IGEgcmVnaXN0cmF0 aW9uIG5vIG1hdHRlciB3aGF0LiBPbiB0aGUgb3RoZXIgaGFuZCBpdCB3b3VsZCBiZSBuaWNlIHRv IHByb3ZpZGUgYW4gaW5jZW50aXZlIHRvIGFsc28gcHJvdmlkZSBhIHBvaW50ZXIgdG8gYSBzcGVj ICh3aGljaCBidHcgZG9lcyBub3QgaGF2ZSB0byBiZSBhbiBJLUQpLCBob3dldmVyLCBJIGRvbuKA mXQgc2VlIHRoYXQgdGhlIGRpZmZlcmVuY2UNCiBiZXR3ZWVuIGEgdGhlb3JldGljYWwgcGVybWFu ZW50IG9yIOKAnG9ubHnigJ0gcHJvdmlzaW9uYWwgcmVnaXN0cmF0aW9uIHdpbGwgcHJvdmlkZSB0 aGlzIGluY2VudGl2ZS4gTXkgZ3Vlc3MgaXMgcmF0aGVyIHRoYXQgaWYgd2UgaGF2ZSBhIGZpZWxk IGZvciBhIHJlZmVyZW5jZSBsaW5rIGluIHRoZSByZWdpc3RyeSB0aGF0IHBlb3BsZSB3aWxsIHBy b3ZpZGUgdGhhdCBwb2ludGVyIGFueXdheSBpZiBhdmFpbGFibGUuPG86cD48L286cD48L2xpPjwv b2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk1pcmphPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlFVSUMgJmx0O3F1aWMtYm91bmNlc0BpZXRm Lm9yZyZndDsgb24gYmVoYWxmIG9mIENocmlzdGlhbiBIdWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRl bWEubmV0Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIDI1LiBPY3RvYmVyIDIwMTkgYXQg MDg6Mzk8YnI+DQo8Yj5UbzogPC9iPkRhdmlkIFNjaGluYXppICZsdDtkc2NoaW5hemkuaWV0ZkBn bWFpbC5jb20mZ3Q7LCBNYXJ0aW4gVGhvbXNvbiAmbHQ7bXRAbG93ZW50cm9weS5uZXQmZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5RVUlDICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5SZTogTWFraW5nIFFVSUMgbGVzcyBjb25zdHJhaW5pbmcgZm9yIGlubm92YXRpb248L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gMTAvMjQvMjAx OSA5OjM0IFBNLCBEYXZpZCBTY2hpbmF6aSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlsw LTYzXSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjODEyNi0yM3NlY3Rpb24tMkQ0LjkmYW1w O2Q9RHdNR2FRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9QzBzVW8tTEZOQmFZ ZnlvYUNzZjZUQSZhbXA7bT1LcTZhd3BXSnVFUWRZa1dEcnNGM2dub1VzbVZDbnVGNnFnVlZMaWRD ekxnJmFtcDtzPWI4UWRQOVJhVkF1N01sNmlQd2t3V1VyOEVuN09EM2J1b1pDNWlYNkpzU2MmYW1w O2U9Ij4NClN0YW5kYXJkcyBBY3Rpb248L2E+IG9yIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9y ZmM4MTI2LTIzc2VjdGlvbi0yRDQuMTAmYW1wO2Q9RHdNR2FRJmFtcDtjPTVWRDBSVHRObFRoM3lj ZDQxYjNNVXcmYW1wO3I9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZhbXA7bT1LcTZhd3BXSnVFUWRZ a1dEcnNGM2dub1VzbVZDbnVGNnFnVlZMaWRDekxnJmFtcDtzPTZKb2N6anN1aktpZlNMbFltcVRJ cXU0Sm84T0hZV1N4ZmFBWk4yVGFPVEEmYW1wO2U9Ij4NCklFU0cgQXBwcm92YWw8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7ICZuYnNwOyBUaGlzIGdpdmVzIHRoZSBJRVRGIGEgbGl0dGxl IHByb3RlY3RlZCBnYXJkZW4gYW5kIHRoYXQgbWVhbnMgdGhhdCBmb2xrcyBkZXZlbG9waW5nPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7ICZuYnNwOyBleHRlbnNpb25zIGFuZCBleHBlcmltZW50 cyB3b24ndCB1c2UgdGhlIG5leHQgYXZhaWxhYmxlIHZhbHVlIGZyb20gaGVyZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bNjQtMTYzODNdIDxhIGhyZWY9 Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9v bHMuaWV0Zi5vcmdfaHRtbF9yZmM4MTI2LTIzc2VjdGlvbi0yRDQuNiZhbXA7ZD1Ed01HYVEmYW1w O2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1DMHNVby1MRk5CYVlmeW9hQ3NmNlRBJmFt cDttPUtxNmF3cFdKdUVRZFlrV0Ryc0YzZ25vVXNtVkNudUY2cWdWVkxpZEN6TGcmYW1wO3M9ZU01 RU9vZW9iY2RDdjNhMmlmUk1EODRZRzZiTS15YUp0d2s5eXpYR0N0ZyZhbXA7ZT0iPg0KU3BlY2lm aWNhdGlvbiBSZXF1aXJlZDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgJm5ic3A7IFRo aXMgY3JlYXRlcyBhIGNhcnZlb3V0IHdpdGggYW4gaW50ZW50aW9uYWwgb3ZlcmhlYWQgb2YgcmVx dWlyaW5nIHdyaXRpbmcgYSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgJm5ic3A7 IFRoaXMgZW5zdXJlcyB0aGF0IHdlJ2xsIG5ldmVyIHJ1biBvdXQgb2YgdGhpcyBzcGFjZS4gRXhw ZXJpbWVudGFsIFJGQ3Mgd291bGQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgJm5ic3A7IHVz ZSB0aGlzIHJlZ2lzdHJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPlsxNjM4NCYjNDM7XSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjODEyNi0yM3Nl Y3Rpb24tMkQ0LjQmYW1wO2Q9RHdNR2FRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1w O3I9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZhbXA7bT1LcTZhd3BXSnVFUWRZa1dEcnNGM2dub1Vz bVZDbnVGNnFnVlZMaWRDekxnJmFtcDtzPW95QXB6Y2ZjYUVSa3V6cnN0TG85X29iWVE0Mk1JemRu aDQ5d2EtWXpueVEmYW1wO2U9Ij4NCkZpcnN0IENvbWUgRmlyc3QgU2VydmU8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7ICZuYnNwOyBUaGlzIGFsbG93cyBhbnlvbmUgdG8gcmVxdWVzdCBh IGNvZGUtcG9pbnQgYW5kIHJlZ2lzdGVyIGl0IHdpdGhvdXQgb3ZlcmhlYWQsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7ICZuYnNwOyBhcyBJQU5BIGRvZXMgbm90IHJldmlldyB0aGUgcmVxdWVz dC4gVGhpcyBtZWFucyB0aGF0IHdlIGNhbiB1c2UgdGhlIHJlZ2lzdHJ5PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7ICZuYnNwOyBzaW1wbHkgYXMgYSBjb2xsaXNpb24tYXZvaWRhbmNlIG1lY2hh bmlzbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+V2Ugc2hvdWxkIHN0cm9uZ2x5IGVuY291cmFnZSBjdXN0b21lcnMgb2YgdGhlIFs2NCYjNDM7 XSByZWdpc3RyaWVzIHRvIGdlbmVyYXRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+dGhlaXIgZGVzaXJl ZCBjb2RlcG9pbnQgcmFuZG9tbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5JIGFncmVlIHdpdGggcmVtb3ZpbmcgPGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRm Lm9yZ19odG1sX3JmYzgxMjYtMjNzZWN0aW9uLTJENC4xJmFtcDtkPUR3TUdhUSZhbXA7Yz01VkQw UlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPUMwc1VvLUxGTkJhWWZ5b2FDc2Y2VEEmYW1wO209S3E2 YXdwV0p1RVFkWWtXRHJzRjNnbm9Vc21WQ251RjZxZ1ZWTGlkQ3pMZyZhbXA7cz1mVzFCRmhVanR5 bGRTOWpSMEx1R29DZlNsWmMzUmVSUDBmMFZpQllyTkdzJmFtcDtlPSI+DQpQcml2YXRlIFVzZTwv YT4gZm9yIHRoZSByZWFzb25zIHN0YXRlZCBieSBvdGhlcnMsIGJ1dCBJIGRvIHRoaW5rPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+dGhhdCBpZiBzb21lb25lIHdhbnRzIHRvIGJ1aWxkIGEgcHJvcHJpZXRh cnkgZXh0ZW5zaW9uLCB0aGV5IHNob3VsZCBiZSBhYmxlIHRvPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ ZG8gc28gd2l0aG91dCBoYXZpbmcgdG8gZG9jdW1lbnQgaXQgcHVibGljbHkgLSBiZWNhdXNlIGlu IHJlYWxpdHkgcGVvcGxlIHdpbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5iZSBidWlsZGluZyB1bmRv Y3VtZW50ZWQgcHJvcHJpZXRhcnkgZXh0ZW5zaW9ucywgc28gd2UgY2FuIGVpdGhlciBnaXZlIHRo ZW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5hIHBhcnQgb2YgdGhlIHJlZ2lzdHJ5IHRoYXQgd29ya3Mg Zm9yIHRoZW0sIG9yIHRoZXknbGwgcmVzb3J0IHRvIHNxdWF0dGluZy4gQW5kPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+SSB0aGluayA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYuLm9yZ19odG1sX3JmYzgxMjYtMjNzZWN0 aW9uLTJENC40JmFtcDtkPUR3TUdhUSZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDty PUMwc1VvLUxGTkJhWWZ5b2FDc2Y2VEEmYW1wO209S3E2YXdwV0p1RVFkWWtXRHJzRjNnbm9Vc21W Q251RjZxZ1ZWTGlkQ3pMZyZhbXA7cz1aUkpjMlplNExDcVI2c3hUN0JxNFB5OGg5dlh0TTV6NVZo aER6QjZsbVA0JmFtcDtlPSI+DQpGaXJzdCBDb21lIEZpcnN0IFNlcnZlPC9hPiB3aWxsIGdldCB1 cyB3aGF0IHdlIHdhbnQgaGVyZS4gSSBkb24ndCB0aGluazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM4MTI2LTIzc2VjdGlvbi0yRDQuMTMmYW1wO2Q9RHdN R2FRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9QzBzVW8tTEZOQmFZZnlvYUNz ZjZUQSZhbXA7bT1LcTZhd3BXSnVFUWRZa1dEcnNGM2dub1VzbVZDbnVGNnFnVlZMaWRDekxnJmFt cDtzPTFod0VobjZtOXFmelNqSzZkdXJxZHk3cS1CMG8taDlBUVN3Z0xIRWx3TGsmYW1wO2U9Ij5Q cm92aXNpb25hbA0KIFJlZ2lzdHJhdGlvbnM8L2E+IGZpdCB0aGUgYmlsbCBoZXJlIGJlY2F1c2Ug dGhlc2UgcHJvcHJpZXRhcnkgZXh0ZW5zaW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmhhdmUgbm8g cmVhc29uIHRvIGJlIHRpbWUtbGltaXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgdGhpbmsgSSBsaWtlIE1hcnRpbidzIHBy b3Bvc2FsIGJldHRlci4gTXkgcmVhc29uaW5nIGlzIHRoYXQgdGhlcmUgaXMgbm8gcHJhY3RpY2Fs IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbnVtYmVycyBhcyBsb25nIGFzIFRQIGFyZSBlbmNvZGVk IG9uIDE2IGJpdHMsIGFuZCBJIGhhdmUgYSBoYXJkIHRpbWUgYmVsaWV2aW5nIHRoYXQgYW55IElB TkEgcmVnaXN0cnkgY291bGQgZWZmaWNpZW50bHkgbWFuYWdlDQogbW9yZSB0aGFuIGEgZmV3IHRo b3VzYW5kIGNvZGUgcG9pbnRzLiBQbHVzIHNwZWNpZmljYXRpb24gcmVxdWlyZWQgaXMgcmVhbGx5 IG5pY2UgZm9yIHRoZSBjb21tdW5pdHkuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+LS0gQ2hyaXN0aWFuIEh1aXRlbWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_AA3FE762639A41AFBB9F5604AD82CDBBfbcom_-- From nobody Fri Oct 25 11:42:58 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDE51200DB for ; Fri, 25 Oct 2019 11:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 nEdkFr_ylPZ9 for ; Fri, 25 Oct 2019 11:42:52 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CF712004D for ; Fri, 25 Oct 2019 11:42:52 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id q78so3836931lje.5 for ; Fri, 25 Oct 2019 11:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2dlLCvvDyDS7Ix9EULULGwIDVUTl6nFjTPDwm8E755M=; b=l4N8aljhBtsBYyQDW8q/Q0rrNLccBiKq1FcQ1kza5Pk0CGf6y7C5chDPd0DbhHbDu2 8/qvOWtiZ9k3IHMdXGSq/r1xpqjIznfgAxSxRUD5rfdcHscLTzJHN1HKnLTrX5u/5nSV ILDqkYOaoHTiQsl5CqjpoBg2SZ2NFYn66hlvKEz6bCoTGYC2I2qKpO8iwXiPsHHNfetj lX1cMM+ianfNIZb8dibByxeiaF+UWSuCq0oq69wWQIjeeiMBSn+jpjl+rmVE4ey5dWTf 60106eQfV8VJCgHILKuynEEDgqMwjZl1y9jXDFW16ZHiNgdR8xI6kt12VMdENIML/i2Y dK+Q== 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=2dlLCvvDyDS7Ix9EULULGwIDVUTl6nFjTPDwm8E755M=; b=gZiVsorfOW1ku/sJqpD9/1o39uiOP2+eNvM1xYTtE1jm6Q3Rsu6U7ZqEJV2MpLKq61 6hmWwc6yU/BAiWySSIAdcglXHbrvM4A3TASYNCSn6u2gZnPihOA2XNEelfP2IooceZ3e 5abhG2gX4yCDKrcvzQuCswyXCuez7i/isGdaKqsCR/8zwl6+z6MyyJdX7UdFlAka9XaD 0PTFwL6YQbv8Fhyb+8mX8i5/OUq6xzXpDEx5QNoWqTA/LuDNqmJdtPU1YYOBJzkfwhCj bJ7cE/3IV0kSp4Ulvf46aFH2GfZQ22IdL2411GsP82hXSfchUkjFcw3S8HcjfrZWWTNK Qdcw== X-Gm-Message-State: APjAAAWnNjs8FhuE4PPA2aTMtzkRHbil1+w6/BKxDBK5SEZyA1wq8LEf XMVGKd35mwPo2e8xIuKs7PxkHPGCMexzwmLCAUo= X-Google-Smtp-Source: APXvYqyL7hpeH3SN+Zx5UZjIOy9LGBCJwlzpNGrmbIUXI4zHxgS4M+ordcsQVYhWEP2mrvBKZ5E3Fa/FAMC7H+MPW8o= X-Received: by 2002:a2e:207:: with SMTP id 7mr3421158ljc.198.1572028970025; Fri, 25 Oct 2019 11:42:50 -0700 (PDT) MIME-Version: 1.0 References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> In-Reply-To: From: David Schinazi Date: Fri, 25 Oct 2019 11:42:38 -0700 Message-ID: Subject: Re: Making QUIC less constraining for innovation To: Roberto Peon Cc: Mirja Kuehlewind , Christian Huitema , Martin Thomson , QUIC Content-Type: multipart/alternative; boundary="00000000000055c7b80595c084b4" 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, 25 Oct 2019 18:42:57 -0000 --00000000000055c7b80595c084b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think requiring folks to document their extensions is realistic. In practice, some won't. Now we get to decide if we'd like them to register their codepoints or not. So I see three options: 1) We pick Private Use and have folks pick randomly there and hope to avoid collisions (fine for varints, not quite so sure for 16-bit) 2) We pick First Come First Serve and let folks easily register 3) We add constraints such as Specification Required to the entire space, and accept the fact that these folks will squat on values in the space. I understand the impulse of encouraging folks to document their codepoints, but we have to accept the reality that some won't. On Fri, Oct 25, 2019 at 9:42 AM Roberto Peon wrote: > Re =E2=80=9Ca=E2=80=9D: My suspicion is that if it has to be registered, = it won=E2=80=99t be > private-- if it is in an implementation that is interoperating broadly wi= th > others, it won=E2=80=99t remain private. > -=3DR > > > > *From: *QUIC on behalf of Mirja Kuehlewind > > *Date: *Friday, October 25, 2019 at 5:19 AM > *To: *Christian Huitema , David Schinazi < > dschinazi.ietf@gmail.com>, Martin Thomson > *Cc: *QUIC > *Subject: *Re: Making QUIC less constraining for innovation > > > > Hi Martin, hi all, > > > > just replying to the last mail in this thread, but I have two points > (which to some extend may relate to other points already made): > > > > 1. Private use: David said something that he still would like private > use for cases where someone don=E2=80=99t want to reveal anything (?).= I think just > registering a codepoint with a random name and without any documentati= on > wouldn=E2=80=99t actually reveal anything but still helps the requeste= r that > nobody else will every use the same code for a different parameter in > future which would case the request to update their code. I think that= =E2=80=99s > exactly the point of the registry. However, I would still like to rese= rve > one or two codepoints for (private) experimentation. That=E2=80=99s ba= sically the > codepoint you would use in your initial implementation for your initia= l > testing because something these code fragment just hang around without > usage until someone suddenly finds it and that would increase the need= to > actually go and register if you really want to use it. Not sure if it > helps, but I would like to try. > 2. I=E2=80=99m afraid that if we have the provisional FCFS that there = is > actually no perceived need any more to make a real registration at som= e > point. Also FCFS is usually without any expert review because the task= of > removing junk or doube-checking if too many request are send at once f= rom > the same party is usually something IANA can do on its own. So I wonde= ring > if having experts and having the Spec required part is actually useful= , if > this model will end up anyway such that everybody can get a registrati= on no > matter what. On the other hand it would be nice to provide an incentiv= e to > also provide a pointer to a spec (which btw does not have to be an I-D= ), > however, I don=E2=80=99t see that the difference between a theoretical= permanent or > =E2=80=9Conly=E2=80=9D provisional registration will provide this ince= ntive. My guess is > rather that if we have a field for a reference link in the registry th= at > people will provide that pointer anyway if available. > > > > Mirja > > > > *From: *QUIC on behalf of Christian Huitema < > huitema@huitema.net> > *Date: *Friday, 25. October 2019 at 08:39 > *To: *David Schinazi , Martin Thomson < > mt@lowentropy.net> > *Cc: *QUIC > *Subject: *Re: Making QUIC less constraining for innovation > > > > > > On 10/24/2019 9:34 PM, David Schinazi wrote: > > [0-63] Standards Action > > or IESG Approval > > > This gives the IETF a little protected garden and that means that > folks developing > > extensions and experiments won't use the next available value from > here. > > > > [64-16383] Specification Required > > > This creates a carveout with an intentional overhead of requiring > writing a draft. > > This ensures that we'll never run out of this space. Experimental RFC= s > would > > use this registry. > > > > [16384+] First Come First Serve > > > This allows anyone to request a code-point and register it without > overhead, > > as IANA does not review the request. This means that we can use the > registry > > simply as a collision-avoidance mechanism. > > > > We should strongly encourage customers of the [64+] registries to generat= e > > their desired codepoint randomly. > > > > I agree with removing Private Use > > for the reasons stated by others, but I do think > > that if someone wants to build a proprietary extension, they should be > able to > > do so without having to document it publicly - because in reality people > will > > be building undocumented proprietary extensions, so we can either give th= em > > a part of the registry that works for them, or they'll resort to > squatting. And > > I think First Come First Serve > > will get us what we want here. I don't think > > Provisional Registrations > > fit the bill here because these proprietary extensions > > have no reason to be time-limited. > > > > I think I like Martin's proposal better. My reasoning is that there is no > practical difference between the numbers as long as TP are encoded on 16 > bits, and I have a hard time believing that any IANA registry could > efficiently manage more than a few thousand code points. Plus specificati= on > required is really nice for the community. > > -- Christian Huitema > --00000000000055c7b80595c084b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think requiring folks to document their extens= ions is realistic.
In practice, some won't. Now we get to decide if= we'd like them to register
their codepoints or not. So I see= three options:
1) We pick Private Use and have=C2=A0folks pick r= andomly there and hope to
avoid collisions (fine for varints, not= quite so sure for 16-bit)
2) We pick First Come First Serve and = let folks easily register
3) We add constraints such as Specifica= tion Required to the entire space,
and accept the fact that these= folks will squat on values in the space.

I unders= tand the impulse=C2=A0of encouraging folks to document their codepoints,
but we have to accept the reality that some won't.
<= br>
On Fri,= Oct 25, 2019 at 9:42 AM Roberto Peon <f= enix@fb.com> wrote:

Re =E2=80=9Ca=E2=80=9D: My suspicion is that if it h= as to be registered, it won=E2=80=99t be private-- if it is in an implement= ation that is interoperating broadly with others, it won=E2=80=99t remain p= rivate.
-=3DR

=C2=A0

From: = QUIC <quic-bounces@ietf.org>= ; on behalf of Mirja Kuehlewind <mirja.kuehlewind=3D40ericsson.com@dmarc.ietf.or= g>
Date: Friday, October 25, 2019 at 5:19 AM
To: Christian Huitema <huitema@huitema.net>, David Schinazi <dschinazi.ietf@gmail.com<= /a>>, Martin Thomson <mt@lowentropy.net>
Cc: QUIC <quic= @ietf.org>
Subject: Re: Making QUIC less constraining for innovation<= /u>

=C2=A0

Hi Martin, hi all,

=C2=A0

just replying to the last mail in this thread, but I= have two points (which to some extend may relate to other points already m= ade):

=C2=A0

  1. Private use: David said something that he still would like private= use for cases where someone don=E2=80=99t want to reveal anything (?). I t= hink just registering a codepoint with a random name and without any documentation wouldn=E2=80=99t actually reveal anythi= ng but still helps the requester =C2=A0that nobody else will every use the = same code for a different parameter in future which would case the request = to update their code. I think that=E2=80=99s exactly the point of the registry. However, I would still like to reserve one or t= wo codepoints for (private) experimentation. That=E2=80=99s basically the c= odepoint you would use in your initial implementation for your initial test= ing because something these code fragment just hang around without usage until someone suddenly finds it and that wo= uld increase the need to actually go and register if you really want to use= it. Not sure if it helps, but I would like to try.
  2. I=E2=80=99m afraid that if we have the provisional FCFS that there is a= ctually no perceived need any more to make a real registration at some poin= t. Also FCFS is usually without any expert review because the task of removing junk or doube-checking if too many req= uest are send at once from the same party is usually something IANA can do = on its own. So I wondering if having experts and having the Spec required p= art is actually useful, if this model will end up anyway such that everybody can get a registration no mat= ter what. On the other hand it would be nice to provide an incentive to als= o provide a pointer to a spec (which btw does not have to be an I-D), howev= er, I don=E2=80=99t see that the difference between a theoretical permanent or =E2=80=9Conly=E2=80=9D provisional regi= stration will provide this incentive. My guess is rather that if we have a = field for a reference link in the registry that people will provide that po= inter anyway if available.

=C2=A0

Mirja

=C2=A0

From: QUIC <quic-bounces@ietf.org>= ; on behalf of Christian Huitema <huitema@huitema.net>
Date: Friday, 25. October 2019 at 08:39
To: David Schinazi <dschinazi.ietf@gmail.com>, Martin Thomson <mt@lowentropy.net>=
Cc: QUIC <quic= @ietf.org>
Subject: Re: Making QUIC less constraining for innovation<= /u>

=C2=A0

=C2=A0

On 10/24/2019 9:34 PM, D= avid Schinazi wrote:

=C2=A0 =C2=A0 This gives= the IETF a little protected garden and that means that folks developing=

=C2=A0 =C2=A0 extensions= and experiments won't use the next available value from here.

=C2=A0

=C2=A0 =C2=A0 This creat= es a carveout with an intentional overhead of requiring writing a draft.=

=C2=A0 =C2=A0 This ensur= es that we'll never run out of this space. Experimental RFCs would

=C2=A0 =C2=A0 use this r= egistry.

=C2=A0

=C2=A0 =C2=A0 This allow= s anyone to request a code-point and register it without overhead,

=C2=A0 =C2=A0 as IANA do= es not review the request. This means that we can use the registry

=C2=A0 =C2=A0 simply as = a collision-avoidance mechanism.

=C2=A0

We should strongly encou= rage customers of the [64+] registries to generate

their desired codepoint = randomly.

=C2=A0

I agree with removing Private Use for the reasons stated by others, but I do think<= /u>

that if someone wants to= build a proprietary extension, they should be able to

do so without having to = document it publicly - because in reality people will

be building undocumented= proprietary extensions, so we can either give them

a part of the registry t= hat works for them, or they'll resort to squatting. And

I think First Come First Serve will get us what we want here. I don't think=

Prov= isional Registrations fit the bill here because these proprietary extensions

have no reason to be tim= e-limited.

=C2=A0

I think I like Martin's proposal better.= My reasoning is that there is no practical difference between the numbers = as long as TP are encoded on 16 bits, and I have a hard time believing that= any IANA registry could efficiently manage more than a few thousand code points. Plus specification required is reall= y nice for the community.

-- Christian Huitema

--00000000000055c7b80595c084b4-- From nobody Fri Oct 25 11:47:23 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83E412011B for ; Fri, 25 Oct 2019 11:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, 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 8d8PoX177f1U for ; Fri, 25 Oct 2019 11:47:20 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 E0A0A12004D for ; Fri, 25 Oct 2019 11:47:20 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9PIlArp000649; Fri, 25 Oct 2019 19:47:17 +0100 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=BTxdnRFtJ4C+5OiNCWtP9QD/BaIkqpLB0OdJpzhvvtU=; b=jtT14ZvUNnKH5rBcDQijV3nkPdb3ZGwcsPsnARMx4CRpGhWvmPzPflywc+kPawp7Mc5R e/REfCrZX/Dyc9J+Bf27vd9NKnjYOVvszsytbZTy3uek/duOkE/ZolnV0lef92O4eMe5 cg3AtWJO2noEnJfzxq8uC95hIJBhaWVNGtYyt0wqemOxOkEp7q+eZhTbX2obVuLDJTF2 BCnWJ/lgZV/aHIfttY+fPDX0dZZNAgIs56j8J4fCpaEFDvatlBcxGP72QstUhJV0sEaC ToDEvoctW6ZqgYSdxMPnZc9qodJw7KoJqcKeDW3chkL8CZOfnjzYuCEoP5K45HABjONK hw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2vqt14gggg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Oct 2019 19:47:17 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9PIl0rq022837; Fri, 25 Oct 2019 14:47:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2vqwtx53rk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 25 Oct 2019 14:47:16 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 14:47:15 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 14:47:15 -0400 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; Fri, 25 Oct 2019 14:47:15 -0400 From: "Salz, Rich" To: David Schinazi , Roberto Peon CC: Mirja Kuehlewind , QUIC , Christian Huitema , Martin Thomson Subject: Re: Making QUIC less constraining for innovation Thread-Topic: Making QUIC less constraining for innovation Thread-Index: AQHVihr0wKOBWmevhU2YcAoLtno5GKdpdyYAgAANYACAAAWDAIAADFuAgADS/QCAAFoiAIAARmmAgAAgxQCAAGDygIAASVWAgAAh0wD//746AA== Date: Fri, 25 Oct 2019 18:47:14 +0000 Message-ID: References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.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.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.81.209] Content-Type: multipart/alternative; boundary="_000_D69CBF00E9E94B70AA1F91FBDCED382Fakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-25_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=635 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910250169 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-25_09:2019-10-25,2019-10-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 mlxlogscore=623 spamscore=0 lowpriorityscore=0 phishscore=0 suspectscore=0 malwarescore=0 impostorscore=0 priorityscore=1501 mlxscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910250169 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, 25 Oct 2019 18:47:22 -0000 --_000_D69CBF00E9E94B70AA1F91FBDCED382Fakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSB1bmRlcnN0YW5kIHRoZSBpbXB1bHNlIG9mIGVuY291cmFnaW5nIGZvbGtzIHRvIGRv Y3VtZW50IHRoZWlyIGNvZGVwb2ludHMsDQpidXQgd2UgaGF2ZSB0byBhY2NlcHQgdGhlIHJlYWxp dHkgdGhhdCBzb21lIHdvbid0Lg0KDQpBbmQgd2hhdCBoYXBwZW5zIGlmIHNvPyAgVGhhdOKAmXMg YSBzZXJpb3VzIHF1ZXN0aW9uLCBub3QgIGZsaXBwYW50IG9uZS4NCg0K --_000_D69CBF00E9E94B70AA1F91FBDCED382Fakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <4FB9939BA370534DBB978FDEF03B1D2F@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tODEwMzIwNDE5MDgwOTE5MjEz OW1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW04MTAzMjA0MTkwODA5MTkyMTM5bXNvbGlzdHBh cmFncmFwaCwgZGl2LmdtYWlsLW04MTAzMjA0MTkwODA5MTkyMTM5bXNvbGlzdHBhcmFncmFwaA0K CXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXzgxMDMyMDQxOTA4MDkxOTIxMzltc29saXN0cGFyYWdy YXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0NDkxNDIxODsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjEyMTI3OTg4NDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDox LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEyNTQ3NzUxNDY7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05OTk5NDQxMzAgLTYxNDcyMTQ0NCA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBsMTps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omwx IGxldmVsMSBsZm8yIj5JIHVuZGVyc3RhbmQgdGhlIGltcHVsc2UmbmJzcDtvZiBlbmNvdXJhZ2lu ZyBmb2xrcyB0byBkb2N1bWVudCB0aGVpciBjb2RlcG9pbnRzLDxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCB3ZSBoYXZlIHRvIGFjY2VwdCB0aGUg cmVhbGl0eSB0aGF0IHNvbWUgd29uJ3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB3aGF0 IGhhcHBlbnMgaWYgc28/Jm5ic3A7IFRoYXTigJlzIGEgc2VyaW91cyBxdWVzdGlvbiwgbm90Jm5i c3A7IGZsaXBwYW50IG9uZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D69CBF00E9E94B70AA1F91FBDCED382Fakamaicom_-- From nobody Fri Oct 25 11:55:38 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548F612011C for ; Fri, 25 Oct 2019 11:55:36 -0700 (PDT) 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=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 XAvojBYkYW4Z for ; Fri, 25 Oct 2019 11:55:34 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 AF9D412004D for ; Fri, 25 Oct 2019 11:55:33 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id v24so2589476lfe.10 for ; Fri, 25 Oct 2019 11:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=60jJhg6qIC/GwA6FN8s9OFmNKg5LDKflprb6LRJt0oI=; b=bGKYC6xk5tinel7zyMZ+P9Uv+g2qEVeZAzaD24tz0GoaesaMc2IHLzLw4B9d1QSR1W 9lDCVlHhlN1APPsY7W+aZG4jVR7ZhvG6chGUC+TC1ZNjS+vdY8SYAhKykyX8x4bUICPF Bt4bSvlykyU0I/FEXMFHYWPdwyYCHq4ZAuJS918CSHR8D2vZwAGSXQ+8maS0c5j8enX+ VbSCF9J1r9w7Bmq5PXmRxsxLjqUdo10oAxLlix4xvju/EG+vGXeoQHiD1aIl0Z7kJKRF gF4hOXuhXsphqQnNfXEd8n4Ugp6QcKCiTCR0kz8+2OizJIWe7xl9f9B8v3lvEMzxDRWm iSiw== 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=60jJhg6qIC/GwA6FN8s9OFmNKg5LDKflprb6LRJt0oI=; b=iNAes/JvGynN0/oSqEBmEO+Holk33xWmOCEBTVcWKWkG1Q6FaQh0vyM8dBklbknmqS VsvBEBAHkzw3HLwS3p8dBCXALpZ638nKAaYrTul/2XtmP4iu8TnkDa32K4zBl++QdNnW js4N6SdZ4dwL5p62+A3XPiw4Dp6+fdHGVfKJKmeGqxcmPhEFqdkiAUMd4vRc/hTcNGrs 0vplH3knaaWnzA7tCOSsz9DKk8KGmgpxRs6wGiYX7hyE1B9LBo0XfquMPJcOOf3hUr2z 9Oc2X2w6cfu1XoE7Z6xsXJKjjD0JzOocHHY+7P8/LiVFNNrNuglYM5hzjHdbiFE/zYgh LvNw== X-Gm-Message-State: APjAAAWacfnqCz1HC3cTjweDowPknpcw6dT9VDr8EpbtifE9PYGU9L4s vsvvaK6Se+mcaFHQZWCLoIIkn6CvaJX0BDwFwwY= X-Google-Smtp-Source: APXvYqzLmGEoiMJNbB+iXg/tBOVqBxGk2vbq5l+KEAPq7BtYaQ1jwTwNOqCANx0Kx+fEQK2ttbTJBrOqaZYXC9ayz90= X-Received: by 2002:a19:cc07:: with SMTP id c7mr3840012lfg.107.1572029731763; Fri, 25 Oct 2019 11:55:31 -0700 (PDT) MIME-Version: 1.0 References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> In-Reply-To: From: David Schinazi Date: Fri, 25 Oct 2019 11:55:20 -0700 Message-ID: Subject: Re: Making QUIC less constraining for innovation To: "Salz, Rich" Cc: Roberto Peon , Mirja Kuehlewind , QUIC , Christian Huitema , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000bcfb820595c0b104" 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, 25 Oct 2019 18:55:36 -0000 --000000000000bcfb820595c0b104 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I understand the impulse of encouraging folks to document their codepoint= s, > > but we have to accept the reality that some won't. > > > > And what happens if so? That=E2=80=99s a serious question, not flippant= one. > I suspect they'll simply squat on IANA-owned space. That's not the end of the world, but we need to decide if we prefer that to allowing low-overhead registrations. I personally would like these folks to register so we don't end up with IANA allocating a widely deployed squatted codepoint. --000000000000bcfb820595c0b104 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2= =A0
I understand the impulse=C2=A0of encoura= ging folks to document their codepoints,
but we have to accept the= reality that some won't.

=C2=A0

And what happens if so?=C2=A0 That=E2=80=99s a serio= us question, not=C2=A0 flippant one.

=C2=A0
I suspect they'll simply squat on IANA-owned space.
Th= at's not the end of the world, but we need to decide if we prefer
=
that to allowing low-overhead registrations.

= I personally would like these folks to register so we don't end up
with IANA allocating a widely deployed squatted codepoint.=C2=A0
--000000000000bcfb820595c0b104-- From nobody Fri Oct 25 12:07:34 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775E812011B for ; Fri, 25 Oct 2019 12:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJLQFAZi3gqN for ; Fri, 25 Oct 2019 12:07:30 -0700 (PDT) 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 82ACD120114 for ; Fri, 25 Oct 2019 12:07:30 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id a22so3946299ljd.0 for ; Fri, 25 Oct 2019 12:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=er0ugnQIQu7E6bCnQTs1fKg6+UX6uxaiuL/B+EPFvrI=; b=bmIR5bwTvcGZfNOqtsdrKnnvTgFcG3FOoDj+JRfXGVl7U2FoN3Pt7mPHkS4tp+m3On LiC+9JSg6pwQsawksJLBi8V8pisB6DgjY4FX15TTSTdsfyEzP77dgS5a8qJMADevIO0b jDlG3wQI8u8jfHRjZsHwljgat3Tay1uiuqs66doSkFBkgZR4juV5rcSPwV3r9Sts6l2P 654dr+KZ2R5hH3v2itA4CdUKKu5oUdlpL4GDXAEykCBgrOpSlLRzMCHeLo8iHtmL61iE EarkP9ulJnxtyGcUBJ8ZyKSq21r1ldcPOPMwenoWC7Qf/5aiXDxHwLcCQ5erJ/ucjsrJ +Vdw== 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=er0ugnQIQu7E6bCnQTs1fKg6+UX6uxaiuL/B+EPFvrI=; b=X5qH2ZzUrnaTGEaDq67dDUI+bQ/W7H/iLoRE3YfEeVMjRA4fSOnaEpwwZ50duF631C ej4h2xwI0Pt6SHEWlv8YFv/GQC+TqRBGDknJPeo6f7ryjPv7tEu36Hq3EddbqjqG1sEB nrnqbHcLJ6E4njXg68hbbtLZf5tWf7063A1TsW37cddsZkL+RbaSzIer98LCNJYBlIfG Uk7lgREmJIvggi1rI3wIBNQnF/98sPJUF53FKbb7qzOxz+S9w2krM9IlFzdGqwyOKSKu 76yfNHmS9MIdR88YrrUzDu8BGfLeQrL3gds2t8Ueiz8zX2PKsU/Lm44H9UZ5SsUBopbL 62/w== X-Gm-Message-State: APjAAAVt4qXGTIUeqmxmma7T2z7cA9Ec1SYbcslMsodQgMUt7QLNDVwq zF5WcsatK4kKx4wf3yUnsiHvAozmSl/HGdO3H6U= X-Google-Smtp-Source: APXvYqwD2JG7i81fIDKQvxRqB7ibSFZkuXYAjPmSf+IRw0i7cAqmyE08hTopqN+siYrjxU7wDdaq8IbMCyE+J/e7S1o= X-Received: by 2002:a2e:29dd:: with SMTP id p90mr3570819ljp.26.1572030448745; Fri, 25 Oct 2019 12:07:28 -0700 (PDT) MIME-Version: 1.0 References: <7ac87af3-b49b-4e93-8f70-db35a74419a8@www.fastmail.com> In-Reply-To: From: David Schinazi Date: Fri, 25 Oct 2019 12:07:17 -0700 Message-ID: Subject: Re: Updates to QUIC Datagrams To: Martin Thomson Cc: QUIC Content-Type: multipart/alternative; boundary="000000000000793f990595c0dc6f" 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, 25 Oct 2019 19:07:34 -0000 --000000000000793f990595c0dc6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Martin, I've filed GitHub issues for these: https://github.com/tfpauly/draft-pauly-quic-datagram/issues/18 https://github.com/tfpauly/draft-pauly-quic-datagram/issues/19 https://github.com/DavidSchinazi/draft-h3-datagram/issues/2 David On Wed, Oct 23, 2019 at 12:26 PM Rui Paulo wrote: > On Oct 22, 2019, at 17:22, Martin Thomson wrote: > > > > Thanks for doing this, I think that this is a reasonable approach. > > > > On Wed, Oct 23, 2019, at 08:19, David Schinazi wrote: > >> https://tools.ietf.org/html/draft-pauly-quic-datagram-04 > > > > Simple is good. > > > > This probably need to say more about 0-RTT. That is, explain that > protocols that use DATAGRAM in 0-RTT need to define a protocol-specific > profile that explains what usage patterns are safe and what anti-replay > countermeasures are recommended. > > That=E2=80=99s a valid point and I brought up other 0-RTT considerations = in July: > > https://github.com/tfpauly/draft-pauly-quic-datagram/issues/14 > > > Is it illegal to send an empty DATAGRAM frame? > > With the removal of the flow identifiers from the transport, I don=E2=80= =99t see > reason why it=E2=80=99s even needed. That said, I don=E2=80=99t oppose i= t being legal. > > =E2=80=94 > Rui Paulo > > --000000000000793f990595c0dc6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div class=3D"gmail_quote">
On Wed, Oct= 23, 2019 at 12:26 PM Rui Paulo <rpaulo=3D40apple.com@dmarc.ietf.org> wrote:
On Oct 22, 2019, at 17:22, Martin= Thomson <mt@lowe= ntropy.net> wrote:
>
> Thanks for doing this, I think that this is a reasonable approach.
>
> On Wed, Oct 23, 2019, at 08:19, David Schinazi wrote:
>> https://tools.ietf.org/html/draft-p= auly-quic-datagram-04
>
> Simple is good.
>
> This probably need to say more about 0-RTT.=C2=A0 That is, explain tha= t protocols that use DATAGRAM in 0-RTT need to define a protocol-specific p= rofile that explains what usage patterns are safe and what anti-replay coun= termeasures are recommended.

That=E2=80=99s a valid point and I brought up other 0-RTT considerations in= July:

https://github.com/tfpauly/draft-pauly= -quic-datagram/issues/14

> Is it illegal to send an empty DATAGRAM frame?

With the removal of the flow identifiers from the transport, I don=E2=80=99= t see reason why it=E2=80=99s even needed.=C2=A0 That said, I don=E2=80=99t= oppose it being legal.

=E2=80=94
Rui Paulo

--000000000000793f990595c0dc6f-- From nobody Fri Oct 25 12:23:58 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DE812013D for ; Fri, 25 Oct 2019 12:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, 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 taWdyIx3FMnB for ; Fri, 25 Oct 2019 12:23:56 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 242421200D8 for ; Fri, 25 Oct 2019 12:23:56 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9PJMPpY004887; Fri, 25 Oct 2019 20:23:50 +0100 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=KwxgIT8N18ovUVNu1wAjrLvpxvHWUDsiTpNg9CsYX3o=; b=iYmVPdJJZA2X5fkJ7J7ECrQzoJsNaxmlpbF1fBsAzG9UgU8S98BadyZqqH16wdEMrJAI xARE7rI5GXuikwVmyzka9rQQgeaI4nhiG5pUr1NkiHxUJ8HRc81TNjrbBRrN4JTnFHN1 sRzymOKVrLhh8VR0Ow0bKJBp577YGjZaA4UBBqbp/b3c3LUihdl1DeoERJ/Pcb62ZYRl iM6J4feCkfE4UcPQi6whRgJDn/P/Os+/9tBa4O0HUnfLl/ik821uPIJD8CUqgUI2YV/j ivEUL8iT5h5dYBMKWP27fNIq4iW8sDnYIbvO3Pw9qRg0xofnGWPjDVQIC0jWgKkSyVsH Tg== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2vv2xuh37w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Oct 2019 20:23:50 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9PJHYqj028195; Fri, 25 Oct 2019 15:23:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint7.akamai.com with ESMTP id 2vqwu2r71e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 25 Oct 2019 15:23:47 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 15:23:46 -0400 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; Fri, 25 Oct 2019 15:23:46 -0400 From: "Salz, Rich" To: David Schinazi CC: Roberto Peon , Mirja Kuehlewind , QUIC , Christian Huitema , Martin Thomson Subject: Re: Making QUIC less constraining for innovation Thread-Topic: Making QUIC less constraining for innovation Thread-Index: AQHVihr0wKOBWmevhU2YcAoLtno5GKdpdyYAgAANYACAAAWDAIAADFuAgADS/QCAAFoiAIAARmmAgAAgxQCAAGDygIAASVWAgAAh0wD//746AIAARVIA///E4oA= Date: Fri, 25 Oct 2019 19:23:45 +0000 Message-ID: <7C3F3194-F087-4765-AC46-DF4E883CB4AB@akamai.com> References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.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.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.81.209] Content-Type: multipart/alternative; boundary="_000_7C3F3194F0874765AC46DF4E883CB4ABakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-25_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=535 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910250174 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-25_09:2019-10-25,2019-10-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 spamscore=0 mlxlogscore=509 phishscore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 malwarescore=0 clxscore=1015 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910250175 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, 25 Oct 2019 19:23:57 -0000 --_000_7C3F3194F0874765AC46DF4E883CB4ABakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSBwZXJzb25hbGx5IHdvdWxkIGxpa2UgdGhlc2UgZm9sa3MgdG8gcmVnaXN0ZXIgc28g d2UgZG9uJ3QgZW5kIHVwDQp3aXRoIElBTkEgYWxsb2NhdGluZyBhIHdpZGVseSBkZXBsb3llZCBz cXVhdHRlZCBjb2RlcG9pbnQuDQoNCkkgZ2V0IGl0LCBhbmQgSSBleHBlY3QgdGhlIFdHIG1heSBk byB0aGF0Lg0KDQpCdXQgSSBjYW4gYmUgYSByZWFsIGplcmssIGFuZCBJIHdhbnQgdXMgdG8gZG8g dGhhdC4gOikNCg== --_000_7C3F3194F0874765AC46DF4E883CB4ABakamaicom_ 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 YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTAwNDgyNTEzOw0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotOTkzNzY4NzgwIDQ0NjIwNTk5 MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+SSBwZXJzb25hbGx5IHdvdWxkIGxpa2UgdGhlc2UgZm9s a3MgdG8gcmVnaXN0ZXIgc28gd2UgZG9uJ3QgZW5kIHVwPG86cD48L286cD48L2xpPjwvdWw+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2l0aCBJQU5BIGFsbG9jYXRpbmcgYSB3aWRlbHkg ZGVwbG95ZWQgc3F1YXR0ZWQgY29kZXBvaW50LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGdldCBpdCwgYW5kIEkgZXhwZWN0IHRoZSBXRyBtYXkgZG8gdGhhdC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QnV0IEkgY2FuIGJlIGEgcmVhbCBqZXJrLCBhbmQgSSB3YW50IHVzIHRvIGRv IHRoYXQuIDopPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_7C3F3194F0874765AC46DF4E883CB4ABakamaicom_-- From nobody Fri Oct 25 14:13:50 2019 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 073AD1209A3; Fri, 25 Oct 2019 14:12:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: magnus.westerlund@ericsson.com, quic@ietf.org Subject: quic - Requested sessions have been scheduled for IETF 106 X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203792502.2724.2465668915219328085.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:05 -0700 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, 25 Oct 2019 21:12:09 -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, 19 November 2019, Morning Session I 1000-1200 Room Name: Padang size: 300 --------------------------------------------- quic Session 2 (2:00 requested) Wednesday, 20 November 2019, Morning Session I 1000-1200 Room Name: Padang size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/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 Number of Attendees: 200 Conflicts to Avoid: Chair Conflict: httpbis Technology Overlap: mptcp tls iccrg tcpm tsvwg tsvarea saag Key Participant Conflict: doh capport add 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 Alan Frindell Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: Two consecutive days early in the week, if possible. Please avoid colliding with all BOFs and area-wide meetings. --------------------------------------------------------- From nobody Fri Oct 25 18:19:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFAE120099 for ; Fri, 25 Oct 2019 18:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=himdFgAE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HwdyNy20 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjP0iM01FhJu for ; Fri, 25 Oct 2019 18:19:14 -0700 (PDT) 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 28914120090 for ; Fri, 25 Oct 2019 18:19:14 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2990D56A; Fri, 25 Oct 2019 21:19:13 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Fri, 25 Oct 2019 21:19:13 -0400 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 :cc:subject:content-type; s=fm3; bh=KYzWKSsPQIFM7GDGec0aLJHhIntf B4l2/wJ8HAdiK8c=; b=himdFgAEDt4YKWJHh0jnbIiujIBgMprOlPcD+wGpqtUd Ou45Bo/7CvUwqw6AhG4fSy4jVMjS5liCVbfGM5pWvn74hm/5k6kkvpBd0G51XNmy mRwIh9F8TaiYNDhbrsdHScHHbVgV9N8EvSCfS+FtiUgjXzu+2d5TBkYP3HPlpOg6 7wOosLi962diXdM3Xi0UxgSbufQRTdEtd1SQ6LoEVWRRv6IJWAUU3Z0FioTM+bRq r9ZMVLFaioKGVyEQ2Yqriq7zkiCK9cyWXEiUU3f3nU8/AV2dtD4mwT33IDtj7AH/ 0v5al52parm/sZoXtmJT5LGs1d0j7ttiUQqOB8lYyA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=KYzWKS sPQIFM7GDGec0aLJHhIntfB4l2/wJ8HAdiK8c=; b=HwdyNy20X0Nr67mtBis48p nOypgg/EBK5S+bywF4WsCyc1oGZTUk5Duk9dK/Cr+u3YSYu6PzX1PK+L9dLdSVbX FKh/Y+wKmzP/7UshBQsHCSu1eh3eWDIn0dy9/B1o10k98l9m9wTkGt0yAsPpZ0bE nAT8YdchwW6KBMEam9t4g5O2DFFolPdSK7DUB61y1mknmdJ+SRcWSyO9+WdZfJ3t OcC6NOP0IklZTPBQlnPRX71t9dvgHuOsg8Jocsr8ijEQmgg3HND3fkkN0AyA+oGG nN1n8CkJYxs0W720VxPkQUtGFxMTOkJnsmyg897BeifrtAoTg4YEjeFwud8ZEEXw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrleeggdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EA760E00A3; Fri, 25 Oct 2019 21:19:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> Date: Sat, 26 Oct 2019 12:18:51 +1100 From: "Martin Thomson" To: "David Schinazi" , "Roberto Peon" Cc: "Mirja Kuehlewind" , "Christian Huitema" , QUIC Subject: Re: Making QUIC less constraining for innovation 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, 26 Oct 2019 01:19:16 -0000 On Sat, Oct 26, 2019, at 05:42, David Schinazi wrote: > I don't think requiring folks to document their extensions is realistic. Nothing in the proposal required that they be documented. I proposed to have provisional registrations explicitly allow for registrations with no information attached. As an aside, I think we might want to require contact information, which is (I think) normal practice for registries. I don't think that we should insist on that contact information being "good"; there's no guarantee that is remains that way even if we did want to test it. From nobody Fri Oct 25 18:45:09 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1881200B6 for ; Fri, 25 Oct 2019 18:45:07 -0700 (PDT) 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 XB66EXZ6pbur for ; Fri, 25 Oct 2019 18:45:04 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E6E12001A for ; Fri, 25 Oct 2019 18:45:04 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id v24so5013526ljj.3 for ; Fri, 25 Oct 2019 18:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i/VZHXYuAuOlNuZ8HYEtv9MQAr4m6jlcYCWjVSnl4cM=; b=pi1tIedtTOtp+PFuYMRukn+ipCJucsGcrltgr3+1VXMcrDEr4l6/5NWUGDd6ZDv+Ut f9eYOL5DhplBmiVdGlvStP6f6NjTJBsP/SQdisOjmTYj0UYXRWebPHRC2imnmFVegSHd djvPHzx7Y87Dk0hfWf0skTB3lefhSC+8r7Ok+pAnSCq/W1YoTSCqfeXZCdkYc+FKeVas aoZwq2pLq0hy9sUtNO0ZAcjOJ/hgLyHeMuBI7KQxwjT9kHpT8qtrmDIm7t0k0E9ujQ2K Zch2KEAIHBNdkKT2dXg3flGyrWa6/uY8npU2XEIoLDpXSONXLoDE2fe2gDMgrPoyHGmq 7PUg== 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=i/VZHXYuAuOlNuZ8HYEtv9MQAr4m6jlcYCWjVSnl4cM=; b=dnpqOznCEvmodnGXIBkL88R2q/KxGrDsYDf8s9LHJZ9Y55rPtWPjSUcAUkmVevjIbw PGv5jym8BFVd0BF+36D4ud5YeeKxz8GcNGkasbYrRtQrbjq5xAOgd/VxhWYOEXJVX+zX g38Wdc3skyv7/smoSfljif0oACcpwmuKOL3Tli46KAZRADU40DWqfae6fgIpHUS9LaMM PqIf6Llw1nTo+4E5btt4p8+EtkSOkuoCyZVEyic4VnBUzUBKCotKcUSp4Wl+KAHc3uvU bgFLpH02pNB0E8NsWA/B9nQznDx9B9VA2gQC/tgkBw4lZjJd2u5C1N9OAAtirMCVbupS wUgw== X-Gm-Message-State: APjAAAV65QOZMeIjggR/L+CNbpHeGV0duH+jkT9YMWWjGEt3ITCad21P oyB6247CANqtQQ0b+d7fkPr6miv/f+4+NvEbJ9E= X-Google-Smtp-Source: APXvYqyr5r+a71GwKfJs6YzL2yUE7X6XAsmmsj0r8Mxj/aB0DbX4iF01jFtTy9bfjqrgxLtAoD8N+sS2kvozVIH7ZjQ= X-Received: by 2002:a2e:29dd:: with SMTP id p90mr4394679ljp.26.1572054302313; Fri, 25 Oct 2019 18:45:02 -0700 (PDT) MIME-Version: 1.0 References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> In-Reply-To: From: David Schinazi Date: Fri, 25 Oct 2019 18:44:51 -0700 Message-ID: Subject: Re: Making QUIC less constraining for innovation To: Martin Thomson Cc: Christian Huitema , Mirja Kuehlewind , QUIC , Roberto Peon Content-Type: multipart/alternative; boundary="00000000000041d3780595c66aea" 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, 26 Oct 2019 01:45:07 -0000 --00000000000041d3780595c66aea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable By provisional, do you mean that they=E2=80=99d expire after some time? I= =E2=80=99m not sure that=E2=80=99s satisfactory for undocumented proprietary extensions. Requiring contact information doesn=E2=80=99t sound like much of a hurdle t= hough, I=E2=80=99m happy with that. On Fri, Oct 25, 2019 at 18:19 Martin Thomson wrote: > On Sat, Oct 26, 2019, at 05:42, David Schinazi wrote: > > I don't think requiring folks to document their extensions is realistic= . > > Nothing in the proposal required that they be documented. I proposed to > have provisional registrations explicitly allow for registrations with no > information attached. > > As an aside, I think we might want to require contact information, which > is (I think) normal practice for registries. I don't think that we shoul= d > insist on that contact information being "good"; there's no guarantee tha= t > is remains that way even if we did want to test it. > --00000000000041d3780595c66aea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
By provisional, do you mean that they=E2=80=99d expi= re after some time? I=E2=80=99m not sure that=E2=80=99s satisfactory for un= documented proprietary extensions.

<= div dir=3D"auto">Requiring contact information doesn=E2=80=99t sound like m= uch of a hurdle though, I=E2=80=99m happy with that.


On Fri, Oct 25, 2019 at 18:19 Martin Thomson <mt@lowentropy.net> wrote:
On Sat, Oct 26, 2019, at 05:42, David Schinazi wrote: > I don't think requiring folks to document their extensions is real= istic.

Nothing in the proposal required that they be documented.=C2=A0 I proposed = to have provisional registrations explicitly allow for registrations with n= o information attached.

As an aside, I think we might want to require contact information, which is= (I think) normal practice for registries.=C2=A0 I don't think that we = should insist on that contact information being "good"; there'= ;s no guarantee that is remains that way even if we did want to test it.
--00000000000041d3780595c66aea-- From nobody Fri Oct 25 19:33:23 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B1A12008B for ; Fri, 25 Oct 2019 19:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=IWaeKYWf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KTu8T0sQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGJkFsa-HXWb for ; Fri, 25 Oct 2019 19:33:21 -0700 (PDT) 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 A12D812001A for ; Fri, 25 Oct 2019 19:33:21 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id EDB4F51A for ; Fri, 25 Oct 2019 22:33:20 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Fri, 25 Oct 2019 22:33:21 -0400 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:content-transfer-encoding; s=fm3; bh=W8pgQ DTmICq/YBJ/imDfO+gu3AaH0acccxVuA90iWek=; b=IWaeKYWfVwrGTctXVY/SQ GpkAiUE8xYHU9ja7zHyl3RN/bZ+4w4pakAR/bs3m8cb8+X2xrCmg6ll93XFY+XZT TsGdfWJMfZLch9poRYmm1xNWGdqm+Bzz6fq5nPvzqfDzArIeZehqfHmbu+9nS9PU XbO+xA5Obhb6BehtH36um80h+ZSNNMaV0Z1C8g1AoS/kws4UdPTo2Nk0yGFWxuwM H3J20gTihw4vRKU2vFBL6zUjceZBDOZCGM1KETVCVGWmmvM5yOP+MgDHJZA7bBKA 0SuI8eieXhPW5WDZW6ps+2IBjpVxLHyJQse0fWUetp1KmvIgH2sQGaVttSgjPoZd A== 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=fm1; bh=W8pgQDTmICq/YBJ/imDfO+gu3AaH0acccxVuA90iW ek=; b=KTu8T0sQurR7HdZ5KOUSRssyve1bkMCJpHhHB3nmKObBcBdFcTmoXLOUF uP0h3jAVCpLNa/JWH1az9ptmMpkUBPQa/oIJmY/2JPCpv5Gy0VveBPkDhmfBbbl0 rUtye6PP5Sk34wyhOHbSbdaOeap9oqlMXtB0tET6ru+Fevwop1a4qQTiQS1LM8TG +qJPbSYV4W9euYtZ2oty8lEdenNUR5b756IcjO98NheH3IC43N4mHzaHPrmCm0se Z3Gab2KqoUGt6PW19xDpNo4tQUrtG3i/36iXYIXUyu/PGzQITnddPua6yzg2P9QS sU5xHi3eEW7NQ9nBT8WRNycMBPE7w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrleeggdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 17003E00A5; Fri, 25 Oct 2019 22:33:20 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: <48a73d4d-9d59-4ab8-9fa5-8bf2f771f585@www.fastmail.com> In-Reply-To: References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> Date: Sat, 26 Oct 2019 13:32:59 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Making QUIC less constraining for innovation 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: Sat, 26 Oct 2019 02:33:23 -0000 On Sat, Oct 26, 2019, at 12:44, David Schinazi wrote: > By provisional, do you mean that they=E2=80=99d expire after some time= ? I=E2=80=99m not=20 > sure that=E2=80=99s satisfactory for undocumented proprietary extensio= ns. Yeah, the idea is that these have no expectation of being permanent, so = that there is some hope of reclaiming spent codepoints. But they can wo= n't be reclaimed unless necessary, and renewal should be easy. From nobody Fri Oct 25 19:35:13 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF56120026 for ; Fri, 25 Oct 2019 19:35:11 -0700 (PDT) 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=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 UetNPcyE-JMu for ; Fri, 25 Oct 2019 19:35:08 -0700 (PDT) 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 7C5EB120019 for ; Fri, 25 Oct 2019 19:35:08 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id c2so4324583wrr.10 for ; Fri, 25 Oct 2019 19:35:08 -0700 (PDT) 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=Ws6SoHGYU8e1xlUMLK3uKJq1m0nxdqGWvv2/KdX53Ps=; b=sZwx+YqAWdnYfGaSlcX1g+N6vcorKl+1fsbvaqLTaPW9IPzUOQ/5PV9qzQc3bz1tYC rbLJ6Cjsfey4kOZauRpxwNAtmfUWKnQkObEB3MjGnI1mXdrWu42/GBIx9L9cEVeWDBgt VzFKBPoBmkhtjOR62jx36Yp28JxHQXSvIUzsc8fI+laZLmJ4dPKGFDSfVNUwZUQlNhVE ll26pO/11m+9uNDs6uWklWUFEUtZg2lg/at6ct7FDDR+ZNhnpqxeqB6IpPktmjbGxkj7 h7PfVI4rkAMBmhutE8vsnmHVb0X/3fGgu5oPZEOFTHG79D5VCWbFw0EPIzL7e1wet7WY iRYw== 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=Ws6SoHGYU8e1xlUMLK3uKJq1m0nxdqGWvv2/KdX53Ps=; b=El8JOs0ygaqXtq+fAGeZqsnR6F/G8T9mIBQJ0+8aT9I9PCjqhKFG+TgLHy6eX6IQX5 nuEHTNv7hfSaEFDsnxL6eJkRuJJkZlT2H/WHBl3SmZwERmJK/mj53LcfSw/T2MWZYaSK ryp0cK37Ix6Im+UZ/YkomKxot3AjWaZoZuThYrs6ymHAdrvqKHWe0l34s6DOcYiX8H+Q aNJLxUJCbYAgyMOn2Ks50DPf89H4vD5FG/MLbFkmKXzINgQp/dffz1emi//WcC6g8Ihr rNdboWAi+M7nDnYVMhcmIKBMBTs4g9HuJP2szcumHYZMQxyR5zz8F856yZXyFnbVcZ+j rSrA== X-Gm-Message-State: APjAAAXQ3dfVqrKPS9Gh0zrFt1QwxI8A2GTUX6mxncPov3RZfjHDtzYa YaGqfnVxb8TGHI8TBZ9V0vLMQ9XM4qqlGU/tvACTyw== X-Google-Smtp-Source: APXvYqxuW7QAMWEUJr7m7C418XKIsiPHPDiT0O4QWG8dyqB4u/9A8GBT7+TzfwDasNgPs1yi0qNXZoRc2Y5MsdjNjJU= X-Received: by 2002:adf:e849:: with SMTP id d9mr5349579wrn.145.1572057306428; Fri, 25 Oct 2019 19:35:06 -0700 (PDT) MIME-Version: 1.0 References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> In-Reply-To: From: Ryan Hamilton Date: Fri, 25 Oct 2019 19:34:54 -0700 Message-ID: Subject: Re: Making QUIC less constraining for innovation To: David Schinazi Cc: Martin Thomson , Mirja Kuehlewind , QUIC , Christian Huitema , Roberto Peon Content-Type: multipart/alternative; boundary="00000000000051753e0595c71dca" 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, 26 Oct 2019 02:35:12 -0000 --00000000000051753e0595c71dca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Requiring contact information (knowing that it might be stale) sounds great. Asking for a completely optional description also sounds good to me. On Fri, Oct 25, 2019 at 6:45 PM David Schinazi wrote: > By provisional, do you mean that they=E2=80=99d expire after some time? I= =E2=80=99m not > sure that=E2=80=99s satisfactory for undocumented proprietary extensions. > > Requiring contact information doesn=E2=80=99t sound like much of a hurdle= though, > I=E2=80=99m happy with that. > > > On Fri, Oct 25, 2019 at 18:19 Martin Thomson wrote: > >> On Sat, Oct 26, 2019, at 05:42, David Schinazi wrote: >> > I don't think requiring folks to document their extensions is realisti= c. >> >> Nothing in the proposal required that they be documented. I proposed to >> have provisional registrations explicitly allow for registrations with n= o >> information attached. >> >> As an aside, I think we might want to require contact information, which >> is (I think) normal practice for registries. I don't think that we shou= ld >> insist on that contact information being "good"; there's no guarantee th= at >> is remains that way even if we did want to test it. >> > --00000000000051753e0595c71dca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Requiring contact information (knowing that it might=C2=A0= be stale) sounds great. Asking for a completely optional description also s= ounds good to me.

On Fri, Oct 25, 2019 at 6:45 PM David Schinazi <<= a href=3D"mailto:dschinazi.ietf@gmail.com">dschinazi.ietf@gmail.com>= wrote:
By provisional, do you mean that they=E2=80=99d expire after= some time? I=E2=80=99m not sure that=E2=80=99s satisfactory for undocument= ed proprietary extensions.

Requiring contact information doesn=E2=80=99t sound like much of = a hurdle though, I=E2=80=99m happy with that.


On Fri, Oct 25, 2019 at 18:19 Martin Thomson <mt@lowentropy.net> wrote:
<= 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">On Sat, Oct 26, 2019, at 0= 5:42, David Schinazi wrote:
> I don't think requiring folks to document their extensions is real= istic.

Nothing in the proposal required that they be documented.=C2=A0 I proposed = to have provisional registrations explicitly allow for registrations with n= o information attached.

As an aside, I think we might want to require contact information, which is= (I think) normal practice for registries.=C2=A0 I don't think that we = should insist on that contact information being "good"; there'= ;s no guarantee that is remains that way even if we did want to test it.
--00000000000051753e0595c71dca-- From nobody Sat Oct 26 00:09:10 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023C2120071 for ; Sat, 26 Oct 2019 00:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 B5tatX6gEhKj for ; Sat, 26 Oct 2019 00:09:06 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 C628A12006E for ; Sat, 26 Oct 2019 00:09:05 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id bm15so3620273edb.3 for ; Sat, 26 Oct 2019 00:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=g8wf6F4C1JHCGjQ/ZA+eK3wYMZeI42BvsErCw+SLWhY=; b=HNnhlwWJ9904HYGuA6q8iXH69ujCPzeVQvBgZ/HD9fGpp4eW6+yQnRC6GAflGy2Ky5 AYkmmXZ27wG+6mnFkx+8h9lDbP/YR9PDEY0z06F/9TEQj6mkWmcW5gI2ZgNvV9Sro5Rc Vn8ugwpePIV718O23QId71Qrzm41Z7T74KYdw2dsWOhwIVKbZeozsg5u/RPoN6U3cQj2 6bZG1VOkGOZLN8wgZIsmZ9TmP8QgSZFsiI+ZrDLeVqSXKvOXGSXf5hZFmmRJFFahwAG3 PPwWD3CZZDf3p8fxPKLZ1eyCWoWagjeTaiEIGaOPYWlOZweRC8AwIFh/QGKewEkOxcPH 0NcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=g8wf6F4C1JHCGjQ/ZA+eK3wYMZeI42BvsErCw+SLWhY=; b=WPFzU+bbytMIYuAV79nmiPNLSKlC/G7BUWuNRrRkFbaCVyfL15GITiDIzR5uBoVQYy LRcpbUvXKLXSY7gerG5DhJ2uMyKmTAen7VWNivFxPcTcsuRijE6HNggKQ/IyxkBtkWnf G3UaTqrY1eFfgFqfem68TctDzmMG0q+5vlGUV7Dh2yTJoK+TJQUIoM/8ILJkhc5cLdCp iFdDuvMNKZb/p1de9hE4gkgJsk+DChbV1siVYJBucFRzO9H/JWZ1V0LeQ8y/LS9pLhCg twZ/Ty5CUIqQMVNWuzIf4/eplLo65n9LEy382pYkPf1l1PyxDPcfq3xT9dvV5cb0IS79 +CfQ== X-Gm-Message-State: APjAAAVY6qr9BR34y3g3A5Xd+EW5N2e1M/bCqC/Yt/X7cLOAfcTZAv0G 0XgUpkBBu27YDv87GXB4OOSyl08EIPR7K9xbaHcpM82H X-Google-Smtp-Source: APXvYqwS5OLjwYHZj0/9SHra47aX3qbLkxfem/4c8/Fy99b25o4kjmockHBPerCrBmqWbn4Bs0hPoOwYMA+OVPG+2yA= X-Received: by 2002:a50:fa84:: with SMTP id w4mr8330069edr.250.1572073744393; Sat, 26 Oct 2019 00:09:04 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 26 Oct 2019 03:09:03 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <48a73d4d-9d59-4ab8-9fa5-8bf2f771f585@www.fastmail.com> References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> <48a73d4d-9d59-4ab8-9fa5-8bf2f771f585@www.fastmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sat, 26 Oct 2019 03:09:03 -0400 Message-ID: Subject: Re: Making QUIC less constraining for innovation To: Martin Thomson , quic@ietf.org Content-Type: multipart/alternative; boundary="0000000000001869630595caf187" 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, 26 Oct 2019 07:09:08 -0000 --0000000000001869630595caf187 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If transport parameters are ordered and variable length you can sidestep the problem by reserving a specific range to custom values and require a preceeding parameter to have a random UUID value to namespace that range. In principle the namespace and range can be repeated for different namespaces. You can then optionally allow for the namespace to be registered but it isn=E2=80=99t necessary because the chance is effectively zero. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 26 October 2019 at 04.33.32, Martin Thomson (mt@lowentropy.net) wrote: On Sat, Oct 26, 2019, at 12:44, David Schinazi wrote: > By provisional, do you mean that they=E2=80=99d expire after some time? I= =E2=80=99m not > sure that=E2=80=99s satisfactory for undocumented proprietary extensions. Yeah, the idea is that these have no expectation of being permanent, so that there is some hope of reclaiming spent codepoints. But they can won't be reclaimed unless necessary, and renewal should be easy. --0000000000001869630595caf187 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = If transport paramet= ers are ordered and variable length you can sidestep the problem by reservi= ng a specific range to custom values and require a preceeding parameter to = have a random UUID value to namespace that range.

In principle the namespace and range can be re= peated for different namespaces.

You can then optionally allow for the namespace to be registere= d but it isn=E2=80=99t necessary because the chance is effectively zero.


=
Kind Regards,
Mikkel Fahn=C3=B8e J=C3= =B8rgensen


On 26 October 20= 19 at 04.33.32, Martin Thomson (mt@low= entropy.net) wrote:

On Sat, Oct 26, 2019, at 12:44, David Schinazi wro= te:
> By provisional, do you mean that they=E2=80=99d expire after some = time? I=E2=80=99m not =20
> sure that=E2=80=99s satisfactory for undocumented proprietary exte= nsions.

Yeah, the idea is that these have no expectation of being permanent, so= that there is some hope of reclaiming spent codepoints. But they can won&= #39;t be reclaimed unless necessary, and renewal should be easy.

--0000000000001869630595caf187-- From nobody Sat Oct 26 17:45:25 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBFA1200F9 for ; Sat, 26 Oct 2019 17:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=VNvo6yar; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=O8yr/WTl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Amu92ZH_6RQ for ; Sat, 26 Oct 2019 17:45:18 -0700 (PDT) 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 A9754120048 for ; Sat, 26 Oct 2019 17:45:18 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id EFEB63A6 for ; Sat, 26 Oct 2019 20:45:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 26 Oct 2019 20:45:18 -0400 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=h6k4lMZqaX6SWjuVwZQ3spPSHyUYA778ZW+CKTX+FNk=; b=VNvo6yar Xfb7z85S0PgTugU/gZoHXdG2eRgFF4bPDhAYzl338azJa2Q11syJdurQSUzeKtPv 1/SN2l/iDXXkCkOGjy8XNkFP1Rur02lvFIN59FmwfqNx5ChdtsAvTf0Q0XOzFnD3 T4hKuawAVJ6ke6Tv1Lz4NIOTDyCNEsuWr6mR407jLckoPiLrmbhm7odFHZ6DFA8i xWWuR2nQLh71S/pA9offEYZAZBtzJAkeNlVVm+EyQzFkeaCBVoa/grELmHWuzpSY JH0+QAHkUxfGs2m1FGlQVqoRW9jhJ8UT2JskXCLMmTSkT1Qt6ycE52EeZCRQE2i1 DWQWQI91E8FLSA== 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=h6k4lMZqaX6SWjuVwZQ3spPSHyUYA 778ZW+CKTX+FNk=; b=O8yr/WTlPdOcuC6aWzgdEa4PHt510MT7YWnw0pHuHDgUv fcuUa4hJ+H103bqm+7UmYskrUaD5JKAmK0/icnLEqOawdg6TUDScDQ54DX49aiAw TxHeWuTQSnUldWK/RLlc5T1IHNKvUmETlxR7eK2kAKwV4pRheP1p1ttR8DO0QRxS O2uK0CT0H8eo+AqFWEPWVRVe0zaMphMbgqwy0YQpCJR60RqIYBacXwFOpUcDFpQo iU3xYMseezcgmMjJjW5v4PWdVQT4ODwmBSFzvi6p67LvBIXfQviBfCEYD6Q629P7 nygzz/3+R0sRCLC3B7FMIWUvcm6BS4zQW+fVjISIw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrleeigdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgsucfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc fkphepgeehrdejledruddufedrudeiheenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 19B85D6005A for ; Sat, 26 Oct 2019 20:45:17 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 67F579E71C for ; Sun, 27 Oct 2019 00:45:16 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============9047324464438631399==" MIME-Version: 1.0 From: Github Notifications To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20191027004516.67F579E71C@cloud.mnot.net> Date: Sun, 27 Oct 2019 00:45:16 +0000 (UTC) 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, 27 Oct 2019 00:45:23 -0000 --===============9047324464438631399== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+3/-5/=F0=9F=92=AC13) 3 issues created: - Client storage of tokens should be independent of other stored state (b= y nharper) https://github.com/quicwg/base-drafts/issues/3152=20 - loss detection timer description could be simplified by definining a ti= mer mode (by marten-seemann) https://github.com/quicwg/base-drafts/issues/3151=20 - It is unspecified how a server should send Handshake packets during / a= fter migration (by kazuho) https://github.com/quicwg/base-drafts/issues/3142=20 9 issues received 13 new comments: - #3151 loss detection timer description could be simplified by defininin= g a timer mode (1 by ianswett) https://github.com/quicwg/base-drafts/issues/3151 [-recovery]=20 - #3142 It is unspecified how a server sends Handshake packets during / a= fter migration (3 by erickinnear, ianswett, kazuho) https://github.com/quicwg/base-drafts/issues/3142=20 - #3130 Does it matter if the the STOP_SENDING error code is something ot= her than EARLY RESPONSE? (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/3130 [-http] [design]=20 - #3115 Don't use bitmap frames to describe varint structures (1 by royfi= elding) https://github.com/quicwg/base-drafts/issues/3115 [editorial]=20 - #3111 [Version Ossification] Alternative version and Initial Salt shoul= d be part of NEW_TOKEN (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/3111 [-transport]=20 - #2926 ICID or OCID? (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2926 [-transport] [editori= al]=20 - #2909 Path Migration makes unjustified assumptions about a new path. (1= by erickinnear) https://github.com/quicwg/base-drafts/issues/2909 [-transport] [editori= al]=20 - #2863 unrecoverable loss pattern leads to deadlock (2 by DavidSchinazi,= ad-l) https://github.com/quicwg/base-drafts/issues/2863 [-transport] [design]= [proposal-ready]=20 - #2632 H3 GOAWAY should be symmetric and cover bidi and uni streams (2 b= y LPardue, afrind) https://github.com/quicwg/base-drafts/issues/2632 [-http] [design]=20 5 issues closed: - Does a Retry really need to change the CID? https://github.com/quicwg/b= ase-drafts/issues/2837 [-transport] [editorial]=20 - Discussion in quic-recovery of delayed ack being 25ms does not seem to = relate to anything https://github.com/quicwg/base-drafts/issues/3075 [-reco= very] [editorial]=20 - Does a client need to remember SETTINGS it doesn't understand when doin= g 0-RTT resumption? https://github.com/quicwg/base-drafts/issues/3110=20 - Retransmitting ACKs may cause misleading RTT samples https://github.com= /quicwg/base-drafts/issues/2748 [-recovery] [editorial]=20 - What if server does not send HTTP_EARLY_RESPONSE but starts sending res= ponse https://github.com/quicwg/base-drafts/issues/2963 [-http] [editorial]= =20 Pull requests ------------- * quicwg/base-drafts (+14/-11/=F0=9F=92=AC32) 14 pull requests submitted: - Use the right connection ID (by martinthomson) https://github.com/quicwg/base-drafts/pull/3153 [-transport] [editorial= ]=20 - Clarify the state a client stores with a token (by nharper) https://github.com/quicwg/base-drafts/pull/3150=20 - Explicit linkages for ODCID/OCID TP (by MikeBishop) https://github.com/quicwg/base-drafts/pull/3149 [-transport] [editorial= ]=20 - Fix handling of Retry in recovery (by martinthomson) https://github.com/quicwg/base-drafts/pull/3148 [-recovery] [editorial]= =20 - Servers have to change connection IDs in Retry (by martinthomson) https://github.com/quicwg/base-drafts/pull/3147 [-transport] [editorial= ]=20 - Fix punctuation (by amirlivneh) https://github.com/quicwg/base-drafts/pull/3146=20 - use a HANDSHAKE_DONE frame to drive the handshake to confirmation (by m= arten-seemann) https://github.com/quicwg/base-drafts/pull/3145=20 - Fix typo and wording in change log (by amirlivneh) https://github.com/quicwg/base-drafts/pull/3144=20 - Fix typo and wording in change log (by amirlivneh) https://github.com/quicwg/base-drafts/pull/3143=20 - use key update for confirming the handshake (by kazuho) https://github.com/quicwg/base-drafts/pull/3141=20 - Delete reference to crypto timeout (by martinduke) https://github.com/quicwg/base-drafts/pull/3140=20 - Packets on one path must not adjust values for a different path (by eri= ckinnear) https://github.com/quicwg/base-drafts/pull/3139=20 - Applications need to disable or selectively reject 0-RTT (by martinthom= son) https://github.com/quicwg/base-drafts/pull/3138 [-transport] [editorial= ]=20 - Remove the TLP citation because it's in RACK (by ianswett) https://github.com/quicwg/base-drafts/pull/3137 [-recovery] [editorial]= =20 14 pull requests received 32 new comments: - #3150 Clarify the state a client stores with a token (2 by ianswett, nh= arper) https://github.com/quicwg/base-drafts/pull/3150 [-transport]=20 - #3149 Explicit linkages for ODCID/OCID TP (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/3149 [-transport] [editorial= ]=20 - #3146 Fix punctuation (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/3146 [-transport] [editorial= ]=20 - #3145 use a HANDSHAKE_DONE frame to drive the handshake to confirmation= (10 by DavidSchinazi, ianswett, janaiyengar, kazuho, martinthomson, mikkel= fj) https://github.com/quicwg/base-drafts/pull/3145 [-transport]=20 - #3141 use key update for confirming the handshake (3 by kazuho, martint= homson, nibanks) https://github.com/quicwg/base-drafts/pull/3141=20 - #3140 Delete reference to crypto timeout (2 by ianswett, martinthomson) https://github.com/quicwg/base-drafts/pull/3140 [-transport] [editorial= ]=20 - #3139 Packets on one path must not adjust values for a different path (= 1 by martinthomson) https://github.com/quicwg/base-drafts/pull/3139 [-transport] [editorial= ]=20 - #3112 TLS overview tweaks (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/3112 [-tls] [editorial]=20 - #3108 Replace use of the TLS presentation language with QUIC encoding (= 4 by DavidSchinazi, rpaulo) https://github.com/quicwg/base-drafts/pull/3108 [-tls] [-transport]=20 - #3107 Immediately close with INVALID_TOKEN (2 by ianswett, martinthomso= n) https://github.com/quicwg/base-drafts/pull/3107 [-transport]=20 - #3096 MUST retire Connection IDs becoming stale (1 by mikkelfj) https://github.com/quicwg/base-drafts/pull/3096 [-transport]=20 - #3080 Retransmit server initial upon second Initial (1 by nibanks) https://github.com/quicwg/base-drafts/pull/3080 [-recovery] [design]=20 - #3066 Change PTO to be per packet number space (2 by ianswett, janaiyen= gar) https://github.com/quicwg/base-drafts/pull/3066 [-recovery] [design]=20 - #2925 Add initial threat model to security considerations (1 by mirjak) https://github.com/quicwg/base-drafts/pull/2925 [-transport] [editorial= ]=20 11 pull requests merged: - Use the right connection ID https://github.com/quicwg/base-drafts/pull/3153 [-transport] [editorial= ]=20 - Servers have to change connection IDs in Retry https://github.com/quicwg/base-drafts/pull/3147 [-transport] [editorial= ]=20 - Remove obsolete 'Discussion' section https://github.com/quicwg/base-drafts/pull/3077 [-recovery] [editorial]= =20 - Clarify that clients don't need to remember unknown SETTINGS https://github.com/quicwg/base-drafts/pull/3113 [-http]=20 - Fix punctuation https://github.com/quicwg/base-drafts/pull/3146 [-transport] [editorial= ]=20 - Fix typo and wording in change log https://github.com/quicwg/base-drafts/pull/3144 [-recovery] [editorial]= =20 - Fix typo and wording in change log https://github.com/quicwg/base-drafts/pull/3143 [editorial]=20 - Retransmitting an ACK frame warning https://github.com/quicwg/base-drafts/pull/3049 [-transport] [editorial= ]=20 - Remove the TLP citation because it's in RACK https://github.com/quicwg/base-drafts/pull/3137 [-recovery] [editorial]= =20 - Delete reference to crypto timeout https://github.com/quicwg/base-drafts/pull/3140 [-transport] [editorial= ]=20 - Require clients to keep sending if they want to keep receiving https://github.com/quicwg/base-drafts/pull/3123 [-http] [editorial]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============9047324464438631399== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday October 27, 2019

Issues

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

3 issues created:

9 issues received 13 new comments:

5 issues closed:

Pull requests

quicwg/base-drafts (+14/-11/=F0=9F=92=AC32)

14 pull requests submitted:

14 pull requests received 32 new comments:

11 pull requests merged:

Repositories tracked by this digest:

--===============9047324464438631399==-- From nobody Sun Oct 27 16:02:26 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4752C1200B6 for ; Sun, 27 Oct 2019 16:02:24 -0700 (PDT) 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 BUMHqnl0jiRZ for ; Sun, 27 Oct 2019 16:02:21 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54842120044 for ; Sun, 27 Oct 2019 16:02:21 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id s4so8396732ljj.10 for ; Sun, 27 Oct 2019 16:02:21 -0700 (PDT) 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=oE+wBYohF1pxM3i9icoNoGWhC7Be3crCSIK598+9izw=; b=o/qLrNJwhzrfXlsLWCVAvGiab5hUS6x+UN0UuBolbDWSUYWmI0nnMr0GOEPncB5q7Z m/K+mSt6AUtJx1YfLZmUxRJ9EbHcrO9gHrjod76+018o46f5Irkke+dznEG++NwLIEI+ Mi7e8mnkX7g1BDqKYRnueSNc89sboRfRo/Psyuc5XsBkjBmmZ+xI842nOS0J/2wbE3AC OzJECNVvbw6A+sMX7x/lsAjOJJqj+UPqrCx6QUlMYJ4C+MdUdKq0Fa5j9MQgu3hmkQbj aJ2Z9nFQ/xJAdPKu0ZM09IvCRdNIR/gzWjYuCHaqhWS2KhlxR0zwdOmHK9y/rRbcUU0D PSEw== 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=oE+wBYohF1pxM3i9icoNoGWhC7Be3crCSIK598+9izw=; b=eL+X0kf2DSo9TvGITEgTpxDEHENjsnK8SaxeBM2dLyLOH2Db3qlaE0caOGg4quBWxB aci/qw1osQ0qJc72zwz96RkHD6KOqlPsgh40nO1L62hW9WTHLPB2GAOU3vX3l8kSY21A WL4XgrkvqKnsVF2/En6adVFmbDLU8hIaVYfiT2isZreOJmZ/sucMMzShLOmrFUJf2aNs ui3px89aFwaI21tiVM+YSOUb1mfgV/UXz8SmUu63/6UYgxcC/mhc+jcBbVnxJdq7BPgl +NIChl03RVggarWr7bkaBZmn/9wMcqjVhkirz3nCQMtGeyF2wDnmJwXCU+0cpRHXzkKd p5yg== X-Gm-Message-State: APjAAAU+5VSieLxSVZMhyv6xy6V5twm+Bnpk+zFKgrA8xkq9jn7AMx9j Te+OxuF2HvkDdmaawJpAFO4EgfiF5UetuyZj5ozoqw== X-Google-Smtp-Source: APXvYqzx7Eb70xgU18AtyhGFh8ZSCETzsJQllUlc788Em6wOXH6Is6VCAF7LSCOBzbFvwcIna2o8xRiI/nCTqtmljPM= X-Received: by 2002:a05:651c:1196:: with SMTP id w22mr2588716ljo.217.1572217339464; Sun, 27 Oct 2019 16:02:19 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Sun, 27 Oct 2019 16:01:43 -0700 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Martin Duke Cc: Jana Iyengar , Mike Bishop , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="0000000000000765f00595ec60f1" 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, 27 Oct 2019 23:02:25 -0000 --0000000000000765f00595ec60f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we're clearly going to need to spend some time on this. I don't think the spec is satisfactory as-is: we should be designing a transport that works for all use cases, not just H3. That said, I also don't agree that we need an additional explicit signal. We have one, it's called "ACK". We should figure out how to make that work. -Ekr On Fri, Oct 25, 2019 at 9:36 AM Martin Duke wrote= : > I agree with the dissenters. The current spec works in the HTTP3 use case= , > though I think we should fix it. Keeping keys forever is unsatisfactory f= or > several reasons. We should use an explicit signal, and there is no reason > to kick the can down the road. Let's just leave #2863 open till we resolv= e > it. > > On Wed, Oct 23, 2019 at 7:40 PM Jana Iyengar wrote: > >> Yup. We need to get this over with in the dumbest way possible. >> >> On Thu, Oct 24, 2019 at 3:53 AM Mike Bishop wrote= : >> >>> I think we=E2=80=99ve amply demonstrated that implicit signals don=E2= =80=99t work. I=E2=80=99d >>> like to see an explicit confirmation of handshake completion that happe= ns >>> at 1-RTT. >>> >>> >>> >>> *From:* QUIC *On Behalf Of * David Schinazi >>> *Sent:* Tuesday, October 22, 2019 4:07 PM >>> *To:* Jana Iyengar >>> *Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen ; IETF QUIC= WG < >>> quic@ietf.org>; Martin Thomson ; Kazuho Oku < >>> kazuhooku@gmail.com> >>> *Subject:* Re: Consensus Calls for Transport/TLS issues, post-Cupertino >>> >>> >>> >>> +1 >>> >>> >>> >>> I think the text we have in the spec today is better than the proposal >>> to never discard the handshake keys. >>> >>> My preference would be to spend the time to fix the issue, and not add = a >>> temporary workaround for now. >>> >>> >>> >>> On Tue, Oct 22, 2019 at 12:51 AM Jana Iyengar >>> wrote: >>> >>> I agree with Kazuho here. The issue of migration was not one we had >>> considered. I was going through this with Kazuho, and we may have >>> identified yet another issue with handshake retransmissions and migrati= on, >>> which is present in the current spec. >>> >>> >>> >>> Sadly, I don't think we can call this issue done... >>> >>> >>> >>> On Tue, Oct 22, 2019 at 2:14 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen < >>> mikkelfj@gmail.com> wrote: >>> >>> Without a way to move to a single PN space I find this a deal breaker. = I >>> might do a custom version of the protocol. >>> >>> >>> >>> >>> ------------------------------ >>> >>> *Fra:* QUIC p=C3=A5 vegne af Kazuho Oku < >>> kazuhooku@gmail.com> >>> *Sendt:* tirsdag, oktober 22, 2019 6:58 AM >>> *Til:* Martin Thomson >>> *Cc:* IETF QUIC WG >>> *Emne:* Re: Consensus Calls for Transport/TLS issues, post-Cupertino >>> >>> >>> >>> >>> >>> >>> >>> 2019=E5=B9=B410=E6=9C=8822=E6=97=A5(=E7=81=AB) 11:38 Martin Thomson : >>> >>> On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote: >>> > I'd also prefer to fix the problem, even if it means bringing back >>> > something like RETIRE_KEY. >>> >>> I would prefer to think of this proposed resolution as a temporary one. >>> I don't think that we agreed to keep the handshake keys indefinitely, o= nly >>> that we would use that option as a fallback position until we found a >>> better solution. >>> >>> >>> >>> I might point out that #3121 is not proposal-ready as a way to resolve >>> #2863. That is because it does not define how to send and receive Hands= hake >>> packets until or after migration happens. There would be a deadlock unl= ess >>> both endpoints agree on how that should be done (e.g., how to select SC= ID, >>> whether the path used for Handshake packets migrates too). >>> >>> >>> >>> Without that being clarified, can we say that we are ready for a >>> consensus call? >>> >>> >>> >>> >>> On that basis, I think that it would be best if we open a new issue tha= t >>> says "Handshake keys can't ever be dropped". >>> >>> We might still conclude not to address that issue, but the important >>> thing is to ensure that any solution works properly. >>> >>> >>> >>> >>> -- >>> >>> Kazuho Oku >>> >>> --0000000000000765f00595ec60f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we're clearly going to need to spend some= time on this. I don't think the spec is satisfactory as-is: we should = be designing a transport that works for all use cases, not just H3. That sa= id, I also don't agree that we need an additional explicit signal. We h= ave one, it's called "ACK". We should figure out how to make = that work.
-Ekr


On Fri, Oct 25, 2019 at 9= :36 AM Martin Duke <martin.h.= duke@gmail.com> wrote:
I agree with the dissenters. The current spe= c works in the HTTP3 use case, though I think we should fix it. Keeping key= s forever is unsatisfactory for several reasons. We should use an explicit = signal, and there is no reason to kick the can down the road. Let's jus= t leave #2863 open till we resolve it.

On Wed, Oct 23, 2019 at 7:40 PM J= ana Iyengar <jri= .ietf@gmail.com> wrote:
Yup. We need to get this over with in the d= umbest way possible.

On Thu, Oct 24, 2019 at 3:53 AM Mike Bishop <mbishop@evequefou.be= > wrote:

I think we=E2=80=99ve amply demonstrated that implic= it signals don=E2=80=99t work.=C2=A0 I=E2=80=99d like to see an explicit co= nfirmation of handshake completion that happens at 1-RTT.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = David Schinazi
Sent: Tuesday, October 22, 2019 4:07 PM
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; IETF QUIC WG <= quic@ietf.org>; M= artin Thomson <mt= @lowentropy.net>; Kazuho Oku <kazuhooku@gmail.com>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertin= o

=C2=A0

+1

=C2=A0

I think the text we have in the spec today is better= than the proposal to never discard the handshake keys.

My preference would be to spend the time to fix the = issue, and not add a temporary workaround for now.

=C2=A0

On Tue, Oct 22, 2019 at 12:51 AM Jana Iyengar <jri.ietf@gmail.com> wrote:

I agree with Kazuho here. The issue of migration was= not one we had considered. I was going through this with Kazuho, and we ma= y have identified yet another issue with handshake retransmissions and migr= ation, which is present in the current spec.

=C2=A0

Sadly, I don't think we can call this issue done= ...

=C2=A0

On Tue, Oct 22, 2019 at 2:14 PM Mikkel Fahn=C3=B8e J= =C3=B8rgensen <m= ikkelfj@gmail.com> wrote:

Without a way to move to a single PN space I find th= is a deal breaker. I might do a custom version of the protocol.

=C2=A0

=C2=A0

Fra: QUIC <quic-bounces@ietf.org> p=C3=A5 vegne af = Kazuho Oku <kaz= uhooku@gmail.com>
Sendt: tirsdag, oktober 22, 2019 6:58 AM
Til: Martin Thomson
Cc: IETF QUIC WG
Emne: Re: Consensus Calls for Transport/TLS issues, post-Cupertino <= u>

=C2=A0

=C2=A0

=C2=A0

2019=E6= =9C=8822=E6=97=A5<= /span>(=E7=81=AB) = 11:38 Martin Thomson <mt@lowentropy.net>:

On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote: >=C2=A0 I'd also prefer to fix the problem, even if it means bringin= g back
> something like RETIRE_KEY.

I would prefer to think of this proposed resolution as a temporary one.=C2= =A0 I don't think that we agreed to keep the handshake keys indefinitel= y, only that we would use that option as a fallback position until we found= a better solution.

=C2=A0

I might point out that #3121 is not proposal-ready a= s a way to resolve #2863. That is because it does not define how to send an= d receive Handshake packets until or after migration happens. There would b= e a deadlock unless both endpoints agree on how that should be done (e.g., how to select SCID, whether the pa= th used for Handshake packets migrates too).

=C2=A0

Without that being clarified, can we say that we are= ready for a consensus=C2=A0call?

=C2=A0


On that basis, I think that it would be best if we open a new issue that sa= ys "Handshake keys can't ever be dropped".=C2=A0

We might still conclude not to address that issue, but the important thing = is to ensure that any solution works properly.


=C2=A0

--

Kazuho Oku

--0000000000000765f00595ec60f1-- From nobody Sun Oct 27 16:03:21 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29631200B6 for ; Sun, 27 Oct 2019 16:03:19 -0700 (PDT) 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 EAEpyrivE3JL for ; Sun, 27 Oct 2019 16:03:17 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD6112003E for ; Sun, 27 Oct 2019 16:03:17 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id l21so9284979lje.4 for ; Sun, 27 Oct 2019 16:03:17 -0700 (PDT) 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=z32F3S8lCrjhrsOMybPb2ePJxlbJS8+2aDMV5Wo7RBs=; b=JnTKzirhIyEvsivPEdzmnsG0N6Zj219LKyWuAQAT6wAVnLrQQrLC1uP4CAppBjz8ks 87+DMsUQheqyxlC9uj1K2lkrDkZ7RNBRzWLcsGGuCyryGBc8I/Bt6VJBAHq9dnrsoB4/ BfNMuuF5v8LnM2aGlySx0JZ8EF4dERDKTa1F0Q1Or57Yg/YMjFGuskK4JboBjDdODmPR yvsbnK9Q3BMbqZn83Cprv46Wbb5mqSsfyb/l5piA+vLLuc7uoS66t188xHhPZJCQVZ31 woy5mnfk9mGChD2qC6I394IQlGbngXBm5Lxpd09TgH2dhaDY5mrLuVc8HXmepDEu31xu QQMg== 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=z32F3S8lCrjhrsOMybPb2ePJxlbJS8+2aDMV5Wo7RBs=; b=bkWHpLZamjZHLm9MaCnymsMn9Hc+mU+bZpHr1KDOYKwAQel6UY3lwWuebSDqfgNPBC pjBWQ472Dyn9c/k8kMVNu5DxmaMq1tEGPWpww0qDwR0UCHGxbd0WvYVQqHTyjjpXIYCl eBEPkjH41jgxFy4LZ20l+S//h5u7neXkoiK2faY1AADDbqD+V2LSuNLK2pi9m85bYaC+ Q8ohbpWVQSgjWWMr5/3T4aYblDbRTrgDWQWCqdblCUVOMgTLZqeaG9imkES0SWIRe5KP 4075b04FgfHjdvC4t5eX3zQ2q0y0PkpP2TMhXZncBQfauqd4AUcR+BxILgdD/cIXQ8NM NB4A== X-Gm-Message-State: APjAAAW+JkedU7Uy1S+D7oj9ulmwkhYqoRYm3ZMv3GgO+WK+R6ZS8LPN N5hvyK8w0ynv3n0eHZLEeL8Rug1zU2bZn/eGYR34cg== X-Google-Smtp-Source: APXvYqzv1DboTOX+Kd8uzN9kHtLCE9jS7Vr9VqveiOHxdypAdv6AigpdUHf/aaQA9uZWl6WYFl/upwnmIZPPDX9CVqc= X-Received: by 2002:a2e:8947:: with SMTP id b7mr3832200ljk.29.1572217395446; Sun, 27 Oct 2019 16:03:15 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Sun, 27 Oct 2019 16:02:39 -0700 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Martin Duke Cc: Jana Iyengar , Mike Bishop , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="0000000000005d97780595ec63c7" 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, 27 Oct 2019 23:03:20 -0000 --0000000000005d97780595ec63c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Note that we also can't close 2741 until we resolve 2863. -Ekr On Sun, Oct 27, 2019 at 4:01 PM Eric Rescorla wrote: > I think we're clearly going to need to spend some time on this. I don't > think the spec is satisfactory as-is: we should be designing a transport > that works for all use cases, not just H3. That said, I also don't agree > that we need an additional explicit signal. We have one, it's called "ACK= ". > We should figure out how to make that work. > -Ekr > > > On Fri, Oct 25, 2019 at 9:36 AM Martin Duke > wrote: > >> I agree with the dissenters. The current spec works in the HTTP3 use >> case, though I think we should fix it. Keeping keys forever is >> unsatisfactory for several reasons. We should use an explicit signal, an= d >> there is no reason to kick the can down the road. Let's just leave #2863 >> open till we resolve it. >> >> On Wed, Oct 23, 2019 at 7:40 PM Jana Iyengar wrote: >> >>> Yup. We need to get this over with in the dumbest way possible. >>> >>> On Thu, Oct 24, 2019 at 3:53 AM Mike Bishop >>> wrote: >>> >>>> I think we=E2=80=99ve amply demonstrated that implicit signals don=E2= =80=99t work. I=E2=80=99d >>>> like to see an explicit confirmation of handshake completion that happ= ens >>>> at 1-RTT. >>>> >>>> >>>> >>>> *From:* QUIC *On Behalf Of * David Schinazi >>>> *Sent:* Tuesday, October 22, 2019 4:07 PM >>>> *To:* Jana Iyengar >>>> *Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen ; IETF QUI= C WG < >>>> quic@ietf.org>; Martin Thomson ; Kazuho Oku < >>>> kazuhooku@gmail.com> >>>> *Subject:* Re: Consensus Calls for Transport/TLS issues, post-Cupertin= o >>>> >>>> >>>> >>>> +1 >>>> >>>> >>>> >>>> I think the text we have in the spec today is better than the proposal >>>> to never discard the handshake keys. >>>> >>>> My preference would be to spend the time to fix the issue, and not add >>>> a temporary workaround for now. >>>> >>>> >>>> >>>> On Tue, Oct 22, 2019 at 12:51 AM Jana Iyengar >>>> wrote: >>>> >>>> I agree with Kazuho here. The issue of migration was not one we had >>>> considered. I was going through this with Kazuho, and we may have >>>> identified yet another issue with handshake retransmissions and migrat= ion, >>>> which is present in the current spec. >>>> >>>> >>>> >>>> Sadly, I don't think we can call this issue done... >>>> >>>> >>>> >>>> On Tue, Oct 22, 2019 at 2:14 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen < >>>> mikkelfj@gmail.com> wrote: >>>> >>>> Without a way to move to a single PN space I find this a deal breaker. >>>> I might do a custom version of the protocol. >>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> *Fra:* QUIC p=C3=A5 vegne af Kazuho Oku < >>>> kazuhooku@gmail.com> >>>> *Sendt:* tirsdag, oktober 22, 2019 6:58 AM >>>> *Til:* Martin Thomson >>>> *Cc:* IETF QUIC WG >>>> *Emne:* Re: Consensus Calls for Transport/TLS issues, post-Cupertino >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2019=E5=B9=B410=E6=9C=8822=E6=97=A5(=E7=81=AB) 11:38 Martin Thomson : >>>> >>>> On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote: >>>> > I'd also prefer to fix the problem, even if it means bringing back >>>> > something like RETIRE_KEY. >>>> >>>> I would prefer to think of this proposed resolution as a temporary >>>> one. I don't think that we agreed to keep the handshake keys indefini= tely, >>>> only that we would use that option as a fallback position until we fou= nd a >>>> better solution. >>>> >>>> >>>> >>>> I might point out that #3121 is not proposal-ready as a way to resolve >>>> #2863. That is because it does not define how to send and receive Hand= shake >>>> packets until or after migration happens. There would be a deadlock un= less >>>> both endpoints agree on how that should be done (e.g., how to select S= CID, >>>> whether the path used for Handshake packets migrates too). >>>> >>>> >>>> >>>> Without that being clarified, can we say that we are ready for a >>>> consensus call? >>>> >>>> >>>> >>>> >>>> On that basis, I think that it would be best if we open a new issue >>>> that says "Handshake keys can't ever be dropped". >>>> >>>> We might still conclude not to address that issue, but the important >>>> thing is to ensure that any solution works properly. >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Kazuho Oku >>>> >>>> --0000000000005d97780595ec63c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note that we also can't close 2741 until we resol= ve 2863.

-Ekr


On Sun, Oct 27, = 2019 at 4:01 PM Eric Rescorla <ekr@rtfm.= com> wrote:
I think we're clearly going to need to spend s= ome time on this. I don't think the spec is satisfactory as-is: we shou= ld be designing a transport that works for all use cases, not just H3. That= said, I also don't agree that we need an additional explicit signal. W= e have one, it's called "ACK". We should figure out how to ma= ke that work.
-Ekr


On Fri, Oct 25, 2019= at 9:36 AM Martin Duke <martin.h.duke@gmail.com> wrote:
I agree with the diss= enters. The current spec works in the HTTP3 use case, though I think we sho= uld fix it. Keeping keys forever is unsatisfactory for several reasons. We = should use an explicit signal, and there is no reason to kick the can down = the road. Let's just leave #2863 open till we resolve it.

=
On Wed, Oc= t 23, 2019 at 7:40 PM Jana Iyengar <jri.ietf@gmail.com> wrote:
Yup. We need to get = this over with in the dumbest way possible.

On Thu, Oct 24, 2019 at 3:53 AM = Mike Bishop <m= bishop@evequefou.be> wrote:

I think we=E2=80=99ve amply demonstrated that implic= it signals don=E2=80=99t work.=C2=A0 I=E2=80=99d like to see an explicit co= nfirmation of handshake completion that happens at 1-RTT.

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = David Schinazi
Sent: Tuesday, October 22, 2019 4:07 PM
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; IETF QUIC WG <= quic@ietf.org>; M= artin Thomson <mt= @lowentropy.net>; Kazuho Oku <kazuhooku@gmail.com>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertin= o

=C2=A0

+1

=C2=A0

I think the text we have in the spec today is better= than the proposal to never discard the handshake keys.

My preference would be to spend the time to fix the = issue, and not add a temporary workaround for now.

=C2=A0

On Tue, Oct 22, 2019 at 12:51 AM Jana Iyengar <jri.ietf@gmail.com> wrote:

I agree with Kazuho here. The issue of migration was= not one we had considered. I was going through this with Kazuho, and we ma= y have identified yet another issue with handshake retransmissions and migr= ation, which is present in the current spec.

=C2=A0

Sadly, I don't think we can call this issue done= ...

=C2=A0

On Tue, Oct 22, 2019 at 2:14 PM Mikkel Fahn=C3=B8e J= =C3=B8rgensen <m= ikkelfj@gmail.com> wrote:

Without a way to move to a single PN space I find th= is a deal breaker. I might do a custom version of the protocol.

=C2=A0

=C2=A0

Fra: QUIC <quic-bounces@ietf.org> p=C3=A5 vegne af = Kazuho Oku <kaz= uhooku@gmail.com>
Sendt: tirsdag, oktober 22, 2019 6:58 AM
Til: Martin Thomson
Cc: IETF QUIC WG
Emne: Re: Consensus Calls for Transport/TLS issues, post-Cupertino <= u>

=C2=A0

=C2=A0

=C2=A0

2019=E6= =9C=8822=E6=97=A5<= /span>(=E7=81=AB) = 11:38 Martin Thomson <mt@lowentropy.net>:

On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote: >=C2=A0 I'd also prefer to fix the problem, even if it means bringin= g back
> something like RETIRE_KEY.

I would prefer to think of this proposed resolution as a temporary one.=C2= =A0 I don't think that we agreed to keep the handshake keys indefinitel= y, only that we would use that option as a fallback position until we found= a better solution.

=C2=A0

I might point out that #3121 is not proposal-ready a= s a way to resolve #2863. That is because it does not define how to send an= d receive Handshake packets until or after migration happens. There would b= e a deadlock unless both endpoints agree on how that should be done (e.g., how to select SCID, whether the pa= th used for Handshake packets migrates too).

=C2=A0

Without that being clarified, can we say that we are= ready for a consensus=C2=A0call?

=C2=A0


On that basis, I think that it would be best if we open a new issue that sa= ys "Handshake keys can't ever be dropped".=C2=A0

We might still conclude not to address that issue, but the important thing = is to ensure that any solution works properly.


=C2=A0

--

Kazuho Oku

--0000000000005d97780595ec63c7-- From nobody Sun Oct 27 19:47:17 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5601200FA for ; Sun, 27 Oct 2019 19:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=hDotjiEB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Jp6M7pb7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuO5BcBIuP5i for ; Sun, 27 Oct 2019 19:47:13 -0700 (PDT) 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 526F2120152 for ; Sun, 27 Oct 2019 19:47:12 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A4AB6223A2; Sun, 27 Oct 2019 22:47:10 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 27 Oct 2019 22:47:10 -0400 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 :cc:subject:content-type; s=fm3; bh=/x32oMJ9Y5TShDlrnIfW9amYZpOX BNFLAMhlDxMwJmg=; b=hDotjiEBdLpzBnArwsOT6oghMwrHLfzG3ApUPJpiR/L6 Iwox43qIjrTNcqxbs03UYMKEgfJXYumgHEYuKs5hF85S5h1EfkoX2VL3g4ljeNh1 IVd81hKiCHJZ/hWNKT7fq7uGbv5OgIHcBeyxhITooDSrxQYvqo8/9LwFsX4XqdDO X5CtySNAEsgoOoFI3z60W6w5VJiZSuYNWI/YOwAe/sDxR70jwV+0FVGeds7tNKwl vVvXdlywFdYPqMJ/G6/AvnhjuHj415jv+rIkCvtMW18rBrF1HLGr/m4mv8Wtgb7D /7b5fQl+GjKqGzQ3Zej8cD0IHkWWZJ1FeXfFuOvqYQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=/x32oM J9Y5TShDlrnIfW9amYZpOXBNFLAMhlDxMwJmg=; b=Jp6M7pb76HZnGBxNRCr7hP O81EQC5DYJL1B2sq/0yZbwPjY288s5V0ytwSAfrI917H1i6uo71De8k9m/Me2Zp4 hWonIN77YBjRT6QtfUurYHNl7uzrkX31Ei6v6vainTa/BTIKr/C4R9xzQsLdVmZJ cSczFltuCKynMfMZTN3bNW0oLoHgLVXFvlZvvqcKuntz8QpQmO+JY/i/P1dfF+K3 YbQiy6bnBs4pxyCT6HilQrSjLu76bIKxnTEmpQg0rbBjDVJ+Oh8SlMc3vobo20uO 3eMfQgERb42rmJdYrM71xwvJrUnArF9ogS5IVxaLXi5qdxPi8zmgLSs1+Dr7KFyg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrleekgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 22C68E00A3; Sun, 27 Oct 2019 22:47:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> In-Reply-To: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> Date: Mon, 28 Oct 2019 13:46:51 +1100 From: "Martin Thomson" To: "'Eric Rescorla'" , "Martin Duke" Cc: "Jana Iyengar" , "Mike Bishop" , "David Schinazi" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "IETF QUIC WG" , "Kazuho Oku" Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino 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: Mon, 28 Oct 2019 02:47:15 -0000 On Mon, Oct 28, 2019, at 10:01, Eric Rescorla wrote: > I think we're clearly going to need to spend some time on this. I don't > think the spec is satisfactory as-is: we should be designing a > transport that works for all use cases, not just H3. That said, I also > don't agree that we need an additional explicit signal. We have one, > it's called "ACK". We should figure out how to make that work. I think that we've established that ACK doesn't work without something to push it along. From nobody Mon Oct 28 06:58:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8312C120115 for ; Mon, 28 Oct 2019 06:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 55ONkFE8yKJz for ; Mon, 28 Oct 2019 06:57:58 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20085.outbound.protection.outlook.com [40.107.2.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1129F120113 for ; Mon, 28 Oct 2019 06:57:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=glZZpCI7bBBwD1QJ/9GBzjzIGO69IK2g4AUOvo6MfxjZjeTZCPwtmZ+IeXSksF2kMKd/B9vSFsdCrSbDCwyvw151RL9Vc6YACAbhgegqgSCZ2z/M6mZKyRV/NYQMaonNKqJlBtWUiXa/kyz3tpuWR6drCM94knKyqC2SXvqyQdcvn9nKrVwyFdBqyVsYNLVhipAFBIKLNKQjxqUmd5hpHZzhaag4gog3zQSC9p/IK5HSSDXjFQP50Nv1zPMEzlGHO4N7HHa75UAtAB+BMTsioa31MU1XujqOgxeMfKmtTD33eFo8hLkiq+YMQMDl35JmQT19SM99JkokCjObdE7LNg== 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=MXQMnZypiJnF38NQ8KF2vfAlZEXm75ctIy1AtvJrkYs=; b=Rc1A6gjPeztB7GEPfY4kiqDc3Wpm73ff+nckzDecXXowHD6TbX6KmRQ8u4j1sK7g2mJcQE9h6QRkEZn4bVfy8zXeh2A/jUg3r3tDyyyGGiZa/SNw9wvIukJHWZ3t2yC5m3yUstw6KVub4CVVRUCSkbo+NfaQa8K2YzJev9pcaJbLI5X6OJbf353MJxjUoE7lK88FWLsQQ14pC6On0rSOL5GXFMAXnh4DOU38hExVlFHb9LqJrk/GVxA4FieADLIbGRjLDXTsTRSbFdOag4ipj4gIPC1K1kjvi8QMflVAx7PG08qcGR0dQ+vF+StEGRJZ5gr1XIkH8eEjao/o5TLnYA== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MXQMnZypiJnF38NQ8KF2vfAlZEXm75ctIy1AtvJrkYs=; b=Lg8R46rNWnI6anmoeVYlslNjcgdMedej7TXBEOhPP5SgeqPAhuH6bk7Y7It8aJ9Ns6KKlwU/7ibo0+Z2pSZfj6emRpClYSMGEou4KYIAEyTgLl4VzyX/FDMFBqgPGTgAt8zCwfWsIQccWRDX5rzUcYaVTEiM689OK3Py9Kw61sE= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB4081.eurprd07.prod.outlook.com (52.134.86.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.14; Mon, 28 Oct 2019 13:57:55 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4573:6a4c:8bb5:1456]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4573:6a4c:8bb5:1456%5]) with mapi id 15.20.2387.021; Mon, 28 Oct 2019 13:57:55 +0000 From: Mirja Kuehlewind To: Ryan Hamilton , David Schinazi , Martin Thomson CC: QUIC Subject: Re: Making QUIC less constraining for innovation Thread-Topic: Making QUIC less constraining for innovation Thread-Index: AQHVihr5J4TvUgA3aU+ZJMysrDnj9KdpNBgAgAANYACAAAWDAIAADFuAgADS/ACAAFojAIAARmmAgAAgxQCAAIJ5gIAAJ86AgAAh0gCAAG60gIAAB0SAgAAN/ACAA/RCgA== Date: Mon, 28 Oct 2019 13:57:55 +0000 Message-ID: <63441659-6CD9-40EC-827F-D9AD56F68837@ericsson.com> References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@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:2cf8:6d00:79e2:9245:1e40:657f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 82ad6513-2f4e-41bc-0d40-08d75baed522 x-ms-traffictypediagnostic: AM0PR07MB4081: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(376002)(396003)(136003)(346002)(189003)(199004)(561944003)(86362001)(44832011)(46003)(486006)(476003)(2616005)(11346002)(446003)(36756003)(6506007)(76176011)(7736002)(186003)(4326008)(99286004)(14444005)(81166006)(5024004)(5660300002)(76116006)(71200400001)(71190400001)(66946007)(66556008)(8936002)(81156014)(8676002)(256004)(64756008)(66476007)(66446008)(110136005)(33656002)(478600001)(14454004)(316002)(25786009)(229853002)(6486002)(2906002)(6246003)(6512007)(54896002)(6306002)(236005)(6436002)(6116002)(53546011)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4081; 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: ltJnSDxK8cSjaikNsapUqsnPLvxhjS9lG04XqhqnTDqithHrqoEryqi6kYDJNA7frfrEjSto39eglb7HQ/oQj4hfpJxMYyhSQPoG1mOfX9o3SA7pvVVYEh2D9M2HAS86jYJCX9cBusC7WkCpyswOUJqVJt05ZVP3FXB6bNOerAV9Ujv33Od0CfXD2vmnIToRlsmEopKQ0Jo8Yspz4kH+1huOnM1EyaLoShd55Rv+Nj/k9yl4Zprtzt/Oc2YMj+6ia2v8PLVzkmm7hpTg/GJLl0SiBX3Vxo3a7h8XIJ/NiGyEEtQodEyYaO1tNG8K0JAYf5y7g8dgwJYHb6OaDkFTFJAcvhLQibuRzGvvODnAAZJJrF9Euu4mvkyrlke6iWYyk1X4fGu460Jz+H7uKFkVsfbLPQhLoU8p4N1rArd6WX0bd3yDbZQaZCyox1e8vNu9 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_634416596CD940EC827FD9AD56F68837ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 82ad6513-2f4e-41bc-0d40-08d75baed522 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2019 13:57:55.3190 (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: 1wqbEuIId6RXz3UQzZDv7jS2IOxqWYXovvOa+marpmdgtcXBJfpqwoPpUDtMxLKGwubkf0BSe9dIZoq0YNL+ACCUXoVgPaOrnU16pEB4EoE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4081 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, 28 Oct 2019 13:58:01 -0000 --_000_634416596CD940EC827FD9AD56F68837ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SUFOQSB3aWxsIHVzdWFsbHkgYWx3YXlzIHJlcXVpcmUgc29tZSBjb250YWN0IGluZm9ybWF0aW9u IGJlY2F1c2UgdXN1YWxseSB0aGV5IHdvdWxkIGxpa2UgdG8gYXQgbGVhc3QgdGVsbCB5b3UgaWYg eW91ciByZXF1ZXN0IHdhcyByZWdpc3RlcmVkIG9yIG5vdCAoZm9yIHdoYXRldmVyIHJlYXNvbiku IEhvd2V2ZXIsIGlmIHdlIHNob3VsZCBwdWJsaXNoIHRoaXMgY29udGFjdCBpbmZvcm1hdGlvbiBp biB0aGUgcmVnaXN0cnkgaXMgYSBkaWZmZXJlbnQgcXVlc3Rpb24uDQoNCg0KRnJvbTogUnlhbiBI YW1pbHRvbiA8cmNoPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IFNhdHVyZGF5 LCAyNi4gT2N0b2JlciAyMDE5IGF0IDA0OjM1DQpUbzogRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6 aS5pZXRmQGdtYWlsLmNvbT4NCkNjOiBNYXJ0aW4gVGhvbXNvbiA8bXRAbG93ZW50cm9weS5uZXQ+ LCBNaXJqYSBLdWVobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbT4sIFFVSUMg PHF1aWNAaWV0Zi5vcmc+LCBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4s IFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPg0KU3ViamVjdDogUmU6IE1ha2luZyBRVUlDIGxl c3MgY29uc3RyYWluaW5nIGZvciBpbm5vdmF0aW9uDQoNClJlcXVpcmluZyBjb250YWN0IGluZm9y bWF0aW9uIChrbm93aW5nIHRoYXQgaXQgbWlnaHQgYmUgc3RhbGUpIHNvdW5kcyBncmVhdC4gQXNr aW5nIGZvciBhIGNvbXBsZXRlbHkgb3B0aW9uYWwgZGVzY3JpcHRpb24gYWxzbyBzb3VuZHMgZ29v ZCB0byBtZS4NCg0KT24gRnJpLCBPY3QgMjUsIDIwMTkgYXQgNjo0NSBQTSBEYXZpZCBTY2hpbmF6 aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPG1haWx0bzpkc2NoaW5hemkuaWV0ZkBnbWFpbC5j b20+PiB3cm90ZToNCkJ5IHByb3Zpc2lvbmFsLCBkbyB5b3UgbWVhbiB0aGF0IHRoZXnigJlkIGV4 cGlyZSBhZnRlciBzb21lIHRpbWU/IEnigJltIG5vdCBzdXJlIHRoYXTigJlzIHNhdGlzZmFjdG9y eSBmb3IgdW5kb2N1bWVudGVkIHByb3ByaWV0YXJ5IGV4dGVuc2lvbnMuDQoNClJlcXVpcmluZyBj b250YWN0IGluZm9ybWF0aW9uIGRvZXNu4oCZdCBzb3VuZCBsaWtlIG11Y2ggb2YgYSBodXJkbGUg dGhvdWdoLCBJ4oCZbSBoYXBweSB3aXRoIHRoYXQuDQoNCg0KT24gRnJpLCBPY3QgMjUsIDIwMTkg YXQgMTg6MTkgTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0PG1haWx0bzptdEBsb3dl bnRyb3B5Lm5ldD4+IHdyb3RlOg0KT24gU2F0LCBPY3QgMjYsIDIwMTksIGF0IDA1OjQyLCBEYXZp ZCBTY2hpbmF6aSB3cm90ZToNCj4gSSBkb24ndCB0aGluayByZXF1aXJpbmcgZm9sa3MgdG8gZG9j dW1lbnQgdGhlaXIgZXh0ZW5zaW9ucyBpcyByZWFsaXN0aWMuDQoNCk5vdGhpbmcgaW4gdGhlIHBy b3Bvc2FsIHJlcXVpcmVkIHRoYXQgdGhleSBiZSBkb2N1bWVudGVkLiAgSSBwcm9wb3NlZCB0byBo YXZlIHByb3Zpc2lvbmFsIHJlZ2lzdHJhdGlvbnMgZXhwbGljaXRseSBhbGxvdyBmb3IgcmVnaXN0 cmF0aW9ucyB3aXRoIG5vIGluZm9ybWF0aW9uIGF0dGFjaGVkLg0KDQpBcyBhbiBhc2lkZSwgSSB0 aGluayB3ZSBtaWdodCB3YW50IHRvIHJlcXVpcmUgY29udGFjdCBpbmZvcm1hdGlvbiwgd2hpY2gg aXMgKEkgdGhpbmspIG5vcm1hbCBwcmFjdGljZSBmb3IgcmVnaXN0cmllcy4gIEkgZG9uJ3QgdGhp bmsgdGhhdCB3ZSBzaG91bGQgaW5zaXN0IG9uIHRoYXQgY29udGFjdCBpbmZvcm1hdGlvbiBiZWlu ZyAiZ29vZCI7IHRoZXJlJ3Mgbm8gZ3VhcmFudGVlIHRoYXQgaXMgcmVtYWlucyB0aGF0IHdheSBl dmVuIGlmIHdlIGRpZCB3YW50IHRvIHRlc3QgaXQuDQo= --_000_634416596CD940EC827FD9AD56F68837ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJ0cmVidWNo ZXQgbXMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SUFOQSB3aWxsIHVzdWFsbHkgYWx3YXlz IHJlcXVpcmUgc29tZSBjb250YWN0IGluZm9ybWF0aW9uIGJlY2F1c2UgdXN1YWxseSB0aGV5IHdv dWxkIGxpa2UgdG8gYXQgbGVhc3QgdGVsbCB5b3UgaWYgeW91ciByZXF1ZXN0IHdhcyByZWdpc3Rl cmVkIG9yIG5vdCAoZm9yIHdoYXRldmVyIHJlYXNvbikuIEhvd2V2ZXIsIGlmDQogd2Ugc2hvdWxk IHB1Ymxpc2ggdGhpcyBjb250YWN0IGluZm9ybWF0aW9uIGluIHRoZSByZWdpc3RyeSBpcyBhIGRp ZmZlcmVudCBxdWVzdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlJ5YW4gSGFtaWx0b24gJmx0O3JjaD00 MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlNhdHVyZGF5 LCAyNi4gT2N0b2JlciAyMDE5IGF0IDA0OjM1PGJyPg0KPGI+VG86IDwvYj5EYXZpZCBTY2hpbmF6 aSAmbHQ7ZHNjaGluYXppLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+TWFydGlu IFRob21zb24gJmx0O210QGxvd2VudHJvcHkubmV0Jmd0OywgTWlyamEgS3VlaGxld2luZCAmbHQ7 bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20mZ3Q7LCBRVUlDICZsdDtxdWljQGlldGYub3Jn Jmd0OywgQ2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7LCBSb2Jl cnRvIFBlb24gJmx0O2Zlbml4QGZiLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IE1h a2luZyBRVUlDIGxlc3MgY29uc3RyYWluaW5nIGZvciBpbm5vdmF0aW9uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O3RyZWJ1Y2hldCBtcyZxdW90OyxzYW5zLXNlcmlmIj5S ZXF1aXJpbmcgY29udGFjdCBpbmZvcm1hdGlvbiAoa25vd2luZyB0aGF0IGl0IG1pZ2h0Jm5ic3A7 YmUgc3RhbGUpIHNvdW5kcyBncmVhdC4gQXNraW5nIGZvciBhIGNvbXBsZXRlbHkgb3B0aW9uYWwg ZGVzY3JpcHRpb24gYWxzbyBzb3VuZHMgZ29vZCB0byBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIEZyaSwgT2N0IDI1LCAyMDE5 IGF0IDY6NDUgUE0gRGF2aWQgU2NoaW5hemkgJmx0OzxhIGhyZWY9Im1haWx0bzpkc2NoaW5hemku aWV0ZkBnbWFpbC5jb20iPmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5CeSBwcm92aXNpb25hbCwg ZG8geW91IG1lYW4gdGhhdCB0aGV54oCZZCBleHBpcmUgYWZ0ZXIgc29tZSB0aW1lPyBJ4oCZbSBu b3Qgc3VyZSB0aGF04oCZcyBzYXRpc2ZhY3RvcnkgZm9yIHVuZG9jdW1lbnRlZCBwcm9wcmlldGFy eSBleHRlbnNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPlJlcXVpcmluZyBjb250YWN0IGluZm9ybWF0aW9uIGRvZXNu4oCZdCBz b3VuZCBsaWtlIG11Y2ggb2YgYSBodXJkbGUgdGhvdWdoLCBJ4oCZbSBoYXBweSB3aXRoIHRoYXQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBGcmksIE9jdCAyNSwgMjAxOSBhdCAxODoxOSBNYXJ0 aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm10QGxvd2VudHJvcHkubmV0IiB0YXJnZXQ9 Il9ibGFuayI+bXRAbG93ZW50cm9weS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPk9uIFNhdCwgT2N0IDI2LCAyMDE5LCBhdCAwNTo0MiwgRGF2aWQgU2NoaW5h emkgd3JvdGU6PGJyPg0KJmd0OyBJIGRvbid0IHRoaW5rIHJlcXVpcmluZyBmb2xrcyB0byBkb2N1 bWVudCB0aGVpciBleHRlbnNpb25zIGlzIHJlYWxpc3RpYy48YnI+DQo8YnI+DQpOb3RoaW5nIGlu IHRoZSBwcm9wb3NhbCByZXF1aXJlZCB0aGF0IHRoZXkgYmUgZG9jdW1lbnRlZC4mbmJzcDsgSSBw cm9wb3NlZCB0byBoYXZlIHByb3Zpc2lvbmFsIHJlZ2lzdHJhdGlvbnMgZXhwbGljaXRseSBhbGxv dyBmb3IgcmVnaXN0cmF0aW9ucyB3aXRoIG5vIGluZm9ybWF0aW9uIGF0dGFjaGVkLjxicj4NCjxi cj4NCkFzIGFuIGFzaWRlLCBJIHRoaW5rIHdlIG1pZ2h0IHdhbnQgdG8gcmVxdWlyZSBjb250YWN0 IGluZm9ybWF0aW9uLCB3aGljaCBpcyAoSSB0aGluaykgbm9ybWFsIHByYWN0aWNlIGZvciByZWdp c3RyaWVzLiZuYnNwOyBJIGRvbid0IHRoaW5rIHRoYXQgd2Ugc2hvdWxkIGluc2lzdCBvbiB0aGF0 IGNvbnRhY3QgaW5mb3JtYXRpb24gYmVpbmcgJnF1b3Q7Z29vZCZxdW90OzsgdGhlcmUncyBubyBn dWFyYW50ZWUgdGhhdCBpcyByZW1haW5zIHRoYXQgd2F5IGV2ZW4gaWYgd2UgZGlkDQogd2FudCB0 byB0ZXN0IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_634416596CD940EC827FD9AD56F68837ericssoncom_-- From nobody Mon Oct 28 10:56:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515911208AA for ; Mon, 28 Oct 2019 10:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, SPF_PASS=-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 vnenUiSsUdz1 for ; Mon, 28 Oct 2019 10:55:56 -0700 (PDT) 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 0B64C120811 for ; Mon, 28 Oct 2019 10:55:55 -0700 (PDT) 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 x9SHkbbp020001; Mon, 28 Oct 2019 10:55:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=V+VRlQKGJf6l6MCYxJ8Gn+KYi3wV0vp3dKZcZyskA1s=; b=v98ilv4BNxWYTvG5mDWvBYztjYV8E30TuiwL4+KYuttqiuUZ+l6cmKJb1rkdUP5OWl7V bLpWCRlYme37JykhuIWVJKo9oG0BywDni1whnJat/Q6Pos1rs83qkOt5NPmFJWN9bnuQ Xz6feBeFKyksDKk+bOq4v9/qz/6HrWOtPNsPGKsZafjML/4J7bOPkK3T1Pd3ODBPlZIX +93v+uTHFYGUF3rBu7wIlUhn99Gu6ESSRgN93vaKOLI5Nzg49kuRGQ3t1XWdd99V5tyh FaXwPPU7nYeUWcCLcQ77dcniVYVoL0kdu74vkAo1El8o13W/uTV24o9j2etWXckaeAAs 4g== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2vvjttv0u6-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 28 Oct 2019 10:55:48 -0700 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q03003J3J4ZHKJ0@mr2-mtap-s02.rno.apple.com>; Mon, 28 Oct 2019 10:55:47 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q0300800IKOLB00@nwk-mmpp-sz11.apple.com>; Mon, 28 Oct 2019 10:55:47 -0700 (PDT) X-Va-A: X-Va-T-CD: fd7fa2cf43a24f878f649a9cdf606cb8 X-Va-E-CD: 89bb43c2003224987ed6b5bdbed65e06 X-Va-R-CD: 4fc418629693d47b682100bd5d2f5567 X-Va-CD: 0 X-Va-ID: 6b3e0e8f-c4dc-42a4-837d-96bca2c205f0 X-V-A: X-V-T-CD: fd7fa2cf43a24f878f649a9cdf606cb8 X-V-E-CD: 89bb43c2003224987ed6b5bdbed65e06 X-V-R-CD: 4fc418629693d47b682100bd5d2f5567 X-V-CD: 0 X-V-ID: 3aea5a91-6ce6-4141-8a7b-b0b70cec59d3 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-28_07:,, signatures=0 Received: from [17.234.75.195] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q0300BCRJ4L7B50@nwk-mmpp-sz11.apple.com>; Mon, 28 Oct 2019 10:55:34 -0700 (PDT) Sender: rpaulo@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Re: Making QUIC less constraining for innovation From: Rui Paulo In-reply-to: Date: Mon, 28 Oct 2019 10:55:33 -0700 Cc: David Schinazi , Mirja Kuehlewind , QUIC , Christian Huitema , Roberto Peon , Martin Thomson Content-transfer-encoding: quoted-printable Message-id: References: <3fcdd338-acf1-48df-9527-84b0fa4a71be@www.fastmail.com> <3DDC7ED2-B9E4-4FF2-B8BB-7F84D4A049FC@ericsson.com> To: Ryan Hamilton X-Mailer: Apple Mail (2.3594.4.19) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-28_07:, , 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: Mon, 28 Oct 2019 17:56:05 -0000 On Oct 25, 2019, at 19:34, Ryan Hamilton = wrote: >=20 > Requiring contact information (knowing that it might be stale) sounds = great. Asking for a completely optional description also sounds good to = me. I agree. This has the advantage that if an extension has a description, = I might read it and realize someone else already solved the problem = I=E2=80=99m trying to solve. I could then reach out to that person and = perhaps I won=E2=80=99t re-invent the wheel... =E2=80=94 Rui Paulo From nobody Mon Oct 28 12:50:09 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D794612006D for ; Mon, 28 Oct 2019 12:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 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, FSL_HELO_FAKE=1.797, 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 p8ttTKW2Spi0 for ; Mon, 28 Oct 2019 12:50:06 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 1C24F12004E for ; Mon, 28 Oct 2019 12:50:06 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id z22so16387112qtq.11 for ; Mon, 28 Oct 2019 12:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=u+UyLvGdzP8Y0PkN6x3iQzQy9k6eN942dzULXdAU4ms=; b=GVtBxTgYCmSPYt7zrFgYvOg4sPvFSvuImKXAMxvsVytolX/3m+DVkCdj/RASh2I/86 xHn/5AAAUAC+ImzonaLFvBZy6lSQoYiV/bNs3B3CssDBnxwbnwr7aNLrq0VRHJX3B0sV ST2r7dvQ/DFWTJxBAF9hZHmZQAXx3SYyxjMFU2+ZZseqCLgPGG+sWzEILcbM8hMa/yM8 9eFvLODkUFFxKmWhn8p5N+F6RIvAvZp74MxRd8goDFeCLmu945aDuAof95eaHwBYUQJb 1aq6iPix9cRcF+eQlmCHjlsIV2hMJXLVhPG6A4mKNsUnXS3wXf5uXCkjA2lvpthfG5xM ic2Q== 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:mime-version :content-disposition:user-agent; bh=u+UyLvGdzP8Y0PkN6x3iQzQy9k6eN942dzULXdAU4ms=; b=LPm71kxZW0S7EQuZbqENbAVUCRgwdyAcFUrfNFPxOG81lK18Gdw1eMMn1GxIQGn3nk KFnY7lLlPizLX6YD53zmFrtcvXTlgx8S08abiGI5g7O+IPa56ZjzPiU77JK7O2+0ir98 uEbelfscsrnnZQcQJ/zNFx++rk9bjgUDIy7HY7k0VrWNn49DYLn1z6LiDpGV/6jxmbF/ T6Trknvw3opE7R6obTldUMBMf0z/XOkspCTN/AjSqcf+Hs4IVxq9fUDtuivjYeTv7asY 1MZPYTw4WuPqZKLGkkkf6i65L/S9w5LWjd2MDdJN+PeIlZoApDdeNAx44TDWZNQIfh8f 4dng== X-Gm-Message-State: APjAAAXGaJ55Ivo6KsMHF0Mg6oH8TPgWY4GIylm8isg3m4gYv4XMdnS2 eJn6uXkpIQ1UccuIJtsUSisnAKOCjso= X-Google-Smtp-Source: APXvYqwUqLW1K+l0NpW+Ma7dhr9OUsYaiLqqmRux465mrfCnAN3KBq2iyenvKjOzNgFInGZo25od/A== X-Received: by 2002:aed:31c7:: with SMTP id 65mr142037qth.379.1572292204731; Mon, 28 Oct 2019 12:50:04 -0700 (PDT) Received: from gmail.com (pool-74-104-133-20.bstnma.fios.verizon.net. [74.104.133.20]) by smtp.gmail.com with ESMTPSA id o3sm9677175qtf.84.2019.10.28.12.50.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 28 Oct 2019 12:50:03 -0700 (PDT) Date: Mon, 28 Oct 2019 15:49:56 -0400 From: Sowmini Varadhan To: quic@ietf.org, martin.h.duke@gmail.com, nibanks@microsoft.com Cc: sovaradh@microsoft.com Subject: draft-duke-quic-load-balancers-05.txt Message-ID: <20191028194956.GC420@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) 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, 28 Oct 2019 19:50:08 -0000 Hi Martin, Nick, I read through https://www.ietf.org/id/draft-duke-quic-load-balancers-05.txt and had a few comments and questions.. - (Editorial) s/encoding/encode at line 306 in Section 2.4 302 2.4. Load Balancer Chains 303 304 While it is possible to construct a scheme that supports multiple 305 low-state load balancers in the path, by using different parts of the 306 connection ID to encoding routing information for each load balancer, : - Section 3.2: Config rotation is one octet (per Section 3.3) and there are 2 bits for config rotation, so it is confusing when Section 3.2 says 361 received these, it MUST generate connection IDs with the config 362 rotation bits set to '0b11' and MUST use the "disable_migration" (0b11 is 2 bytes? In general, it would help to provide more context about what/when/how this can happen, and why it is needed) - Section 4 ("Routing Algorithms"). The 0-RTT can have application data. Given that Section 4 discusses an "alternate algorithm" for 0-RTT, is it possible that the data from 0-RTT gets routed differently than the remainder of the packet? - (Editorial) The third paragraph in Section 4.1.2 referes to a "figure below" that seems to be missing? I am referring to the lines below: 457 4.1.2. Server Actions : 468 The figure below clarifies the format. The first two bits are 469 reserved for config rotation. The server can assign the next 6 bit : - General editorial comment: missing a defintions section for acronyms like SCID and token. I realize that the Normative reference here is [QUIC-TRANSPORT] but it may be helpful to include a cheat-sheet of the main concepts like Initial, 0-RTT, Retry, SCID, Token (to name a few) - Section 4.3.1 refers to "token". Is this the token from the Initial? From the Retry? The LB is just a service in the middle, between the 2 quic endpoints, so it would help to explain which token to use. To be clear, I am referring to: 604 The load balancer decrypts the server ID using 128-bit AES Electronic 605 Codebook (ECB) mode, much like QUIC header protection. The nonce 606 octets are padded to 16 octets using the as many of the first octets 607 of the token as necessary. AES-ECB encrypts this nonce using its key 608 to generate a mask which it applies to the encrypted server id. - Editorial: s/decrypts/encrypts in second paragraph of Section 4.3.2: 631 4.3.2. Server Actions : 640 The server decrypts the server ID using 128-bit AES Electronic 641 Codebook (ECB) mode, much like QUIC header protection. The nonce - Section 5: this one was particularly hard for me to read. I think it would help if this section of the draft hsd a top-level discussion on why this is needed (i.e., what are the sort of things that can go wrong if it is not there? Also, in Figure 5, why do we need to encode ODCIL and ODCID in the Retry token, given that they are already there in the Retry packet itself?) --Sowmini From nobody Mon Oct 28 16:34:58 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CE1120059 for ; Mon, 28 Oct 2019 16:34:55 -0700 (PDT) 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 xZew_8LAJ9p2 for ; Mon, 28 Oct 2019 16:34:54 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 EBE75120033 for ; Mon, 28 Oct 2019 16:34:53 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id j5so2738046lfh.10 for ; Mon, 28 Oct 2019 16:34:53 -0700 (PDT) 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=nRi6Eknq63m8b9rP9VTgYm5iZvTDAQ3rJMpBOEdV+nk=; b=xqlqrgEJP0UWCntmsOCi+YPL76XPFEpJjUewNHA9TJJ2+mGKQDezjOCgm75uepCO4t RHJZeXZKiPEIigEC6IYFxO2md6f5YVLloMnkWZw/kfOjv3e1oC8k66kggDLIecM26jnm 9uOwJAJLWO7Z2lqoZXQoNCfxMKnuy/KhUtMrT3F5/vpaOudzq4L0fQHhLs/BeyliG41I zr6mACV7tlx5UHj0kUONXYa211xqk1Bgy8bO8HwZIulPEqORZiwUWw2rXos0MpshfavA Ae4t3JRfnEcGDv+T+GYB3WuxRLmyXV0PRh+0lsalVQsoksIgeoqbQKpm0AYFHVWquAJU A91g== 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=nRi6Eknq63m8b9rP9VTgYm5iZvTDAQ3rJMpBOEdV+nk=; b=Pex9A8M6x6Q7cQI1p1aV+4fhhni+DEZU4W1VVng2tzCwibevltIMRcdHaHF8y0k5Lr pqzI203j/CxLtVbqUnZpjPzD4o5SDRspZy1NIyjWG2jmFsUOLtJjrdEM35jNI3ubk4Rg 4OsHB5daLFETqbqnCq8kF4BE57TznPxZRcTU9lE3dma7BqLzt8dR3zv1cAAA1qAtolEM HibEpydSlIeDesvnPS5BdL+2YbhRI5m51qB7Md6/jOzUiUqvBtWaBSrTwW9wK36uXjgo DQrMQniHGx70gb+hTtAUjjA5pMkIb8sBwG+03L08nA32yjOiVVzlUTtvqoPRB3LvRSAv 2Myw== X-Gm-Message-State: APjAAAUkTk7hJ1wBskbm6WZV554LdTfJv5CW2Dodgfckqxb1UPjN6l6G 2PtdIkCRkz6FoSVbGvxndjPL1ECJfGK/SJjmjOBe2Q== X-Google-Smtp-Source: APXvYqyIDwLjNxO5a12eqQQg2O1vvX9FKOhDQmBCBmIbXh+78ouVfVDBWjDYtU/b+UWgD15aXbRUnh30bH+avzt72q4= X-Received: by 2002:a19:6d19:: with SMTP id i25mr231491lfc.178.1572305692238; Mon, 28 Oct 2019 16:34:52 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> In-Reply-To: <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> From: Eric Rescorla Date: Mon, 28 Oct 2019 16:34:16 -0700 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Martin Thomson Cc: Martin Duke , Jana Iyengar , Mike Bishop , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Kazuho Oku Content-Type: multipart/alternative; boundary="00000000000043bc68059600f212" 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, 28 Oct 2019 23:34:56 -0000 --00000000000043bc68059600f212 Content-Type: text/plain; charset="UTF-8" On Sun, Oct 27, 2019 at 7:47 PM Martin Thomson wrote: > On Mon, Oct 28, 2019, at 10:01, Eric Rescorla wrote: > > I think we're clearly going to need to spend some time on this. I don't > > think the spec is satisfactory as-is: we should be designing a > > transport that works for all use cases, not just H3. That said, I also > > don't agree that we need an additional explicit signal. We have one, > > it's called "ACK". We should figure out how to make that work. > > I think that we've established that ACK doesn't work without something to > push it along. No, I don't agree with that assessment. -Ekr --00000000000043bc68059600f212 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 27, 2019 at 7:47 PM Marti= n Thomson <mt@lowentropy.net>= ; wrote:
On Mon,= Oct 28, 2019, at 10:01, Eric Rescorla wrote:
> I think we're clearly going to need to spend some time on this. I = don't
> think the spec is satisfactory as-is: we should be designing a
> transport that works for all use cases, not just H3. That said, I also=
> don't agree that we need an additional explicit signal. We have on= e,
> it's called "ACK". We should figure out how to make that= work.

I think that we've established that ACK doesn't work without someth= ing to push it along.

No, I don't agree= with that assessment.

-Ekr

--00000000000043bc68059600f212-- From nobody Mon Oct 28 20:32:22 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FA9120047 for ; Mon, 28 Oct 2019 20:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=lowentropy.net header.b=ctiNxJFp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rBCktFuM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45sOcuHReCHb for ; Mon, 28 Oct 2019 20:32:20 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A9E120046 for ; Mon, 28 Oct 2019 20:32:19 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E973B218C1; Mon, 28 Oct 2019 23:32:18 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 28 Oct 2019 23:32:18 -0400 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 :cc:subject:content-type; s=fm3; bh=h0VUAiivffAA1NwGwNrbwefOxAjm ATlTUeymLro6wsw=; b=ctiNxJFpLH/Tn36Y6Mn52IL3z7HEcwcATmCnCZXEjU4p UOz0jkufFS2jlfkqWDGVkXaRseOqUFDDlQSZHkeL1IKj3X/yQUFYQIib5iAsw4/7 wXbUZ+K+RJozH+JXdZ8BsA/DxetOKQM/BwjNRTTe11hXhvjCvDdqodICUFSQKpk3 c1gaCZqdHgbZbN9yI6ydGEFFMXT5rDcCs90LfabPRgWXO4Pb6CSu3wTz9wxSV6vk YOYt5rbKJ2tGG8gixlrZjMLLyheHGcX0R8/0iSpmBRYYnUCRiP4Zg6XqE7ZeOeGQ 01OSpMCQmYaPGxoKqZrno6kGCFxmwVOo0WAwC4OEuQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=h0VUAi ivffAA1NwGwNrbwefOxAjmATlTUeymLro6wsw=; b=rBCktFuMDAwBaIPYTcyS91 QnhN/4RyV3r4RSV/nYGbphyiA5CI3/u/6wocysWmCnhIM6OxMsaW4OswZG1JJwzp HtyX5oD5wFBA7dlsoGnzAZRiMzlg5S5Ed44x01sSiHgwaFXhNujip/joz6NCtQjg FW/O8X7MRsXhd5ZvntEwDbvQQpPurNoQp70B9KAUrIPe8QjAzyY6o9ohoFDonnxA rsqDGzJ3JX0TbAEShN6/5pym31Z01b5jT45VV/m6G6O6u5R4gxMp5NxzoknSnBSA 6c883zbmsjpPCy5tlA3nBmw/0lChXVv2k6pznBCg1xAQVS9gMgN+YNGIMHtZNqog == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddttddgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurf grrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 802D6E00A1; Mon, 28 Oct 2019 23:32:14 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-512-g193a140-fmstable-20191028v1 Mime-Version: 1.0 Message-Id: <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> In-Reply-To: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> Date: Tue, 29 Oct 2019 14:31:54 +1100 From: "Martin Thomson" To: "'Eric Rescorla'" Cc: "Martin Duke" , "Jana Iyengar" , "Mike Bishop" , "David Schinazi" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "IETF QUIC WG" , "Kazuho Oku" Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino 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: Tue, 29 Oct 2019 03:32:22 -0000 On Tue, Oct 29, 2019, at 10:34, Eric Rescorla wrote: > On Sun, Oct 27, 2019 at 7:47 PM Martin Thomson wrote: > > On Mon, Oct 28, 2019, at 10:01, Eric Rescorla wrote: > > > I think we're clearly going to need to spend some time on this. I don't > > > think the spec is satisfactory as-is: we should be designing a > > > transport that works for all use cases, not just H3. That said, I also > > > don't agree that we need an additional explicit signal. We have one, > > > it's called "ACK". We should figure out how to make that work. > > > > I think that we've established that ACK doesn't work without something to push it along. > > No, I don't agree with that assessment. Well, I'd like some proof. I shared what I believe to be proof earlier. Happy to walk through it again though. From nobody Tue Oct 29 11:26:58 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE1C120B50 for ; Tue, 29 Oct 2019 11:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=ham 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 RqtyMgNhvB2l for ; Tue, 29 Oct 2019 11:26:53 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720109.outbound.protection.outlook.com [40.107.72.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2B0120B61 for ; Tue, 29 Oct 2019 11:26:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IUAWKIhJeiiF1HTXOdnoQJBWCFkevY6Ze3kr6hejHie59tIF9i2rq5x4Sk4ONBWqevEjeYUK8ImfD4JX2nVE3JSqgV7lsZ8DnDnwMSVcQ7uplQrCNOKK2eu+IXzcmYkvMlBm4Z2Lb62WoTDdZJcJGeyZ7CnM2/hy18KRc2YzuwdZadXbDh3F2ddL4y/Vm28vbu0+qpWu/yssldfvvAlEpZgRy4vzbN1gqgwZhVwyIylqEZ8BKU/vcqi3pyM9ihPsBWKUmimB0KgSBoRMG3zquVQtUJRn8Pu4Y/9guqwS/10cxMXIndSWgACt8FNraML30NcSpq12tCDm9Pbfy1w70g== 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=XKlsvaMF4rsAhxdAFzjeY7BslCswAihlc7tUEwhIBc0=; b=KNt1oF4WTs9W62DJ2RYwHjV9e/PHewCVuE5wUjC2xqxhUMN1ygdXycIJz45fYR4DI7zm7ywIJwSVEUX7vTgBTmyd3DqjxhG6JSTBH6RTl1fxTJGVFfue2Q6z4XtJ39TDINbJ4l/N/o4mx39PR9NUz80Zzzdc0YyZcsCGAdJlTHvajBdRvPYtV2Ef43mUB24dYP1iebUgsNeHnX/yCDbAvgJ9epFq0p31Ap/d5DdMJkmikoFmWRAvufIcmFyYv59nhw/6HNkIBfYVVkN4uqKSGHbBNkc7+7g+z/hTA8cW5bPLWohx7ho8nTMZECedqWZMWWzNqkEvmbgGPQx3cRdt4g== 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=XKlsvaMF4rsAhxdAFzjeY7BslCswAihlc7tUEwhIBc0=; b=EAZIB/IEsweSS7uyj/uVcfthmQ2wlWRA1YjYpYdyM8JmI2PO533ubu6pz6lXtst9yLlfp7ZrfKyRsAljn+wmC2auzGM9gIPo3dpfVd38X7mC/uINzQNvmvM7nJuqbtH7mzP+gUoi1/uPmPjcAKx6amMeM+5omPID4RJbvAsHqTo= Received: from BN6PR2201MB1700.namprd22.prod.outlook.com (10.161.152.144) by BN6PR2201MB1427.namprd22.prod.outlook.com (10.174.90.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.24; Tue, 29 Oct 2019 18:26:39 +0000 Received: from BN6PR2201MB1700.namprd22.prod.outlook.com ([fe80::c92c:4b04:cfcd:655]) by BN6PR2201MB1700.namprd22.prod.outlook.com ([fe80::c92c:4b04:cfcd:655%7]) with mapi id 15.20.2387.027; Tue, 29 Oct 2019 18:26:39 +0000 From: Mike Bishop To: Eric Rescorla , Martin Thomson CC: Martin Duke , Jana Iyengar , David Schinazi , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , IETF QUIC WG , Kazuho Oku Subject: RE: Consensus Calls for Transport/TLS issues, post-Cupertino Thread-Topic: Consensus Calls for Transport/TLS issues, post-Cupertino Thread-Index: AQHViHGZIuF5g6IoEE6LYrhgawqNGqdl3+KAgAACSQCAABB9gIAAJugAgAAEuICAACuwgIAAzYuAgAF9CnCAAIMlAIACfAKAgAOQaICAAD7ngIABXIYAgAE7BRA= Date: Tue, 29 Oct 2019 18:26:39 +0000 Message-ID: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> 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: [2600:2b00:931f:a301:6877:8be6:ec8e:e92d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d3ca04d7-0352-4d0a-3a28-08d75c9d8a2b x-ms-traffictypediagnostic: BN6PR2201MB1427: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(39830400003)(366004)(396003)(199004)(189003)(51444003)(14444005)(6436002)(2906002)(7736002)(53546011)(102836004)(6506007)(6306002)(229853002)(508600001)(6116002)(25786009)(54896002)(9686003)(790700001)(236005)(256004)(55016002)(14454004)(6246003)(52536014)(74316002)(5660300002)(54906003)(110136005)(71190400001)(316002)(8676002)(33656002)(99286004)(66446008)(81156014)(66574012)(64756008)(81166006)(486006)(4326008)(7696005)(71200400001)(76176011)(66476007)(76116006)(86362001)(66946007)(46003)(476003)(446003)(11346002)(186003)(8936002)(66556008)(87944003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR2201MB1427; H:BN6PR2201MB1700.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: jlVuWdFu4+NBMHP6R0b/C2zK/9pQohfWuhsIRFfAktNtpY/gRjrsDXljlYddbwY629HNU8foZCeU7YxE6UPLxwo/ZanQaHqVuGxGcMPWTshIQ1MPtXVIgmTu+FmmbunAu6wI6ouHGF0bC3qsbTLHFbpoN1vfJYhHUFY6T9dblnNMqXjyRs6M/6Uxe8fYy1jr6L73+PJi2/96FVrDBB69ojsvqH1+bnwJvXpVJlWhwgcLj81QGtaQpIhyqv8NHKune5m/Kr3fK9QD1fiBULu5psxBN7ucrhg5D88TPOidAAXT6QczGaTvFHJSNqpQW4fNhT9HC7P4ccaGddhEo3meJONK8grB2TkwVfuxOrZXbCNabLdzs/vZ0XoqnuFu8x2bdqchO7yFglD9Zs/hSINLKsKYmAs/4X8CjANbMOCU1JOOZIOBTxV7b4RDA+N0RJ0m x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR2201MB1700E30A73DA3E8E91937C6BDA610BN6PR2201MB1700_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: d3ca04d7-0352-4d0a-3a28-08d75c9d8a2b X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2019 18:26:39.2674 (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: qfjPV9THi5pyo5ie4usbtouLFWC0CJ3hJ/4+HIz212R4Xg3s7IPVtOmB6wcMa6gOsGVDkNrTgaDSMRFhwQ33bA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1427 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, 29 Oct 2019 18:26:56 -0000 --_000_BN6PR2201MB1700E30A73DA3E8E91937C6BDA610BN6PR2201MB1700_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV0IG1lIG1ha2Ugc3VyZSBJ4oCZdmUgZ290IHRoaW5ncyBpbiB0aGUgcmlnaHQgb3JkZXIgaGVy ZTogdGhpbmdzIOKAnGp1c3Qgd29ya+KAnSBpZiBib3RoIGNsaWVudCBhbmQgc2VydmVyIGFyZSBh Y3RpdmVseSBzZW5kaW5nIDEtUlRUIGRhdGEuICBUaGUgc2VydmVyIGtub3dzIHRoZSBoYW5kc2hh a2UgaXMgY29tcGxldGUgd2hlbiBpdCBnZXRzIHRoZSBDbGllbnQgRmluaXNoZWQ7IHRoZSBwcm9i bGVtIGlzIHRoYXQgdGhlIHNlcnZlciBkb2VzbuKAmXQga25vdy4NCg0KVGhlcmVmb3JlLCBBQ0sg d29ya3MgaWZmIHdlIGtub3cgdGhhdCB0aGUgY2xpZW50IHNlbnQgc29tZXRoaW5nIGFjay1lbGlj aXRpbmcgaW4gMS1SVFQuICBTbyBvbmUgc29sdXRpb24gaXMgdG8gcmVxdWlyZSBjbGllbnRzIHRv IHNlbmQgc29tZXRoaW5nIOKAkyBhbnl0aGluZywgcmVhbGx5IOKAkyBpbiAxLVJUVCBpbW1lZGlh dGVseSBhZnRlciB0aGUgRmluaXNoZWQuICBXaGVuIGFueSAxLVJUVCBwYWNrZXQgaXMgQUNL4oCZ ZCwgdGhlIGNsaWVudCBrbm93cyB0aGUgc2VydmVyIGhhcyBjb25maXJtZWQgdGhlIGhhbmRzaGFr ZS4gIEEgY2xpZW50IHRoYXQgd2FudGVkIHRvIGJlIGNhdXRpb3VzIGNvdWxkIHNpbXBseSBzZW5k IGFuIGltbWVkaWF0ZSBQSU5HLCBvciBQQVRIX0NIQUxMRU5HRSBhdCAxLVJUVCBhbG9uZyB3aXRo IHRoZSBGaW5pc2hlZCwgYW5kIHRoZXnigJlkIGdldCB0aGVpciBBQ0suICAoVGhpcyBvbmx5IHdv cmtzIGlmIHRoZSBzZXJ2ZXIgaXMgZG9pbmcgdGhlIHJpZ2h0IHRoaW5nIGFuZCBub3QgcmVhZGlu ZyAxLVJUVCBwYWNrZXRzIHVudGlsIGl0IHNlZXMgdGhlIEZpbmlzaGVkLCBob3dldmVyLikgIFJl cXVpcmluZyB0aGUgY2xpZW50IHRvIHNlbmQgSEFORFNIQUtFX0RPTkUgd291bGQgaGF2ZSB0aGUg c2FtZSBlZmZlY3QsIGJ1dCByZXF1aXJlIGl0IGluc3RlYWQgb2YgcGVybWl0IGl0Lg0KDQpBbHRl cm5hdGl2ZWx5LCB0aGUgc2VydmVyIGNvdWxkIHNlbmQgSEFORFNIQUtFX0RPTkUsIGV4cGxpY2l0 bHkgZGVjbGFyaW5nIHRoYXQgaXQgaGFzIHJlY2VpdmVkIHRoZSBGaW5pc2hlZC4gIFJlY2VpcHQg b2YgdGhlIGZyYW1lIGlzIGFsbCB0aGUgY2xpZW50IG5lZWRzLCBidXQgdGhlIHNlcnZlciBuZWVk cyB0aGUgQUNLIHRvIGtub3cgd2hlbiB0byBzdG9wIHNlbmRpbmcgaXQuDQoNCkZyb206IEVyaWMg UmVzY29ybGEgPGVrckBydGZtLmNvbT4NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyOCwgMjAxOSA3 OjM0IFBNDQpUbzogTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0Pg0KQ2M6IE1hcnRp biBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT47IEphbmEgSXllbmdhciA8anJpLmlldGZA Z21haWwuY29tPjsgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPjsgRGF2aWQgU2No aW5hemkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT47IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5z ZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IEth enVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogQ29uc2Vuc3VzIENh bGxzIGZvciBUcmFuc3BvcnQvVExTIGlzc3VlcywgcG9zdC1DdXBlcnRpbm8NCg0KDQoNCk9uIFN1 biwgT2N0IDI3LCAyMDE5IGF0IDc6NDcgUE0gTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHku bmV0PG1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldD4+IHdyb3RlOg0KT24gTW9uLCBPY3QgMjgsIDIw MTksIGF0IDEwOjAxLCBFcmljIFJlc2NvcmxhIHdyb3RlOg0KPiBJIHRoaW5rIHdlJ3JlIGNsZWFy bHkgZ29pbmcgdG8gbmVlZCB0byBzcGVuZCBzb21lIHRpbWUgb24gdGhpcy4gSSBkb24ndA0KPiB0 aGluayB0aGUgc3BlYyBpcyBzYXRpc2ZhY3RvcnkgYXMtaXM6IHdlIHNob3VsZCBiZSBkZXNpZ25p bmcgYQ0KPiB0cmFuc3BvcnQgdGhhdCB3b3JrcyBmb3IgYWxsIHVzZSBjYXNlcywgbm90IGp1c3Qg SDMuIFRoYXQgc2FpZCwgSSBhbHNvDQo+IGRvbid0IGFncmVlIHRoYXQgd2UgbmVlZCBhbiBhZGRp dGlvbmFsIGV4cGxpY2l0IHNpZ25hbC4gV2UgaGF2ZSBvbmUsDQo+IGl0J3MgY2FsbGVkICJBQ0si LiBXZSBzaG91bGQgZmlndXJlIG91dCBob3cgdG8gbWFrZSB0aGF0IHdvcmsuDQoNCkkgdGhpbmsg dGhhdCB3ZSd2ZSBlc3RhYmxpc2hlZCB0aGF0IEFDSyBkb2Vzbid0IHdvcmsgd2l0aG91dCBzb21l dGhpbmcgdG8gcHVzaCBpdCBhbG9uZy4NCg0KTm8sIEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGF0IGFz c2Vzc21lbnQuDQoNCi1Fa3INCg0K --_000_BN6PR2201MB1700E30A73DA3E8E91937C6BDA610BN6PR2201MB1700_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5M ZXQgbWUgbWFrZSBzdXJlIEnigJl2ZSBnb3QgdGhpbmdzIGluIHRoZSByaWdodCBvcmRlciBoZXJl OiB0aGluZ3Mg4oCcanVzdCB3b3Jr4oCdIGlmIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIgYXJlIGFj dGl2ZWx5IHNlbmRpbmcgMS1SVFQgZGF0YS4mbmJzcDsgVGhlIHNlcnZlciBrbm93cyB0aGUgaGFu ZHNoYWtlIGlzIGNvbXBsZXRlIHdoZW4gaXQgZ2V0cyB0aGUgQ2xpZW50IEZpbmlzaGVkOyB0aGUg cHJvYmxlbSBpcyB0aGF0IHRoZQ0KIHNlcnZlciBkb2VzbuKAmXQga25vdy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlcmVmb3JlLCBBQ0sgd29ya3MgaWZmIHdlIDxpPmtub3c8L2k+IHRoYXQg dGhlIGNsaWVudCBzZW50IHNvbWV0aGluZyBhY2stZWxpY2l0aW5nIGluIDEtUlRULiZuYnNwOyBT byBvbmUgc29sdXRpb24gaXMgdG8gcmVxdWlyZSBjbGllbnRzIHRvIHNlbmQgc29tZXRoaW5nIOKA kyBhbnl0aGluZywgcmVhbGx5IOKAkyBpbiAxLVJUVCBpbW1lZGlhdGVseSBhZnRlciB0aGUgRmlu aXNoZWQuJm5ic3A7IFdoZW4gYW55IDEtUlRUIHBhY2tldA0KIGlzIEFDS+KAmWQsIHRoZSBjbGll bnQga25vd3MgdGhlIHNlcnZlciBoYXMgY29uZmlybWVkIHRoZSBoYW5kc2hha2UuJm5ic3A7IEEg Y2xpZW50IHRoYXQgd2FudGVkIHRvIGJlIGNhdXRpb3VzIGNvdWxkIHNpbXBseSBzZW5kIGFuIGlt bWVkaWF0ZSBQSU5HLCBvciBQQVRIX0NIQUxMRU5HRSBhdCAxLVJUVCBhbG9uZyB3aXRoIHRoZSBG aW5pc2hlZCwgYW5kIHRoZXnigJlkIGdldCB0aGVpciBBQ0suJm5ic3A7IChUaGlzIG9ubHkgd29y a3MgaWYgdGhlIHNlcnZlciBpcyBkb2luZw0KIHRoZSByaWdodCB0aGluZyBhbmQgbm90IHJlYWRp bmcgMS1SVFQgcGFja2V0cyB1bnRpbCBpdCBzZWVzIHRoZSBGaW5pc2hlZCwgaG93ZXZlci4pJm5i c3A7IFJlcXVpcmluZyB0aGUgY2xpZW50IHRvIHNlbmQgSEFORFNIQUtFX0RPTkUgd291bGQgaGF2 ZSB0aGUgc2FtZSBlZmZlY3QsIGJ1dCByZXF1aXJlIGl0IGluc3RlYWQgb2YgcGVybWl0IGl0Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHRlcm5hdGl2ZWx5LCB0aGUgc2VydmVyIGNvdWxkIHNl bmQgSEFORFNIQUtFX0RPTkUsIGV4cGxpY2l0bHkgZGVjbGFyaW5nIHRoYXQgaXQgaGFzIHJlY2Vp dmVkIHRoZSBGaW5pc2hlZC4mbmJzcDsgUmVjZWlwdCBvZiB0aGUgZnJhbWUgaXMgYWxsIHRoZSBj bGllbnQgbmVlZHMsIGJ1dCB0aGUgc2VydmVyIG5lZWRzIHRoZSBBQ0sgdG8ga25vdyB3aGVuIHRv IHN0b3Agc2VuZGluZyBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEVy aWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgT2N0b2JlciAyOCwgMjAxOSA3OjM0IFBNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhvbXNv biAmbHQ7bXRAbG93ZW50cm9weS5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJ0aW4gRHVrZSAm bHQ7bWFydGluLmguZHVrZUBnbWFpbC5jb20mZ3Q7OyBKYW5hIEl5ZW5nYXIgJmx0O2pyaS5pZXRm QGdtYWlsLmNvbSZndDs7IE1pa2UgQmlzaG9wICZsdDttYmlzaG9wQGV2ZXF1ZWZvdS5iZSZndDs7 IERhdmlkIFNjaGluYXppICZsdDtkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBNaWtrZWwg RmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7OyBJRVRGIFFVSUMg V0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBLYXp1aG8gT2t1ICZsdDtrYXp1aG9va3VAZ21haWwu Y29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQ29uc2Vuc3VzIENhbGxzIGZvciBUcmFu c3BvcnQvVExTIGlzc3VlcywgcG9zdC1DdXBlcnRpbm88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFN1biwgT2N0IDI3LCAyMDE5IGF0IDc6NDcgUE0gTWFydGluIFRob21zb24g Jmx0OzxhIGhyZWY9Im1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldCI+bXRAbG93ZW50cm9weS5uZXQ8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgT2N0IDI4LCAyMDE5LCBhdCAxMDowMSwgRXJpYyBSZXNj b3JsYSB3cm90ZTo8YnI+DQomZ3Q7IEkgdGhpbmsgd2UncmUgY2xlYXJseSBnb2luZyB0byBuZWVk IHRvIHNwZW5kIHNvbWUgdGltZSBvbiB0aGlzLiBJIGRvbid0IDxicj4NCiZndDsgdGhpbmsgdGhl IHNwZWMgaXMgc2F0aXNmYWN0b3J5IGFzLWlzOiB3ZSBzaG91bGQgYmUgZGVzaWduaW5nIGEgPGJy Pg0KJmd0OyB0cmFuc3BvcnQgdGhhdCB3b3JrcyBmb3IgYWxsIHVzZSBjYXNlcywgbm90IGp1c3Qg SDMuIFRoYXQgc2FpZCwgSSBhbHNvIDxicj4NCiZndDsgZG9uJ3QgYWdyZWUgdGhhdCB3ZSBuZWVk IGFuIGFkZGl0aW9uYWwgZXhwbGljaXQgc2lnbmFsLiBXZSBoYXZlIG9uZSwgPGJyPg0KJmd0OyBp dCdzIGNhbGxlZCAmcXVvdDtBQ0smcXVvdDsuIFdlIHNob3VsZCBmaWd1cmUgb3V0IGhvdyB0byBt YWtlIHRoYXQgd29yay48YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgd2UndmUgZXN0YWJsaXNoZWQg dGhhdCBBQ0sgZG9lc24ndCB3b3JrIHdpdGhvdXQgc29tZXRoaW5nIHRvIHB1c2ggaXQgYWxvbmcu PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5ObywgSSBkb24ndCBhZ3JlZSB3aXRoIHRoYXQgYXNzZXNzbWVudC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_BN6PR2201MB1700E30A73DA3E8E91937C6BDA610BN6PR2201MB1700_-- From nobody Tue Oct 29 13:25:20 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA79120125 for ; Tue, 29 Oct 2019 13:25:17 -0700 (PDT) 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 Uu5PvWgoo83r for ; Tue, 29 Oct 2019 13:25:15 -0700 (PDT) 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 C46841200E3 for ; Tue, 29 Oct 2019 13:25:14 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id g7so4009859wmk.4 for ; Tue, 29 Oct 2019 13:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l2EfxQFvS4/CLQFcTRDGbJk7ko9pDW2R3MEy75XPU3E=; b=vhasHWHBHHBM4uQCNuoIkTJjiFIHVLDGMogN6F0InRTjojAXwphMoUPFMwZH35XxT+ Y+6L4AYVIRTzo3Rc4h/MH9UMT/ac8WcbN/RGbBNmzQumwynuXKo3r7Mz720cC6F8eyiw HweEnpvj9ko3PJjUWrdB35Ma2Z79YVomuQgoBMehxKdg8LgbmN4sBaLwlfntxPxvnGuQ 7B/l/o/JnCbw5EZwXjWf442OT4g2WL4a3v/76MqHLs96g0v2NTZPdH4QXBrEEviwZyLE jUvKYrhftlLrGRapFon7gDL41nHNlaNCce0gXw9Iy/0HVOyJp21Iklh7q3S1zMfbq2D3 4jfA== 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=l2EfxQFvS4/CLQFcTRDGbJk7ko9pDW2R3MEy75XPU3E=; b=D4VMRGKte5t8Kpm4Ri88xtCppzXFZ/zga0L+dG1Lb0rgyQcnzMTVn6h33l3djRBpxS JG5EdY4dKVbXV1MfBq4ugBTJMuvnxmvpW3gFu+/zZq+Nmn2pVEb7DjGInjgU2F98lIff hWAL5qxulHdK3v34Ge34+yfRyTFWMfP6i38RA3KWfLNvvGFUEZ71iCBagfkrIHDMc5Rh HrDVsp50Ti6QU+0X6EKcUi2U/9uWYTSjr/ArdR2vLyQpCUzlbiVHaU2rQ3ZF3IFJET9E asEbPGRIUgFSPr8jA8ctPl+bWJ+OlpFxiI+dopbsFNMPB6lryp7q+ojjnTIoEXvugvEN f/1A== X-Gm-Message-State: APjAAAUnWWgcUtuQW4djYvuYPN/3yC2L4QCNHo8NlnoXVSDDkrtClwcm u3SYmW/d2qKsnnTNu+4VPL0bBEq+cVEQSy++Ty4g0RjdfmA= X-Google-Smtp-Source: APXvYqz+dbQxr/JEJmvJjyemChS/mXEXNVDQlVD3gVeqJeOw3N4T/xlo0tEOWVe4WNNqjF2X7rrQg26gfr6hkUf+lKw= X-Received: by 2002:a1c:2846:: with SMTP id o67mr5850875wmo.7.1572380713215; Tue, 29 Oct 2019 13:25:13 -0700 (PDT) MIME-Version: 1.0 References: <20191028194956.GC420@gmail.com> In-Reply-To: <20191028194956.GC420@gmail.com> From: Martin Duke Date: Tue, 29 Oct 2019 13:25:01 -0700 Message-ID: Subject: Re: draft-duke-quic-load-balancers-05.txt To: Sowmini Varadhan Cc: IETF QUIC WG , Nick Banks , sovaradh@microsoft.com Content-Type: multipart/alternative; boundary="000000000000dceb290596126941" 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, 29 Oct 2019 20:25:18 -0000 --000000000000dceb290596126941 Content-Type: text/plain; charset="UTF-8" Hi Sowmini, Thanks for the review. I'll file a PR for your editorial changes. Responses inline: On Mon, Oct 28, 2019 at 12:50 PM Sowmini Varadhan wrote: > > > - Section 3.2: Config rotation is one octet (per Section 3.3) and > there are 2 bits for config rotation, so it is confusing when Section 3.2 > says > 361 received these, it MUST generate connection IDs with the config > 362 rotation bits set to '0b11' and MUST use the "disable_migration" > (0b11 is 2 bytes? In general, it would help to provide more context about > what/when/how this can happen, and why it is needed) > 0b11 is 2 bits. The '0b' notation indicates each digit is a bit; '0x' would be hexadecimal, where 2 characters = 1 Bytes. > > - Section 4 ("Routing Algorithms"). The 0-RTT can have application data. > Given that Section 4 discusses an "alternate algorithm" for 0-RTT, > is it possible that the data from 0-RTT gets routed differently than > the remainder of the packet? > In section 4, it says: " The load balancer SHOULD route Initial and 0-RTT packets from the client using an alternate algorithm". The point here is that the destination CID for these packets is chosen by the client. It may not be long enough to apply the chosen algorithm, so something else should be done. However, " This algorithm SHOULD generate consistent results for Initial and 0RTT packets that arrive with the same source and destination connection ID" so they all end up at the same place. If the LB doesn't do this, then the 0RTT packets will be lost. This is suboptimal but doesn't break the protocol. > > > - Section 4.3.1 refers to "token". Is this the token from the Initial? > From the Retry? The LB is just a service in the middle, between the > 2 quic endpoints, so it would help to explain which token to use. > To be clear, I am referring to: > 604 The load balancer decrypts the server ID using 128-bit AES > Electronic > 605 Codebook (ECB) mode, much like QUIC header protection. The nonce > 606 octets are padded to 16 octets using the as many of the first > octets > 607 of the token as necessary. AES-ECB encrypts this nonce using its > key > 608 to generate a mask which it applies to the encrypted server id. > > This is the QUIC-LB authentication token, which I should clarify. In any case, I don't believe that servers get this token if there's out-of-band configuration, so I need to fix this. > > - Editorial: s/decrypts/encrypts in second paragraph of Section 4.3.2: > 631 4.3.2. Server Actions > : > 640 The server decrypts the server ID using 128-bit AES Electronic > 641 Codebook (ECB) mode, much like QUIC header protection. The nonce > > - Section 5: this one was particularly hard for me to read. I think it > would help if this section of the draft hsd a top-level discussion on > why this is needed (i.e., what are the sort of things that can go > wrong if it is not there? Also, in Figure 5, why do we need to encode > ODCIL and ODCID in the Retry token, given that they are already there > in the Retry packet itself?) > This is for the benefit of the QUIC server. When the server gets an Initial Packet with a Retry token in it, it needs to extract the ODCID from that token so that it can send it back in a transport parameter. If the client got a Retry but then doesn't get the ODCID transport parameter, it means there's an unauthorized man in the middle and the client should terminate the connection. > > --Sowmini > --000000000000dceb290596126941 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sowmini,

Thanks for the review. I'll file a PR for your editorial changes.
<= /div>

Responses inline:

On Mon, Oct 28, 2019 at= 12:50 PM Sowmini Varadhan <sowmi= ni05@gmail.com> wrote:

<snip>
- Section 3.2: Config rotation is one octet (per Section 3.3) and
=C2=A0 there are 2 bits for config rotation, so it is confusing when Sectio= n 3.2
=C2=A0 says
=C2=A0361=C2=A0 =C2=A0 received these, it MUST generate connection IDs with= the config
=C2=A0362=C2=A0 =C2=A0 rotation bits set to '0b11' and MUST use the= "disable_migration"
=C2=A0 (0b11 is 2 bytes? In general, it would help to provide more context = about
=C2=A0 what/when/how this can happen, and why it is needed)

0b11 is 2 bits. The '0b' notation indica= tes each digit is a bit; '0x' would be hexadecimal, where 2 charact= ers =3D 1 Bytes.
=C2=A0

- Section 4 ("Routing Algorithms"). The 0-RTT can have applicatio= n data.
=C2=A0 Given that Section 4 discusses an "alternate algorithm" fo= r 0-RTT,
=C2=A0 is it possible that the data from 0-RTT gets routed differently than=
=C2=A0 the remainder of the packet?

<= div>In section 4, it says: " The = load balancer SHOULD route Initial and 0-RTT packets from the client using = an alternate algorithm". The point here is that the destination= CID for these packets is chosen by the client. It may not be long enough t= o apply the chosen algorithm, so something else should be done. However, &q= uot; This= algorithm SHOULD generate consistent results for Initial and 0RTT packets = that arrive with the same source and destination connection ID"= so they all end up at the same place. If the LB doesn't do this, then = the 0RTT packets will be lost. This is suboptimal but doesn't break the= protocol.

<snip>


- Section 4.3.1 refers to "token". Is this the token from the Ini= tial?
=C2=A0 From the Retry? The LB is just a service in the middle, between the<= br> =C2=A0 2 quic endpoints, so it would help to explain which token to use. =C2=A0 To be clear, I am referring to:
=C2=A0604=C2=A0 =C2=A0 The load balancer decrypts the server ID using 128-b= it AES Electronic
=C2=A0605=C2=A0 =C2=A0 Codebook (ECB) mode, much like QUIC header protectio= n.=C2=A0 The nonce
=C2=A0606=C2=A0 =C2=A0 octets are padded to 16 octets using the as many of = the first octets
=C2=A0607=C2=A0 =C2=A0 of the token as necessary.=C2=A0 AES-ECB encrypts th= is nonce using its key
=C2=A0608=C2=A0 =C2=A0 to generate a mask which it applies to the encrypted= server id.


This is the QUIC-LB authenticati= on token, which I should clarify. In any case, I don't believe that ser= vers get this token if there's out-of-band configuration, so I need to = fix this.
=C2=A0

- Editorial: s/decrypts/encrypts in second paragraph of Section 4.3.2:
=C2=A0631 4.3.2.=C2=A0 Server Actions
=C2=A0 :
=C2=A0640=C2=A0 =C2=A0 The server decrypts the server ID using 128-bit AES = Electronic
=C2=A0641=C2=A0 =C2=A0 Codebook (ECB) mode, much like QUIC header protectio= n.=C2=A0 The nonce

- Section 5: this one was particularly hard for me to read. I think it
=C2=A0 would help if this section of the draft hsd a top-level discussion o= n
=C2=A0 why this is needed (i.e., what are the sort of things that can go =C2=A0 wrong if it is not there? Also, in Figure 5, why do we need to encod= e
=C2=A0 ODCIL and ODCID in the Retry token, given that they are already ther= e
=C2=A0 in the Retry packet itself?)

This is for the benefit of the QUIC server. When the server gets an Init= ial Packet with a Retry token in it, it needs to extract the ODCID from tha= t token so that it can send it back in a transport parameter. If the client= got a Retry but then doesn't get the ODCID transport parameter, it mea= ns there's an unauthorized man in the middle and the client should term= inate the connection.

=C2=A0

--Sowmini
--000000000000dceb290596126941-- From nobody Tue Oct 29 14:04:41 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AC8120119 for ; Tue, 29 Oct 2019 14:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 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, FSL_HELO_FAKE=1.797, 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 OgvIEI57ps8e for ; Tue, 29 Oct 2019 14:04:37 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 49A8712006D for ; Tue, 29 Oct 2019 14:04:37 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id g50so172830qtb.4 for ; Tue, 29 Oct 2019 14:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=/B3Fft6DZPztXv8n5+6oDXh+nv6maexlf2NTGmJOIpI=; b=mbjxjl4gW26r4dDFMxsc7/zqs5VXTmggD16cJSlZpqYPrnJY3AZVVnIZI9G//lEhos rN4zWcQfj4dc4yUBmuXX5sw7Lxn/tSd+lO8JYoZHIDTTp0neqp35pHKMnhcDkXg6aaTI lDCHHUak5jL78zUlMtwiTJwETyT1bVwpjUj2wzgpVzfm/MjsfRVOBjF4XPxRPbPfojwB BVwyj3GC4p0cfeZNWDB/AL0f39cWg43M0bViwGtb2pCHm8CMTlwcxNcdTF4qzy+1G4Xx pNqZyHrcFqnUpmFBoEN83JjEnt1YtqQz7pQWO7i67MqYHXA+qg2hGJzby8UK7uljWDQm oPRQ== 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:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/B3Fft6DZPztXv8n5+6oDXh+nv6maexlf2NTGmJOIpI=; b=mzBXXb2KPi4eGjgZ4SjuCgQ9o/wOEpbgI/S3T/ZiaNi3nWVqOz8Vaq8KTYojdo29xQ zJVXOVVQ+YbXknfooeh2/OEbMftZkTw2eFHxbKD/J+9J+HA24ZapytbQXlF8vzEzi3Ig AbZq8WGg2A32wmTYQldX+ZpLSmenbENkV3RIwUbv9iABRVNrSEydu8CBP+Hy9NpqSNnb Zao2qTOiYokOd9Ds7VpEeXRCcsC6IBRhFfFpiSQQhSd5YIzFZcTNZjY6I9GvpsZ0cEXN ht4bjRyi2ffmJHmRWDlhXhIFQOyTflYHEOezA2McdLbjizRZ/wPD5eqSVAgWpgNXUHK3 sPgw== X-Gm-Message-State: APjAAAVB646WNAaRb5DMpOg84AVvHE/+qNqNznlCb1X6ee2BB4FQONCe gsn2IXQR+3tsxVob2+cNmPo= X-Google-Smtp-Source: APXvYqyGdqju8Nijo69SYGDp44QEXaohiRoPNMKEq3aVNNcfs88gXeJbRlHbZ77qDSpVSNSSt1YphA== X-Received: by 2002:aed:21c4:: with SMTP id m4mr1330598qtc.342.1572383076285; Tue, 29 Oct 2019 14:04:36 -0700 (PDT) Received: from gmail.com (pool-74-104-133-20.bstnma.fios.verizon.net. [74.104.133.20]) by smtp.gmail.com with ESMTPSA id d139sm216188qkb.36.2019.10.29.14.04.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 29 Oct 2019 14:04:35 -0700 (PDT) Date: Tue, 29 Oct 2019 17:04:28 -0400 From: Sowmini Varadhan To: Martin Duke Cc: IETF QUIC WG , Nick Banks , sovaradh@microsoft.com Subject: Re: draft-duke-quic-load-balancers-05.txt Message-ID: <20191029210428.GA119@gmail.com> References: <20191028194956.GC420@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) 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, 29 Oct 2019 21:04:39 -0000 On (10/29/19 13:25), Martin Duke wrote: > Hi Sowmini, > Thanks for the review. I'll file a PR for your editorial changes. sounds good, thanks for doing this! > 0b11 is 2 bits. The '0b' notation indicates each digit is a bit; '0x' > would be hexadecimal, where 2 characters = 1 Bytes. ah, this is the NIC data-sheet notation, that got me by surprise. If there is no strong objection, can we just list the code-points as "11" (I think this is the convention followed in other ietf rfcs, e.g., 3168, for the ECT code-points). > In section 4, it says: " The load balancer SHOULD route Initial and 0-RTT > packets from the client using an alternate algorithm". The point here is > that the destination CID for these packets is chosen by the client. It may > not be long enough to apply the chosen algorithm, so something else should > be done. However, " This algorithm SHOULD generate consistent results for > Initial and 0RTT packets that arrive with the same source and destination > connection ID" so they all end up at the same place. If the LB doesn't do > this, then the 0RTT packets will be lost. This is suboptimal but doesn't > break the protocol. ok, perhaps it would be helpful to add some discussion around this in the draft. [discussion for "Section 4.3.1 refers to "token"] > This is the QUIC-LB authentication token, which I should clarify. In any > case, I don't believe that servers get this token if there's out-of-band > configuration, so I need to fix this. Ok. [discussion around Section 5] > This is for the benefit of the QUIC server. When the server gets an > Initial Packet with a Retry token in it, it needs to extract the ODCID > from that token so that it can send it back in a transport parameter. If > the client got a Retry but then doesn't get the ODCID transport parameter, > it means there's an unauthorized man in the middle and the client should > terminate the connection. I see. In general, it would help to provide some context in this section about why any tweaks in the Retry Service are needed at all, along with your explanation above. Thanks! --Sowmini From nobody Tue Oct 29 16:46:21 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9F11200A3 for ; Tue, 29 Oct 2019 16:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=PEfrQquI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EIZavS7e Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id li0_yXlRiz6f for ; Tue, 29 Oct 2019 16:46:18 -0700 (PDT) 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 5994D12006B for ; Tue, 29 Oct 2019 16:46:18 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AF8D1210B8 for ; Tue, 29 Oct 2019 19:46:17 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 29 Oct 2019 19:46:17 -0400 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=fm3; bh=52/yrzrWpU2My/iWeMsdxP8uIn9kDU9 MpO311GDFxEc=; b=PEfrQquItdMs6VpDzSfxdt3/OkDZPxibHoYgbx9C4A96nXA D9Cowh1NIXLfc12NaconiQSVmuoG2uB29AQHvDX+ZedN9ex43OFCdgnOmLneQQqp mwW8Qa6HmL5IEnhzYBZtukUDh2hZPKoJzjyX/5VzFFc28lRXpuvz+72ytTVG/J8e XvVlJf77sskr2oBKW4oP+NyGCOzytnfsL2ajvIKsPvuxCgcLxwahGw6ZBr6H5SPO 8JKcj4Aby0LjVGN6jBBunKJNb0vJs8xQiNcnl/8U9YNWCXDj/RJzNn7iQQYKwJOL w6OlkkNp7WtElAUNrFdXpc0zYVfRXbT4KqdIFHw== 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=fm1; bh=52/yrz rWpU2My/iWeMsdxP8uIn9kDU9MpO311GDFxEc=; b=EIZavS7eveuI7AdrewgR8C l7TD37GZV897gA43Wj33Dz2RYM26o3lFWX6+HdaLj65HV7gEWb6sgMqs6zdwhMwi FcYSrmyBTqAi4ZxIO9Pqw8d7ea07q7I7FrGsxPOaB/8PJFj4Gx7mbHyQbID+ROU9 qGBZT7q16D7uoN2ZSkKkYXayiOuNfYpTdpEJvj8lk4qZ6zFEfpfcPTmKsZQ9LeFb XDDoPbhfHq33Kn82Kuu3FT0YqELfSeD0MqGjamx6UwNESFfjt5gDM7xHgcJ6BeQ7 HbUXRIiL5TmoTqpUXlhw0N6otVAIeU3y7A5r3RYTym3yec+PUG/nfIDukLdBeGkQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtvddgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5E4F0E00A3; Tue, 29 Oct 2019 19:46:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-512-g193a140-fmstable-20191028v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> Date: Wed, 30 Oct 2019 10:45:59 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino 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: Tue, 29 Oct 2019 23:46:20 -0000 On Wed, Oct 30, 2019, at 05:26, Mike Bishop wrote: > Therefore, ACK works iff we *know* that the client sent something > ack-eliciting in 1-RTT. I think that you have to make it symmetric, not just "client sends". Because we don't have implicit acknowledgement for Handshake packets from the server, the server can enter the same state that the client does in Marten's deadlock scenario. In other words, both need to send something ack-eliciting. And it's not just anything at any time, it has to be anything within some bounded time. The upper bound is probably high, but it is at least before the Handshake packets consume all the available congestion window (which might be a long time, but I haven't worked out how long that could take). > So one solution is to require clients to send ...and servers :) From nobody Tue Oct 29 16:59:33 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D7A12008B for ; Tue, 29 Oct 2019 16:59:31 -0700 (PDT) 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 4gpJhRJBTC4G for ; Tue, 29 Oct 2019 16:59:30 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4180412006B for ; Tue, 29 Oct 2019 16:59:30 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id u22so561940lji.7 for ; Tue, 29 Oct 2019 16:59:30 -0700 (PDT) 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=02Jw9YB/y83B7pxpkmQ3zfhC8MkJy93NouoM6BI6Cwg=; b=ltc7KHQ5Xts9cj1bzE19rpstr32Th4x2yYR/fTpzuCXHf2YXGNLD2iYM+RV43GgKgp PM0orlGW6J1z23cWSqSbAMkMDQJYz/aOhlZd+wkAtuj0G6cW1tvxwHzo+f55OQFswh6x P9Bj9O9LT20xHiws0D4kZFsxHXWOttxeogW0Ibm3o1pdBq92X6bTkHnm793AXGtVTx6Y PvJUYTN5nZwR+y6OXI+h6bqpWVMCQhv4PT/QUjDQccGtPj19MdiOcart5wXrKEZxHpUe dkGWG683G0TW032rJZ8qkd9Rl7hQv4kQNGSeiC4QJPMJfojPXwDhPfLaOgkgMN9lupZ7 6Skg== 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=02Jw9YB/y83B7pxpkmQ3zfhC8MkJy93NouoM6BI6Cwg=; b=WwZQvlPGTJSpxUB/HM3CDwGxzxI3eAXRk/ifGmYsObJ1Y4aU1FFcQ7zvJmNrfq7XCZ 8vZqdYNvHlT3nXNO6EoAp3JnhmIs3Spjrjc2dNVeaMFsP9YBme02GzVG8cDR+aHC0TPo QJ2wDfsSBIH0sBceeSY44HBFrw/mHXIx/DxGyQpLxybaniPTjqHICBFT2NnnUL/uJ7U7 Kc1CIjC08Vfiz+/fd4awNoAJP684Sah6ezVmVH1RvWj/cKTzCLz4P93Fc8gUpzcFmmbt 40p6nae3Eq9znJ4rkYcEHEWidFRnpFeD23tXlmxtSFV0ijfTYqto4ArfiGmwBvRjaaR5 03PQ== X-Gm-Message-State: APjAAAVY3dGhSctf1mEdHhdt8TrFrLbzZTKmTueRk/PpMzBLtyW+QLiI 7F7oIY+zvEMEyl6J0VBXtcz61OkEboYsUmKrV3c0EQ== X-Google-Smtp-Source: APXvYqyiXxQUX0yMEjN0J/sUACikbMoHGFeFrJDGgTz+4QHMgFTTuYrq75mYCktTEhZ4CEzJmAn3Pyc6JRkR61Z0joQ= X-Received: by 2002:a2e:a303:: with SMTP id l3mr4070367lje.38.1572393568446; Tue, 29 Oct 2019 16:59:28 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> In-Reply-To: <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> From: Eric Rescorla Date: Tue, 29 Oct 2019 16:58:52 -0700 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Martin Thomson Cc: Martin Duke , Jana Iyengar , Mike Bishop , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Kazuho Oku Content-Type: multipart/alternative; boundary="0000000000001845cb0596156823" 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, 29 Oct 2019 23:59:32 -0000 --0000000000001845cb0596156823 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 28, 2019 at 8:32 PM Martin Thomson wrote: > On Tue, Oct 29, 2019, at 10:34, Eric Rescorla wrote: > > On Sun, Oct 27, 2019 at 7:47 PM Martin Thomson > wrote: > > > On Mon, Oct 28, 2019, at 10:01, Eric Rescorla wrote: > > > > I think we're clearly going to need to spend some time on this. I > don't > > > > think the spec is satisfactory as-is: we should be designing a > > > > transport that works for all use cases, not just H3. That said, I > also > > > > don't agree that we need an additional explicit signal. We have > one, > > > > it's called "ACK". We should figure out how to make that work. > > > > > > I think that we've established that ACK doesn't work without > something to push it along. > > > > No, I don't agree with that assessment. > > Well, I'd like some proof. I shared what I believe to be proof earlier. > Happy to walk through it again though. > Yeah, I think that would help. I've gotten a little lost on the list, so maybe you can re-point it out to me. -Ekr --0000000000001845cb0596156823 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 28, 2019 at 8:32 PM Marti= n Thomson <mt@lowentropy.net>= ; wrote:
On Tue,= Oct 29, 2019, at 10:34, Eric Rescorla wrote:
> On Sun, Oct 27, 2019 at 7:47 PM Martin Thomson <mt@lowentropy.net> wrote:
> > On Mon, Oct 28, 2019, at 10:01, Eric Rescorla wrote:
> >=C2=A0 > I think we're clearly going to need to spend some = time on this. I don't
> >=C2=A0 > think the spec is satisfactory as-is: we should be des= igning a
> >=C2=A0 > transport that works for all use cases, not just H3. T= hat said, I also
> >=C2=A0 > don't agree that we need an additional explicit si= gnal. We have one,
> >=C2=A0 > it's called "ACK". We should figure out = how to make that work.
> >
> >=C2=A0 I think that we've established that ACK doesn't wor= k without something to push it along.
>
> No, I don't agree with that assessment.

Well, I'd like some proof.=C2=A0 I shared what I believe to be proof ea= rlier.=C2=A0 Happy to walk through it again though.
Yeah, I think that would help. I've gotten a little lost o= n the list, so maybe you can re-point it out to me.

-Ekr



--0000000000001845cb0596156823-- From nobody Tue Oct 29 22:02:52 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4DA1200E3 for ; Tue, 29 Oct 2019 22:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=lowentropy.net header.b=fP54RQci; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XCzyCDNQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKc2qmLtK-i2 for ; Tue, 29 Oct 2019 22:02:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D8312003E for ; Tue, 29 Oct 2019 22:02:48 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1C59521A92; Wed, 30 Oct 2019 01:02:47 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 30 Oct 2019 01:02:47 -0400 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 :cc:subject:content-type; s=fm3; bh=llNDkmw0W4vEnmb+ZxgzGybQU1uI VUh30qHoYfym+1U=; b=fP54RQciikvugvMN2dEOYmiwsE+SNuLKltbwtiN7lD0C lQFHpL1/GyCgLFzaFmaQwwSisIE1KvSMyIvoD/rRo417whd9hmgII23Zmk/RU/xG N+jwGCsXan2i49q959F9akXr2QhpC46ERdU+Oe00gNpxILMEi0tByn80Wgs7T/6Q m+JV6P2SMVZpLE5WjJmr30U4sfv6zTOQ5GtCX0AZlXPAPI/NNFlx2aMkVwFcifYI rFcuCvnFPPPL6RKZRinatKRFYRRSwVrj8KxgqMldAEJv8YI84LVzsvy1ESqDBANo NX4mpoyeuX3YvPvw84FxuN71/qoFb6gZdN+8Ck5tpg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=llNDkm w0W4vEnmb+ZxgzGybQU1uIVUh30qHoYfym+1U=; b=XCzyCDNQr3US9aVYGqLRBZ PeLaSG2GoBuoqvYC28UHGzkuZtGIqKpc5k/UhRfvd21Fdku6z0VtiTXeZiDAH6wJ WpFgaClvnz1YURDQ+LYH+4mtZ1j7OoRftvcUA0NlxBvjRw7tggjR1zg9lFGht3JY dQrMLvC+KvXckV2+lH6EzXEi8tDl6u0hX3rgeI9G3pK4vUmhpO9Q8D9XFPXY4X68 i3+aX7m9t0VH9Pm8m95P0PpxjIEhGhEyQuUGFzpdMpIgt8KOJMb0/YZUv+Hhxdur 3+dQmpg408Vhh4RiTWN+upBVKB6F+CUlV5uCbdXEtgQNrznKOjS657zvX5gqs+Bw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtvddgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurf grrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5D0F4E00A3; Wed, 30 Oct 2019 01:02:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> In-Reply-To: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> Date: Wed, 30 Oct 2019 16:02:28 +1100 From: "Martin Thomson" To: "'Eric Rescorla'" Cc: "Martin Duke" , "Jana Iyengar" , "Mike Bishop" , "David Schinazi" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "IETF QUIC WG" , "Kazuho Oku" Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino 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: Wed, 30 Oct 2019 05:02:51 -0000 On Wed, Oct 30, 2019, at 10:58, Eric Rescorla wrote: > On Mon, Oct 28, 2019 at 8:32 PM Martin Thomson wrote: > > On Tue, Oct 29, 2019, at 10:34, Eric Rescorla wrote: > > > On Sun, Oct 27, 2019 at 7:47 PM Martin Thomson wrote: > > > > On Mon, Oct 28, 2019, at 10:01, Eric Rescorla wrote: > > > > > I think we're clearly going to need to spend some time on this. I don't > > > > > think the spec is satisfactory as-is: we should be designing a > > > > > transport that works for all use cases, not just H3. That said, I also > > > > > don't agree that we need an additional explicit signal. We have one, > > > > > it's called "ACK". We should figure out how to make that work. > > > > > > > > I think that we've established that ACK doesn't work without something to push it along. > > > > > > No, I don't agree with that assessment. > > > > Well, I'd like some proof. I shared what I believe to be proof earlier. Happy to walk through it again though. > > Yeah, I think that would help. I've gotten a little lost on the list, > so maybe you can re-point it out to me. Let me try restating it more thoroughly: The problem that Marten identified is a deadlock because one side discards keys at a time that might be significantly in advance of the other. If the endpoint that retains keys still hasn't received acknowledgments, it enters a deadlock state if it exhausts the congestion window by sending Handshake packets. (As an aside, David suggested that we might avoid deadlock if the congestion controller didn't create a dependency cycle between 1-RTT and Handshake, but I didn't detect any inclination to do that, nor am I completely confident that attempting to do so would guarantee success. There's also the problem that Kazuho and Jana identified, which observes that a loose upper bound on convergence time was undesirable if we want to enable migration.) Both peers can enter this potential deadlock state in different ways, so we need a symmetric solution. I can draw up what this looks like in converse, but just imagine that the client sends and loses a Handshake ACK that is separate from the Finished. That side of this could be addressed with implicit acknowledgment for the server, but I don't think we want to go there. Any signal that is based purely on "organic" traffic (that is stuff that is sent by the application) can produce an asymmetric state where one side receives the signal and the other does not. If both peers stop sending packets at that point, which "organic" traffic would have to permit, then the keys will be gone on one side and not the other. In general, frames from an endpoint don't result in any mandatory transport-level action other than an ACK frame. ACK frames don't elicit acknowledgment and aren't sent again. PATH_CHALLENGE is the other way to get a transport-level forced response, but that is similar in that PATH_RESPONSE also doesn't require retransmision. An endpoint that sends a packet can decide not to send another packet. Thus, any implicit signal we create can only guarantee one-way propagation, which is firmly in two generals territory as Christian points out. A PATH_CHALLENGE is almost right for this purpose, because it initiates a three-way exchange, but the lack of requirements for retransmission makes it difficult to guarantee that the process terminates. And that probably requires overloading semantics for the frames in uncomfortable ways. Forcing either endpoint to repeatedly initiate path validation would be worse than HANDSHAKE_DONE, especially when you consider that the path is already validated by the handshake. Thus, while we might be able to define a process where each peer can satisfy themselves that their peer is "done", we don't have an "organic" process that we can attach to for roughly synchronizing the times that endpoints reach that conclusion. From nobody Tue Oct 29 22:09:05 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8413212003E for ; Tue, 29 Oct 2019 22:09:03 -0700 (PDT) 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, 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 umXky9FtrBv4 for ; Tue, 29 Oct 2019 22:09:01 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A95120827 for ; Tue, 29 Oct 2019 22:09:01 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id y3so1129119ljj.6 for ; Tue, 29 Oct 2019 22:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=m7chVPRkUMfij36+pZGeUsh176Nod5x9332jPXTLAnU=; b=gmEKlvTVgnMHwwFrK67ho08ZBcXrbegneicyeX2xmjTKOgGlO0mzOnh7iItTfKX5Jb GFx0k+obNKAAY6q4fDD/rB9DXJDXib13Gas2dDKYVfMgdsNZ57dv39btARJX+L3fMXA6 +hzOushnH1nAaxVb103/qHWEEG/gthsLz9F97oxfRc6DIgpM2uG5RgGcoRU1bEBUWql/ wOw46pdFYIWYE79jHMIlp0CB1ftbxK1rCAAX4rpLz7C5Q6a7NUUQcjQHY/StIM6Ib4Ga ko07DxKpWUth+K8Ox6RAPqbnBF/Jy17denfBjYxYRGQVZXRPqmt1v2GZGx0Xj7BkJKpR +qfg== 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:content-transfer-encoding; bh=m7chVPRkUMfij36+pZGeUsh176Nod5x9332jPXTLAnU=; b=i0ae6qTZkX8Lce0a3q+eMnPbKRaBVjneqV664rdm24KI/A6iq8A2mI9DKnZYfIUNoT tSc4ejyiACnU019Zn8HFCaAL69hvZ4km5v264SQvUz3uAraiPJnhD8hW+sv3E1QbPg4q YpuU1FntXkO9tSOWoutmeJyXVMlYobhH4Rd7DO6sifikneKYOJYIBuPuRmtDTPT4URCq IZn5wgHiXFRKEF5TCE+f6uPpOO3U2Domt7VHfWMFZmReY6oHX0p5uRgezEyMyY92RaMF xWNwXFLUhvJHGZ8vvQb+2t4/bUfT5NQJu6g/V40nPErsKsko2s+TclfRVHCwqJq49nKs lwqw== X-Gm-Message-State: APjAAAVXjd/PB6OkzC3SW1oezc5tU1wB5TY2RTELzhUgWgYX/kzXr9EQ E9DbanGPC5L3XyC/V86HvhwrWP+mh+i9SvgcVGo= X-Google-Smtp-Source: APXvYqzgM7I42eO5wYs82MIivU5nZ6VakrG3Vj1LtBPJgC9Mb+6J//sMVmwZKa+likKdoWkrwcoNDr/Jlqt0GFRJIsg= X-Received: by 2002:a05:651c:28a:: with SMTP id b10mr850300ljo.124.1572412139404; Tue, 29 Oct 2019 22:08:59 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> In-Reply-To: <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> From: Watson Ladd Date: Tue, 29 Oct 2019 22:08:48 -0700 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Martin Thomson Cc: Eric Rescorla , Jana Iyengar , Mike Bishop , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Martin Duke , Kazuho Oku 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: Wed, 30 Oct 2019 05:09:04 -0000 On Tue, Oct 29, 2019 at 10:03 PM Martin Thomson wrote: > > On Wed, Oct 30, 2019, at 10:58, Eric Rescorla wrote: > > On Mon, Oct 28, 2019 at 8:32 PM Martin Thomson wrot= e: > > > On Tue, Oct 29, 2019, at 10:34, Eric Rescorla wrote: > > > > On Sun, Oct 27, 2019 at 7:47 PM Martin Thomson = wrote: > > > > > On Mon, Oct 28, 2019, at 10:01, Eric Rescorla wrote: > > > > > > I think we're clearly going to need to spend some time on this= . I don't > > > > > > think the spec is satisfactory as-is: we should be designing a > > > > > > transport that works for all use cases, not just H3. That said= , I also > > > > > > don't agree that we need an additional explicit signal. We hav= e one, > > > > > > it's called "ACK". We should figure out how to make that work. > > > > > > > > > > I think that we've established that ACK doesn't work without som= ething to push it along. > > > > > > > > No, I don't agree with that assessment. > > > > > > Well, I'd like some proof. I shared what I believe to be proof earli= er. Happy to walk through it again though. > > > > Yeah, I think that would help. I've gotten a little lost on the list, > > so maybe you can re-point it out to me. > > Let me try restating it more thoroughly: > > The problem that Marten identified is a deadlock because one side discard= s keys at a time that might be significantly in advance of the other. If t= he endpoint that retains keys still hasn't received acknowledgments, it ent= ers a deadlock state if it exhausts the congestion window by sending Handsh= ake packets. > > (As an aside, David suggested that we might avoid deadlock if the congest= ion controller didn't create a dependency cycle between 1-RTT and Handshake= , but I didn't detect any inclination to do that, nor am I completely confi= dent that attempting to do so would guarantee success. There's also the pr= oblem that Kazuho and Jana identified, which observes that a loose upper bo= und on convergence time was undesirable if we want to enable migration.) > > Both peers can enter this potential deadlock state in different ways, so = we need a symmetric solution. I can draw up what this looks like in conver= se, but just imagine that the client sends and loses a Handshake ACK that i= s separate from the Finished. That side of this could be addressed with im= plicit acknowledgment for the server, but I don't think we want to go there= . > > Any signal that is based purely on "organic" traffic (that is stuff that = is sent by the application) can produce an asymmetric state where one side = receives the signal and the other does not. If both peers stop sending pac= kets at that point, which "organic" traffic would have to permit, then the = keys will be gone on one side and not the other. > > In general, frames from an endpoint don't result in any mandatory transpo= rt-level action other than an ACK frame. ACK frames don't elicit acknowled= gment and aren't sent again. PATH_CHALLENGE is the other way to get a tran= sport-level forced response, but that is similar in that PATH_RESPONSE also= doesn't require retransmision. An endpoint that sends a packet can decide= not to send another packet. Thus, any implicit signal we create can only = guarantee one-way propagation, which is firmly in two generals territory as= Christian points out. > > A PATH_CHALLENGE is almost right for this purpose, because it initiates a= three-way exchange, but the lack of requirements for retransmission makes = it difficult to guarantee that the process terminates. And that probably r= equires overloading semantics for the frames in uncomfortable ways. Forcin= g either endpoint to repeatedly initiate path validation would be worse tha= n HANDSHAKE_DONE, especially when you consider that the path is already val= idated by the handshake. > > Thus, while we might be able to define a process where each peer can sati= sfy themselves that their peer is "done", we don't have an "organic" proces= s that we can attach to for roughly synchronizing the times that endpoints = reach that conclusion. Maybe it's worth writing down the state machine formally and trying to use a model checker to show that there are no deadlocking pathways. It's certainly confusing enough for me to have no idea. > > > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Oct 29 23:50:43 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE2C1200B1 for ; Tue, 29 Oct 2019 23:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=BAgUzQKb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lQ5PWS5C Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1Cb1BMBmpHL for ; Tue, 29 Oct 2019 23:50:39 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7ED512008F for ; Tue, 29 Oct 2019 23:50:39 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E150643C for ; Wed, 30 Oct 2019 02:50:38 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 30 Oct 2019 02:50:39 -0400 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=fm3; bh=VzJOBAAFYwddGYrtha81MtTbxU+4OMr U5F3uEWD7qnA=; b=BAgUzQKbfnyZKN/Nas57U5na7IF81IyFS3eY1eMV79QeK9i lJ3rUsgaLCWLEY+S1fJR/jQCDHh8kED3y43KjQ70t/fZrT1ap/mEJ+tWPFdSM/Yy UND22lFrlicxK0SBAYpvbXsIlDa7esebofw5YEKIl4WfYnHb9ZpdEIuTvPfA3urj ZfrsIy7gTYMCtpMPitb9zdoi0iepZHrSKqCVVYKs9A+Bni52h/dPkvW4qcuNrIvN IAtdpXx0/WWUlqA+RORkhYB9vVGcLkYEl1mL+2Lb+nNuSXRVFhRKyRpQr/FOJNZY ve0XpCZEgTyzRdXA13534D5ofjE0hq13Z6Rzm6w== 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=fm1; bh=VzJOBA AFYwddGYrtha81MtTbxU+4OMrU5F3uEWD7qnA=; b=lQ5PWS5C93VimiCy5Y+xV+ mbj4yqS/pw6bkQNxmTQF1ZrGjW+dQKuE833KTfzH2F5UtGcVWLzgeXkqw3st+z1O 0cUzoVxRnZUmpdQ93KUeygSh93lP9gvhBRW96DQkvnB1xxKULieXk022rVludfub vS9DQfMXfYDwjOT4ESv3MtxNcol7QSjL5c3adxmyqCpO/3Tbg7Gx+SMWXPtcWQHs 9ANxpObc7scQv40U3VFoRyhhpxwMeMhvMCcK6IRWzg6NkeWAum1imih8fqkbaoV6 3zvFnMd0lapkjjlRWpGl7Qv6a+FZzrA0QfPhOD/BwYQ+8cdwYGiDAcabA1MV49dw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtvddguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc frrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucev lhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 03E5FE00A3; Wed, 30 Oct 2019 02:50:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <36b10565-1c64-4a42-a1c2-648e4c8eee37@www.fastmail.com> In-Reply-To: References: Date: Wed, 30 Oct 2019 17:50:19 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Making QUIC less constraining for innovation 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: Wed, 30 Oct 2019 06:50:41 -0000 I've written up this proposal here: https://github.com/quicwg/base-drafts/pull/3170 Thanks to everyone who provided input here. I think that I got all of it, but feel free to pitch in on the PR with notes about errors and omissions. The only bit of this that I'm hesitant over is the use of Expert Review for the provisional entries. I don't know if we could instead use First-Come, First-Served and rely on IANA to watch for spamming. It would probably be faster without an expert review step involved. On Thu, Oct 24, 2019, at 14:26, Martin Thomson wrote: > Issue 3020 (https://github.com/quicwg/base-drafts/issues/3020) raises > the question of IANA registration policies in the core drafts. The > thesis is that the constraints on registrations pushes people into a > small space of available numbers (in that specific case the space is > 256 values) or has registration requirements that are too onerous. > > We aim to address this in most places in QUIC and h3 with varints, > which all have a similar registration scheme. I think that David's > intent with #3020 was to push more of our code to use varints. But > we're nothing if not consistent when it comes to these things and after > lengthy discussion in Cupertino the group decided not to use varints > for transport parameters. > > Instead, we want to revise the registration policies to better allow > implementations to experiment with new features (which is what I think > David intended by the use of the word "innovation"). For varints, we > divide the space into three partitions: > > 0-63 = Standards Action > 64-16383 = Specification Required > 16384+ = Private Use > > David's PR #3109 (https://github.com/quicwg/base-drafts/pull/3109) > proposes the same split for transport parameters. That greatly > increases the size of the Private Use space. The Private Use section > is still a lot smaller than with varints, but the cut points are the > same and the belief is that ~2^16 values is plenty of room to play with. > > The main problem with all of these policies is described in RFC 6648, > namely that a codepoint from Private Use space can get wide adoption. > RFC 6648 basically concludes that these can be impossible to move to a > registered portion of the codepoint space. Furthermore, RFC 8126 says > that IANA doesn't register these codepoints and so no mechanism exists > to prevent collisions. That's a shame, because that's what registries > are for. > > --- > I propose that we instead remove Private Use space from specifications > and instead adopt a Specification Required policy for all codepoints > except the first 64 values of a varint value (we can keep that as > Standards Action). > > To allow for experimentation and proprietary extensions, add the > ability to provisionally register any codepoint. Provisional > registrations are registrations can omit values that would be required > for a permanent registration, include an expiry date, and operate on > First-Come, First-Served basis. > > This is intentionally lightweight so that anyone can initiate > registration, even without complete information. A Designated Expert > will be assigned to ensure that the registries don't end up crammed > with junk and to discourage use of codepoints with small encodings, > large blocks of codepoints, or codepoints that are likely to be used by > future standardization (those that are adjacent the first contiguous > block of allocated values, which we might want to use later). I > emphasize discourage intentionally, because this can't be a hard rule - > this is why we use a human for this job and not a machine. > > To recognize that people will inevitably use values before they even > provisionally register them, we should encourage people to select from > the space at random. Random selection from a larger space greatly > reduces the chances of collision. For varints, people will be > encouraged to choose values that have the longest encoding tolerable > for their use case. In particular, extensions that are fully > proprietary will be encouraged to use values that encode to 4 or 8 > bytes. I recognize that this might not avoid people having inflated > notions of the value of their extension. And maybe it's not worth > protecting the 2 byte space on the basis that we might never run out of > the 16320 values available. Either way, I think that it's worth > providing some text to help the expert in case this protocol gets > unexpectedly busy. > > Registrants are specify the codepoint they want when registering, > rather than have IANA make an allocation on request. For standards > that want to use codepoints that are adjacent the first set of values, > we might still use TBD in specifications to avoid having the same value > specified in multiple specifications. The TLS working group had the > same codepoint in three different drafts last year, which wasn't great. > > Provisional registrations can be removed or refreshed after a year > (period negotiable) after consultation with the expert, who is > encouraged to consult with the broader community. Experts would be > advised to refresh registrations unless there is evidence that the > value is no longer in use and there is a need to free up space for new > registrations. > > The motivation behind this proposal is to recognize that the overriding > goal of a protocol registry is to avoid the interoperability failures > that arise from codepoint collisions. In particular, registries are > not an access control mechanism. > > From nobody Tue Oct 29 23:52:11 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3155B1200B1 for ; Tue, 29 Oct 2019 23:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=OBOU3XE9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hGZPOj+a Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBfjwSdiyDlS for ; Tue, 29 Oct 2019 23:52:08 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831DA12008F for ; Tue, 29 Oct 2019 23:52:08 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E06813F4 for ; Wed, 30 Oct 2019 02:52:07 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 30 Oct 2019 02:52:08 -0400 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=fm3; bh=2RlLuLPZ29tiF37fB0fklNQWfTEE3QU Eaj/g3bIuZk0=; b=OBOU3XE9+lATmkdvFosLF6WyCN9rWlo4kgPZELTXL78BZOI 6c6x7AB8dLhDCAViu11Y7GjBYO4RXnQ0XwjM+hLSp21R2Sv6bU07rKEi1VVUYZaS 4FDf9lN9RYBOtNp1LPeHOH7eIZz8myuVF/knfM1EMQa4P6PbIlyzudoA9ySKXpR2 vfJvb+Ut64elytk7MHWwFUUey2qpSqkYddKZABzPbcv41DqS/RZLYY7YA5cnGxGm PT+rb0PbfL82sD5YYQHGquGHsL49d6hLoqrSNf3bIwG7K8Z70vE+zmpOQBpQcH9z Ve+0XCnx+z693QTi9i5uZVh63me0ATG1vUa3IqQ== 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=fm1; bh=2RlLuL PZ29tiF37fB0fklNQWfTEE3QUEaj/g3bIuZk0=; b=hGZPOj+a1tPgWEz6fvYTwJ OeM1L7OHM+VsykQCKw05CQkR+C2YBuSCtLqf45PUDUfDP4mC53As/48BGMTds6DL FL2cQWNq6DSbr1grqTMwPgwQNMTt+U895IY9ADeIlIRyUFJZrWVMJzWMLJJatV6d sxwumusZD/P33HkvLnh1KQHbmh7Mp371v6y3yRnOPbYR+TK/CeANRdWS5bonBeNH 2+s7yu+SdZEOXCMW8XU67oztFKYIFVJFCM6EexMU6PQgILjE9vpHGDQQQx/lC8D4 WGdfDfqk1a6LyQ+wjiZ6uFRV+Dqd3xyFMNjHivOoGsHTExmwVcqLMKpkw5dvkp0w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtvddguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslh hofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3C727E00A3; Wed, 30 Oct 2019 02:52:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> Date: Wed, 30 Oct 2019 17:51:49 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino 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: Wed, 30 Oct 2019 06:52:10 -0000 On Wed, Oct 30, 2019, at 16:08, Watson Ladd wrote: > Maybe it's worth writing down the state machine formally and trying to > use a model checker to show that there are no deadlocking pathways. > It's certainly confusing enough for me to have no idea. You aren't the first one to point this out. I think that the primary concern was lack of time and probably also lack of expertise. There are people looking into finding/funding work on validation of our handshake. From nobody Wed Oct 30 06:41:19 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3C51200FF for ; Wed, 30 Oct 2019 06:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=alibaba-inc.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 ENRv5X9u9WXw for ; Wed, 30 Oct 2019 06:41:15 -0700 (PDT) Received: from out0-155.mail.aliyun.com (out0-155.mail.aliyun.com [140.205.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6719E1200DE for ; Wed, 30 Oct 2019 06:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1572442871; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=gTDjGPvTR5DgS3hnxBA3HQwanlvBae+nfdiXupUKUNk=; b=n1MDBGFpYW8wb6n8eROunY347XYm6/uoSpSLvEEbuc9wCvNQdkKoqOjHPyZVqn9YQyTsEDpmw7Ga/43/J9S2E0fCE7D5yz1fAMGbVb+mtBaWRZEJboDm32VzFrSQHzGlgUupGdunU9sd+wHL49M97oAvEOHZrwoPpcEI3I9qjzg= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03292; MF=anqing.aq@alibaba-inc.com; NM=1; PH=DW; RN=4; SR=0; TI=W4_5657687_v5ForWebDing_0A9326DB_1572442075839_o7001c3975q; Received: from WS-web (anqing.aq@alibaba-inc.com[W4_5657687_v5ForWebDing_0A9326DB_1572442075839_o7001c3975q]) by e01l07406.eu6 at Wed, 30 Oct 2019 21:41:10 +0800 Date: Wed, 30 Oct 2019 21:41:10 +0800 From: "Qing An" To: "quic" , "jri.ietf" , "mt" Cc: "=?UTF-8?B?5YiY5aSn6bmPKOm5j+aIkCk=?=" Reply-To: "Qing An" Message-ID: <4974ed86-0fa9-435d-880f-80af637ef180.anqing.aq@alibaba-inc.com> Subject: =?UTF-8?B?RmFzdCBBZGRyZXNzIFZhbGlkYXRpb24gLSBhYm91dA==?= X-Mailer: [Alimail-Mailagent revision 2765257][W4_5657687][v5ForWebDing][Chrome] MIME-Version: 1.0 x-aliyun-mail-creator: W4_5657687_v5ForWebDing_NTMTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTVfMCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzc4LjAuMzkwNC43MCBTYWZhcmkvNTM3LjM2XQ Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_12452_53252940_5db992f6_2fa5a3" 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, 30 Oct 2019 13:41:18 -0000 ------=ALIBOUNDARY_12452_53252940_5db992f6_2fa5a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 CgpIaSBNYXJ0aW4sIEphbmEsIAoKSSByZWFkIHRocm91Z2ggaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aWQvZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yMy50eHQgYW5kIGhhdmUgYSBmZXcgY29tbWVu dHMgYW5kIGlkZWFzIHRvIGRpc2N1c3MuCgpbUVVJQy1UcmFuc10gZGVmaW5lcyBhIHRva2VuIGJh c2VkIHNjaGVtZSB0byBmYWNpbGl0YXRlIGFkZHJlc3MgdmFsaWRhdGlvbiBvZiBhIGNsaWVudC4g VGhlIHRva2VuIE1VU1QgYmUgY292ZXJlZCBieSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBhZ2FpbnN0 IG1vZGlmaWNhdGlvbiBvciBmYWxzaWZpY2F0aW9uIGJ5IGNsaWVudHMuIFRoZSBzZXJ2ZXIgcmVt ZW1iZXJzIHRoZSB2YWx1ZSBpdCBzZW5kcyB0byBjbGllbnRzIGFuZCB2YWxpZGF0ZXMgdGhlIHRv a2VuIHNlbnQgYmFjayBmcm9tIGEgY2xpZW50LiBJbiBpdHMgZGVzaWduLCBSZXRyeSBwYWNrZXQg aXMgdXNlZCB0byBkZWxpdmVyIHRoZSB0b2tlbiB0byBhIGNsaWVudCB3aGljaCBhZGRyZXNzIGhh cyBub3QgeWV0IGJlZW4gdmFsaWRhdGVkLiBJdCB2b2lkcyB0aGUgZmlyc3QgdHJhbnNtaXNzaW9u IG9mIHRoZSBJbml0aWFsIHBhY2tldCBzZW50IGJ5IHRoZSBjbGllbnQsIGFuZCB0cmlnZ2VycyBh IHNlY29uZCBJbml0aWFsIHBhY2tldCB0byBiZSBzZW50IHdpdGggdGhlIHRva2VuLiBUaGUgZXhj aGFuZ2Ugb2YgdG9rZW4gd2lsbCBjYXVzZSBsb25nZXIgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50 IGRlbGF5IGZvciBhIGNsaWVudC4KVG8gaW1wcm92ZSB0aGUgZWZmaWNpZW5jeSBvZiBhZGRyZXNz IHZhbGlkYXRpb24gZHVyaW5nIGhhbmRzaGFrZSwgb25lIGlkZWEgaXMgdGhhdCB0aGUgc2FtZSB0 b2tlbiBjYW4gYmUgZXhjaGFuZ2VkIHZpYSBhIGRpZmZlcmVudCBjb250YWluZXIgaS5lLiB0aGUg SGFuZHNoYWtlIHBhY2tldCwgdGhhdCBlbGltaW5hdGVzIHRoZSB1c2Ugb2YgUmV0cnkgcGFja2V0 IGZvciB0b2tlbiBkZWxpdmVyeS4gCgpJIGFtIHdvcmtpbmcgb24gdGhlIGNvbXBsZXRlIGRyYWZ0 IGFuZCB3aWxsIHN1Ym1pdCBpdCBieSBGcmlkYXkuIEJlZm9yZSB0aGF0LCBob3BlIHRoaXMgY2Fu IGJlIGRpc2N1c3NlZCBpbiBlbWFpbCBmaXJzdC4KCkJSLApRaW5nIEFu ------=ALIBOUNDARY_12452_53252940_5db992f6_2fa5a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iX19hbGl5dW5fZW1haWxfYm9keV9ibG9jayI+PGRpdiAgc3R5bGU9ImxpbmUt aGVpZ2h0OjEuNztmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1z aXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48YnIg PjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PGJyID48L2Rpdj48ZGl2ICBzdHlsZT0i Y2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0iY29sb3I6IzAwMDAwMDtmb250LWZhbWlseTpIZWx2 ZXRpY2EsVGFob21hLEFyaWFsO2ZvbnQtc2l6ZToxNC4wcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9u dC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQt d2VpZ2h0OjQwMDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7dGV4dC10cmFuc2Zv cm06bm9uZTtiYWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmlu aXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7ZmxvYXQ6bm9uZTtkaXNwbGF5Omlu bGluZTsiPkhpJm5ic3A7TWFydGluLCZuYnNwO0phbmEsJm5ic3A7PC9zcGFuPjxiciAgc3R5bGU9 Im91dGxpbmU6bm9uZSBtZWRpdW07Y29sb3I6IzAwMDAwMDtmb250LWZhbWlseTpIZWx2ZXRpY2Es VGFob21hLEFyaWFsO2ZvbnQtc2l6ZToxNC4wcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJp YW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0 OjQwMDtsZXR0ZXItc3BhY2luZzpub3JtYWw7b3JwaGFuczoyO3RleHQtYWxpZ246c3RhcnQ7dGV4 dC1pbmRlbnQ6LjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3aWRv d3M6Mjt3b3JkLXNwYWNpbmc6LjBweDsiPjxiciAgc3R5bGU9Im91dGxpbmU6bm9uZSBtZWRpdW07 Y29sb3I6IzAwMDAwMDtmb250LWZhbWlseTpIZWx2ZXRpY2EsVGFob21hLEFyaWFsO2ZvbnQtc2l6 ZToxNC4wcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDtsZXR0ZXItc3BhY2luZzpu b3JtYWw7b3JwaGFuczoyO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6LjBweDt0ZXh0LXRy YW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3aWRvd3M6Mjt3b3JkLXNwYWNpbmc6LjBw eDsiPjxzcGFuICBzdHlsZT0iY29sb3I6IzAwMDAwMDtmb250LWZhbWlseTpIZWx2ZXRpY2EsVGFo b21hLEFyaWFsO2ZvbnQtc2l6ZToxNC4wcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50 LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQw MDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7dGV4dC10cmFuc2Zvcm06bm9uZTti YWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4 dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7ZmxvYXQ6bm9uZTtkaXNwbGF5OmlubGluZTsiPkkm bmJzcDtyZWFkJm5ic3A7dGhyb3VnaCZuYnNwOzxhICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0LTIzLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yMy50eHQ8L2E+Jm5ic3A7PC9zcGFuPjxz cGFuICBzdHlsZT0iY29sb3I6IzAwMDAwMDtmb250LWZhbWlseTpIZWx2ZXRpY2EsVGFob21hLEFy aWFsO2ZvbnQtc2l6ZToxNC4wcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0 dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0 LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7dGV4dC10cmFuc2Zvcm06bm9uZTtiYWNrZ3Jv dW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNv cmF0aW9uLWNvbG9yOmluaXRpYWw7ZmxvYXQ6bm9uZTtkaXNwbGF5OmlubGluZTsiPmFuZCZuYnNw O2hhdmUgYSZuYnNwO2ZldyZuYnNwO2NvbW1lbnRzJm5ic3A7YW5kJm5ic3A7aWRlYXMgdG8gZGlz Y3Vzcy48L3NwYW4+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48YnIgPjwvZGl2Pjxk aXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PGRpdiAgc3R5bGU9Im1hcmdpbjouMHB4O3BhZGRpbmc6 LjBweDtib3JkZXI6LjBweDtvdXRsaW5lOi4wcHg7Y29sb3I6IzAwMDAwMDtmb250LWZhbWlseTpU YWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtmb250LXN0eWxlOm5v cm1hbDtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6LjBweDt0ZXh0 LXRyYW5zZm9ybTpub25lO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3Jh dGlvbi1jb2xvcjppbml0aWFsO2NsZWFyOmJvdGg7Ij5bUVVJQy1UcmFuc10gZGVmaW5lcyZuYnNw O2EmbmJzcDt0b2tlbiZuYnNwO2Jhc2VkJm5ic3A7c2NoZW1lIHRvJm5ic3A7ZmFjaWxpdGF0ZSZu YnNwO2FkZHJlc3MmbmJzcDt2YWxpZGF0aW9uJm5ic3A7b2YmbmJzcDthJm5ic3A7Y2xpZW50LiZu YnNwO1RoZSZuYnNwO3Rva2VuJm5ic3A7TVVTVCZuYnNwO2JlJm5ic3A7Y292ZXJlZCZuYnNwO2J5 IGludGVncml0eSBwcm90ZWN0aW9uJm5ic3A7YWdhaW5zdCZuYnNwO21vZGlmaWNhdGlvbiZuYnNw O29yJm5ic3A7ZmFsc2lmaWNhdGlvbiZuYnNwO2J5Jm5ic3A7Y2xpZW50cy4mbmJzcDtUaGUgc2Vy dmVyJm5ic3A7cmVtZW1iZXJzIHRoZSZuYnNwO3ZhbHVlIGl0IHNlbmRzIHRvJm5ic3A7Y2xpZW50 cyZuYnNwO2FuZCZuYnNwO3ZhbGlkYXRlcyZuYnNwO3RoZSZuYnNwO3Rva2VuJm5ic3A7c2VudCBi YWNrJm5ic3A7ZnJvbSZuYnNwO2EmbmJzcDtjbGllbnQuJm5ic3A7SW4mbmJzcDtpdHMmbmJzcDtk ZXNpZ24sJm5ic3A7UmV0cnkmbmJzcDtwYWNrZXQmbmJzcDtpcyZuYnNwO3VzZWQmbmJzcDt0byZu YnNwO2RlbGl2ZXImbmJzcDt0aGUmbmJzcDt0b2tlbiZuYnNwO3RvIGEmbmJzcDtjbGllbnQmbmJz cDt3aGljaCZuYnNwO2FkZHJlc3MmbmJzcDtoYXMmbmJzcDtub3QmbmJzcDt5ZXQmbmJzcDtiZWVu Jm5ic3A7dmFsaWRhdGVkLiBJdCZuYnNwO3ZvaWRzJm5ic3A7dGhlJm5ic3A7Zmlyc3QgdHJhbnNt aXNzaW9uJm5ic3A7b2YgdGhlJm5ic3A7SW5pdGlhbCBwYWNrZXQgc2VudCBieSB0aGUgY2xpZW50 LCBhbmQmbmJzcDt0cmlnZ2VycyZuYnNwO2EmbmJzcDtzZWNvbmQgSW5pdGlhbCZuYnNwO3BhY2tl dCZuYnNwO3RvJm5ic3A7YmUmbmJzcDtzZW50Jm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwO3Rva2Vu LiZuYnNwO1RoZSZuYnNwO2V4Y2hhbmdlJm5ic3A7b2YmbmJzcDt0b2tlbiZuYnNwO3dpbGwmbmJz cDtjYXVzZSBsb25nZXImbmJzcDtjb25uZWN0aW9uJm5ic3A7ZXN0YWJsaXNobWVudCZuYnNwO2Rl bGF5Jm5ic3A7Zm9yJm5ic3A7YSZuYnNwO2NsaWVudC48L2Rpdj48ZGl2ICBzdHlsZT0ibWFyZ2lu Oi4wcHg7cGFkZGluZzouMHB4O2JvcmRlcjouMHB4O291dGxpbmU6LjBweDtjb2xvcjojMDAwMDAw O2ZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNpbVN1bjtmb250LXNpemU6MTQuMHB4 O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWlu ZGVudDouMHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRp YWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Y2xlYXI6Ym90aDsiPiZuYnNwOzwvZGl2 PjxzcGFuICBzdHlsZT0ibWFyZ2luOi4wcHg7cGFkZGluZzouMHB4O2JvcmRlcjouMHB4O291dGxp bmU6LjBweDtjb2xvcjojMDAwMDAwO2ZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNp bVN1bjtmb250LXNpemU6MTQuMHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1saWdh dHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4 dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDouMHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7dGV4dC1k ZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Ij5U byZuYnNwO2ltcHJvdmUmbmJzcDt0aGUmbmJzcDtlZmZpY2llbmN5Jm5ic3A7b2YmbmJzcDthZGRy ZXNzJm5ic3A7dmFsaWRhdGlvbiZuYnNwO2R1cmluZyZuYnNwO2hhbmRzaGFrZSwgb25lIGlkZWEg aXMgdGhhdCB0aGUmbmJzcDtzYW1lIHRva2VuIGNhbiBiZSBleGNoYW5nZWQmbmJzcDt2aWEmbmJz cDthJm5ic3A7ZGlmZmVyZW50Jm5ic3A7Y29udGFpbmVyJm5ic3A7aS5lLiZuYnNwO3RoZSZuYnNw O0hhbmRzaGFrZSZuYnNwO3BhY2tldCwmbmJzcDt0aGF0IGVsaW1pbmF0ZXMgdGhlIHVzZSZuYnNw O29mJm5ic3A7UmV0cnkmbmJzcDtwYWNrZXQgZm9yJm5ic3A7dG9rZW4gZGVsaXZlcnkuJm5ic3A7 PC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJtYXJn aW46LjBweDtwYWRkaW5nOi4wcHg7Ym9yZGVyOi4wcHg7b3V0bGluZTouMHB4O2NvbG9yOiMwMDAw MDA7Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4w cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQt aW5kZW50Oi4wcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5p dGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDsiPjxiciA+PC9zcGFuPjwvZGl2Pjxk aXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJtYXJnaW46LjBweDtwYWRkaW5n Oi4wcHg7Ym9yZGVyOi4wcHg7b3V0bGluZTouMHB4O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1pbHk6 VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7Zm9udC1zdHlsZTpu b3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7dGV4 dC10cmFuc2Zvcm06bm9uZTt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29y YXRpb24tY29sb3I6aW5pdGlhbDsiPkkgYW0gd29ya2luZyBvbiB0aGUgY29tcGxldGUgZHJhZnQg YW5kIHdpbGwgc3VibWl0IGl0IGJ5IEZyaWRheS4gQmVmb3JlIHRoYXQsIGg8L3NwYW4+b3BlIHRo aXMgY2FuIGJlIGRpc2N1c3NlZCBpbiBlbWFpbCBmaXJzdC48L2Rpdj48ZGl2ICBzdHlsZT0iY2xl YXI6Ym90aDsiPjxiciA+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij5CUiw8L2Rpdj48 ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPlFpbmcgQW48L2Rpdj48L2Rpdj48L2Rpdj4= ------=ALIBOUNDARY_12452_53252940_5db992f6_2fa5a3-- From nobody Wed Oct 30 06:56:08 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1C8120112 for ; Wed, 30 Oct 2019 06:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, UNPARSEABLE_RELAY=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 Uhp2AGYg-Rbw for ; Wed, 30 Oct 2019 06:56:05 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 3AA3D1200DE for ; Wed, 30 Oct 2019 06:56:05 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id c4so1836412edl.0 for ; Wed, 30 Oct 2019 06:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=GWbS4qMg+mM62dLJLcicy2r7kUAk8CgocRAE0EFlE34=; b=g5S6tUXJ375ETlseQbPf/DpRbBM6mibuKjujlZB2VI6ISKshClfz96c20LsiOLEm57 RSRizzLl8LBZGppZnWQzaCNuDzoEb5WWIObfOGxaalO5BgASst8vmY8Jblam7LExlPKV IoIMuRfOlhd87FPO9zrfr4K74aBU1qRFXtkDfq1XVy2D3hydriFo+v8ybusB+0A7+bN7 39fAnXpbAaVbLmLcm8CPd+ZLQL1Ji+sUsl3+ktLBglxBzriZtswyf+O0RWLMcUem9rOO buPLrCOnHTbedUBYjSX0oCuTIwrfmlrG5cCeR/7/93z5G+7d/Vn940sNttAJq3F6C05m CwdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=GWbS4qMg+mM62dLJLcicy2r7kUAk8CgocRAE0EFlE34=; b=sGLvAzYzrKFXEF8phhJ6rCHkiRibDo0VUAJFTBETzTGrMtZHVBeotokWFIoUT8GvIG cBYWhnTjgNsv60el/y+ey7vaqSvqoA116TlC61zC1XoVyUUOZJDRae/9Z20Uy/zwb1jf H52l3kU+FQwdCEHwuYI1L0Zbk5JGqF1lkG3ANQYf/Y7eYWEBseqX4JahCb4hO3f42oHV sa1+efwmirCKWDu52mgkSokzVzSvg/pLv5OWuvkrrajSJMZGoZKkb1Wf0H0wctJYgLii 9HcpHx/ekjWPOY6NaaJxARvsyjFmQV9hyVKJCXOFgwa/gWNKhYyzs98Tu4uu6ZcGU/or NdsQ== X-Gm-Message-State: APjAAAUQuORgXAMYmrwMRZPFFX+vWZCR5gtJ3MyOG15nrGRoU5DdzvXR An23vsKRYa08tT80BC5EJt1FFSV2f+iPhsXJGE8= X-Google-Smtp-Source: APXvYqxy6EGMqmqZorHJeWgFRBrLGDo6K1hR6TEh5OBHKOQ2BOLm0icLW5fq53TSimfjirHGJK/44FhyPmybjpbcnME= X-Received: by 2002:a05:6402:488:: with SMTP id k8mr31611307edv.293.1572443763839; Wed, 30 Oct 2019 06:56:03 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 30 Oct 2019 13:56:03 +0000 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <4974ed86-0fa9-435d-880f-80af637ef180.anqing.aq@alibaba-inc.com> References: <4974ed86-0fa9-435d-880f-80af637ef180.anqing.aq@alibaba-inc.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 30 Oct 2019 13:56:03 +0000 Message-ID: Subject: Re: Fast Address Validation - about To: Qing An , "jri.ietf" , quic , mt Cc: =?UTF-8?B?5YiY5aSn6bmPKOm5j+aIkCk=?= Content-Type: multipart/alternative; boundary="000000000000f915b0059621179f" 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, 30 Oct 2019 13:56:07 -0000 --000000000000f915b0059621179f Content-Type: text/plain; charset="UTF-8" Please keep in mind that Retry can be used by a server that does not want to spend resources on the handshake and to redirect traffic elsewhere, it is not just for validation. And when it is not a redirect, the server might want the roundtrip to make sure the client is really interested and able before committing resources to process the handshake. Thus, trying to optimise this step might work against the idea, at least for some use cases. Mikkel On 30 October 2019 at 14.41.29, Qing An (anqing.aq@alibaba-inc.com) wrote: Hi Martin, Jana, I read through https://www.ietf.org/id/draft-ietf-quic-transport-23.txt and have a few comments and ideas to discuss. [QUIC-Trans] defines a token based scheme to facilitate address validation of a client. The token MUST be covered by integrity protection against modification or falsification by clients. The server remembers the value it sends to clients and validates the token sent back from a client. In its design, Retry packet is used to deliver the token to a client which address has not yet been validated. It voids the first transmission of the Initial packet sent by the client, and triggers a second Initial packet to be sent with the token. The exchange of token will cause longer connection establishment delay for a client. To improve the efficiency of address validation during handshake, one idea is that the same token can be exchanged via a different container i.e. the Handshake packet, that eliminates the use of Retry packet for token delivery. I am working on the complete draft and will submit it by Friday. Before that, hope this can be discussed in email first. BR, Qing An --000000000000f915b0059621179f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Please keep in mind = that Retry can be used by a server that does not want to spend resources on= the handshake and to redirect traffic elsewhere, it is not just for valida= tion. And when it is not a redirect, the server might want the roundtrip to= make sure the client is really interested and able before committing resou= rces to process the handshake.

Thus, trying to optimise this step might work against the idea, a= t least for some use cases.

Mikkel


On 30 October 2019 at 14.41.29, Qin= g An (anqing.aq@alibaba-inc.co= m) wrote:

<= div>


Hi=C2=A0Martin,=C2=A0Jana,=C2=A0

I=C2=A0read=C2=A0through=C2=A0https://www.ietf.org/id/draft-ietf-quic-transport-2= 3.txt=C2=A0and=C2=A0have a=C2=A0few=C2=A0comments=C2=A0and=C2=A0ideas to discuss.

[QUIC-Trans] defines=C2=A0a=C2=A0token=C2=A0based=C2=A0scheme to=C2=A0facilitate=C2=A0address=C2=A0validation=C2=A0of=C2=A0a=C2=A0client.= =C2=A0The=C2=A0token=C2=A0MUST=C2=A0be=C2=A0covered=C2=A0by integrity protection=C2=A0against=C2=A0modification=C2=A0or=C2=A0falsification=C2=A0b= y=C2=A0clients.=C2=A0The server=C2=A0remembers the=C2=A0value it sends to=C2=A0clients=C2=A0and=C2=A0validates=C2=A0the=C2=A0token=C2=A0sent back=C2=A0from=C2=A0a=C2=A0client.=C2=A0In=C2=A0its=C2=A0design,=C2=A0Retry= =C2=A0packet=C2=A0is=C2=A0used=C2=A0to=C2=A0deliver=C2=A0the=C2=A0token=C2= =A0to a=C2=A0client=C2=A0which=C2=A0address=C2=A0has=C2=A0not=C2=A0yet=C2=A0been= =C2=A0validated. It=C2=A0voids=C2=A0the=C2=A0first transmission=C2=A0of the=C2=A0Initial packet sent by the client, and=C2=A0triggers=C2=A0a=C2=A0second Initial=C2=A0packet=C2=A0to=C2=A0be=C2=A0sent=C2=A0with=C2=A0the=C2=A0token= .=C2=A0The=C2=A0exchange=C2=A0of=C2=A0token=C2=A0will=C2=A0cause longer=C2=A0connection=C2=A0establishment=C2=A0delay=C2=A0for=C2=A0a=C2=A0c= lient.
=C2=A0
To=C2=A0improve=C2=A0the=C2=A0effic= iency=C2=A0of=C2=A0address=C2=A0validation=C2=A0during=C2=A0handshake, one idea is that the=C2=A0same token can be exchanged=C2=A0via=C2=A0a=C2=A0different=C2=A0container=C2=A0i.e.=C2=A0the= =C2=A0Handshake=C2=A0packet,=C2=A0that eliminates the use=C2=A0of=C2=A0Retry=C2=A0packet for=C2=A0token delivery.=C2=A0

I am working on the complete draft and will submit it by Friday. Before that, hope this can be discussed in email first.

BR,
Qing An
--000000000000f915b0059621179f-- From nobody Wed Oct 30 08:45:53 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C46120964 for ; Wed, 30 Oct 2019 08:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 ZVtqhtpwGRdz for ; Wed, 30 Oct 2019 08:45:48 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800090.outbound.protection.outlook.com [40.107.80.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7D0120BE2 for ; Wed, 30 Oct 2019 08:45:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IfLar252eMiTYYOVT69qkrb1MUU+5mkt7BA5wpKK0fCLF3vMwc5sGkuTvD2AzfRHjuadoHAo7ujkZIBVI8Hony5MX3uDRSRxV1ceDLDxYVR5OPDqVAnWCUw0ekIMle4vRe7kPuciwncNebNgOQqO83qYV6owntzjx3o/ZQR/9Uky4Y4j2vLd/hC2298XWoKyyKKbad+i8PdQybKLc1kjQXKxqHMZ66W44EuR+BKQpTb3O8LcOUs6+M25IGrXDssZL0QFfs+A1/STVkfgrgWW5Nmh0RbWzuiqA0OyrNdcFbgoa80zYB2Edvmmup5jdUDBjHzSLsg5c6E6PR87IUceHA== 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=yN23Gb+cOgn+Zfz6leSDOGxVIxG/6oFxpjYGmit/Q/s=; b=bZphZDdMv2E4zRe2e/wgkF3GBQxaeli2qrKYSyx9tVEUz36W5oImeyggIlz5HeKam+Aov07gabwD471jpN0jd5dNfMeTFNrcjQXAHFAQlLedR5o76CxmDHRU/TquDm/vf1rRL6a62wshPL5PH0Ctsw0zAifgzfCqAbRUZeHsh3HbGUXJxEECXBtpshPT5JIRmY8RcC9WozWvgsu++92oaVwsO2hImrUa7dxmBrQ2P1ezF9nHNVvqul7Bnp72bsHHEu2khcVU0BZzboGbBr48CcPHNH8zjs+Ye+UUcxdfZWj48F4Y7OSI8TyYIU+/NAYJVECbyLb427G/XU8cxDEibA== 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=yN23Gb+cOgn+Zfz6leSDOGxVIxG/6oFxpjYGmit/Q/s=; b=jDL/IZsoIcm75nx5vOJfgbU8xBFKgFz0YzcIIZKK+f+1si6YqoPBYqUAgXG251DQ5AU2E/zd51RoUbl0uW6sBy0WVCE7/5HdijVb6ho7lmds8OLXKh7wJDHVxD8fGVxpimzT8GNQgf88TFEvjsFZcmNDaC9aSs3driCHwt1kVP0= Received: from BN6PR2201MB1700.namprd22.prod.outlook.com (10.161.152.144) by BN6PR2201MB1298.namprd22.prod.outlook.com (10.174.80.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.23; Wed, 30 Oct 2019 15:45:46 +0000 Received: from BN6PR2201MB1700.namprd22.prod.outlook.com ([fe80::7cb4:5e4e:334c:a737]) by BN6PR2201MB1700.namprd22.prod.outlook.com ([fe80::7cb4:5e4e:334c:a737%7]) with mapi id 15.20.2387.028; Wed, 30 Oct 2019 15:45:46 +0000 From: Mike Bishop To: Martin Thomson , "quic@ietf.org" Subject: RE: Consensus Calls for Transport/TLS issues, post-Cupertino Thread-Topic: Consensus Calls for Transport/TLS issues, post-Cupertino Thread-Index: AQHViHGZIuF5g6IoEE6LYrhgawqNGqdl3+KAgAACSQCAABB9gIAAJugAgAAEuICAACuwgIAAzYuAgAF9CnCAAIMlAIACfAKAgAOQaICAAD7ngIABXIYAgAE7BRCAAFqWgIABBsHw Date: Wed, 30 Oct 2019 15:45:45 +0000 Message-ID: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> 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: [2600:2b00:931f:a301:d929:1930:fc03:fdc0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5b8c4e34-ec34-4026-140a-08d75d503ae9 x-ms-traffictypediagnostic: BN6PR2201MB1298: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(396003)(136003)(376002)(346002)(366004)(199004)(189003)(13464003)(51444003)(2501003)(86362001)(305945005)(7736002)(52536014)(8676002)(508600001)(81166006)(8936002)(81156014)(33656002)(71190400001)(71200400001)(6436002)(25786009)(2906002)(316002)(5660300002)(9686003)(55016002)(53546011)(76176011)(102836004)(6506007)(7696005)(486006)(11346002)(74316002)(476003)(446003)(99286004)(186003)(46003)(6116002)(66476007)(66946007)(76116006)(66446008)(66556008)(64756008)(256004)(110136005)(14454004)(229853002)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR2201MB1298; H:BN6PR2201MB1700.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: 7IVwVdmIcMsYwO8GTd7umpW2Vioo4U2QLErPEGic7ZW3SX2gs9E8qH5bTVyo9O63zWjaPp5m7TW9XJESeEp2DK/ZdyZiOzrqOntAVWVMBxDAw5O4pR60LcGPlwTQ1Ms0MEB0QKNkl7cM7S8RK+CNSjHBQVtZlceMEXIv3vOUPGO16xVQIjJwGRaTkn/zZ+VFjK+eBxYgt+eBKPlmAhnMo0QfEXsoZHvSSKXQ+o89CjVaNQJkBURiLSLifFu5kChcAXI7/YxLmlfkm8C3UXb7NnqXY9HzlktDBCxLFPtNLvNaTBvOujpDO24zGNLPvVP3uMOShPnuccvqYxOwtqiuGq/92Z3pKc5jn+OtcwqJKfCWH9iaQ8ErqHqum/EyBE+osKKFB/RG9EJf0GjamWGBP6asNu+5Gys4avtjVII6JRbFOrItdn5r3hFMqu+fAUA2 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 5b8c4e34-ec34-4026-140a-08d75d503ae9 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2019 15:45:45.8377 (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: gcjEgxXheW79wutgkZwjdHLZAKbmI/ZhDFzC3iNVQnsVhHqraoSu4ntnhwhZWe50l4HFfbEXSXTqgLj5Nziv4g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1298 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, 30 Oct 2019 15:45:52 -0000 And this is the piece I'm not getting, I think. The minimum requirement for the server to know the client got the whole han= dshake is to receive the Client Finished; receipt of any 1-RTT traffic from= the client demonstrates they derived the correct keys. The server can dro= p Handshake keys at that point. However, the server can no longer retransm= it the ACK or even know if it was delivered, so the client needs a reliable= sync point based on 1-RTT traffic to know that the server received the Cli= ent Finished. Since the server can send 1-RTT packets before the handshake completes, rec= eipt of 1-RTT packets isn't sufficient. Since the 0-RTT and 1-RTT packets = share a space, receiving an ACK in a 1-RTT packet isn't sufficient. The cl= ient knows that the server has seen the whole handshake once it receives an= ACK of a 1-RTT packet. As soon as any packet sent in 1-RTT is ACK'd, the = client can drop handshake keys. As you explain in the other fork, organic traffic isn't sufficient, so we h= ave to force something into 1-RTT to ensure these signals happen. If the c= lient sends HANDSHAKE_DONE in 1-RTT, probably coalesced with Client Finishe= d, that's an ack-eliciting 1-RTT packet. The server will ACK it; if the AC= K gets lost, the client will PTO its 1-RTT packet and the server will ack *= that*, and so on. Eventually the client gets an ACK of a 1-RTT packet, whi= ch is what it needs. It drops keys. If the server sends HANDSHAKE_DONE upon receipt of the Finished, that is a = more direct signal, and the client can drop keys upon receipt of that frame= . If the ACK of the server's HANDSHAKE_DONE gets lost, the server will PTO= it, and the client will ACK, and so on. But those things aren't really nec= essary -- the client and server have both already gotten their signal. I c= an see the appeal of having the server send it, so that we're not driving o= ff of ACKs of particular packets. The only reason I see for both sides to send it is distaste for implicit ac= knowledgements, trying to avoid letting the Client Finished be what tells t= he server that all its Handshake data clearly made it. Is this just prefer= ence for one solution over another, or is there a technical reason I'm miss= ing? -----Original Message----- From: QUIC On Behalf Of Martin Thomson Sent: Tuesday, October 29, 2019 7:46 PM To: quic@ietf.org Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino On Wed, Oct 30, 2019, at 05:26, Mike Bishop wrote: > Therefore, ACK works iff we *know* that the client sent something=20 > ack-eliciting in 1-RTT. I think that you have to make it symmetric, not just "client sends". Becau= se we don't have implicit acknowledgement for Handshake packets from the se= rver, the server can enter the same state that the client does in Marten's = deadlock scenario. In other words, both need to send something ack-eliciti= ng. And it's not just anything at any time, it has to be anything within s= ome bounded time. The upper bound is probably high, but it is at least bef= ore the Handshake packets consume all the available congestion window (whic= h might be a long time, but I haven't worked out how long that could take). > So one solution is to require clients to send ....and servers :) From nobody Wed Oct 30 09:07:40 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC94120113 for ; Wed, 30 Oct 2019 09:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, UNPARSEABLE_RELAY=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 mHelnBhb_aau for ; Wed, 30 Oct 2019 09:07:37 -0700 (PDT) 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 735F8120110 for ; Wed, 30 Oct 2019 09:07:37 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id f25so2169476edw.10 for ; Wed, 30 Oct 2019 09:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=4aBnf9IyV5STVZDfJ4gOe04RHR/lhsQkfl6z6zWBKcc=; b=fIAY0P/+qlbFBhodNiqCFriB4EhD/Ul19m8JGvwKwXrOCOfjZmUqmdBiaMv3dan2lQ 7qP0DCzG7+XdkVnoGvNcYwRRrzYnaxjgqiCxOXQClqnAWqFnO/p31QSBnct9TnRlRSq0 Ae7/P2wdTA+o2yOgP7tcblwRza7c4zE2BVv5Lvd8KNp8i4/ekn4dDzEAWS6axn693xFq 7FyNm2rsb/Cng7zr0RY8TCNdD+t+eO8OKyZwAVPGO5PFvWufMBtSRCnyQODtvW7chu3r IB+9OAeNaOqGpV3cZy0ndxOGmKm4AYZ2LecoynBJTq0geNq2oym/UVepeN+rjzTzeFdq OSJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=4aBnf9IyV5STVZDfJ4gOe04RHR/lhsQkfl6z6zWBKcc=; b=F/rETOeooV9EUgzkeQc16LBxcF00hp7Jc24mx28qVZUo0t2pnvRXNNCwq0jDV4Q4Ch GQD6+1HhahHpjYK7G0kBhh/vjXPc4EJYJ0oynAnGGn4SpkQwCM3J3S7z/7cXhwKfS/yO 9pXC1luxKiqp2PCJtVIqa0Yz/9lFBVrlV9tlkqyokjwgWUh/OT6m82xNDb74RkCi6yPJ myiuFj7XQwbxbDLHYsmRmgiMAXIJt1mvbSPPCDBkieDLGmVbZRe4FYTMeq786Qr0QPX8 tVuu2j1Jn0Ak8pcVe3ps3TZFh8gpXEimWHq1Qx8tkDPmgpCJDivUs8A15yTiYXBNsZC1 CRVg== X-Gm-Message-State: APjAAAWsepASFTsJ+ZkIiHSpLljtVcqrL0fLS5Yd6EeFjbIo0Cwvnx7Y FYrptU0iMGWM5M4+UuTis4CnTJgsolpWpgqrUppF8igW X-Google-Smtp-Source: APXvYqzTjg4scWlHZrjpN4knstH4we19DbfwSU6ct3QwAEdO6ABZ0kE7fz/X/Dr3ad4n0XhI9b1OgU2VQ6Q3RabIGX8= X-Received: by 2002:a50:b723:: with SMTP id g32mr456479ede.13.1572451656016; Wed, 30 Oct 2019 09:07:36 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 30 Oct 2019 12:07:35 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 30 Oct 2019 12:07:35 -0400 Message-ID: Subject: RE: Consensus Calls for Transport/TLS issues, post-Cupertino To: Mike Bishop , Martin Thomson , "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000622b1e059622ee01" 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, 30 Oct 2019 16:07:39 -0000 --000000000000622b1e059622ee01 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t see a need for HANDSHAKE_DONE in both directions although i= t won=E2=80=99t hurt. An argument for symmetric HANDSHAKE_DONE is that it decouples the handshake transition from the handshake logic which makes it easier to replace TLS with something simpler, for example in a QUIC version for constrained devices. On 30 October 2019 at 16.46.10, Mike Bishop (mbishop@evequefou.be) wrote: And this is the piece I'm not getting, I think. The minimum requirement for the server to know the client got the whole handshake is to receive the Client Finished; receipt of any 1-RTT traffic from the client demonstrates they derived the correct keys. The server can drop Handshake keys at that point. However, the server can no longer retransmit the ACK or even know if it was delivered, so the client needs a reliable sync point based on 1-RTT traffic to know that the server received the Client Finished. Since the server can send 1-RTT packets before the handshake completes, receipt of 1-RTT packets isn't sufficient. Since the 0-RTT and 1-RTT packets share a space, receiving an ACK in a 1-RTT packet isn't sufficient. The client knows that the server has seen the whole handshake once it receives an ACK of a 1-RTT packet. As soon as any packet sent in 1-RTT is ACK'd, the client can drop handshake keys. As you explain in the other fork, organic traffic isn't sufficient, so we have to force something into 1-RTT to ensure these signals happen. If the client sends HANDSHAKE_DONE in 1-RTT, probably coalesced with Client Finished, that's an ack-eliciting 1-RTT packet. The server will ACK it; if the ACK gets lost, the client will PTO its 1-RTT packet and the server will ack *that*, and so on. Eventually the client gets an ACK of a 1-RTT packet, which is what it needs. It drops keys. If the server sends HANDSHAKE_DONE upon receipt of the Finished, that is a more direct signal, and the client can drop keys upon receipt of that frame.. If the ACK of the server's HANDSHAKE_DONE gets lost, the server will PTO it, and the client will ACK, and so on. But those things aren't really necessary -- the client and server have both already gotten their signal. I can see the appeal of having the server send it, so that we're not driving off of ACKs of particular packets. The only reason I see for both sides to send it is distaste for implicit acknowledgements, trying to avoid letting the Client Finished be what tells the server that all its Handshake data clearly made it. Is this just preference for one solution over another, or is there a technical reason I'm missing? -----Original Message----- From: QUIC On Behalf Of Martin Thomson Sent: Tuesday, October 29, 2019 7:46 PM To: quic@ietf.org Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino On Wed, Oct 30, 2019, at 05:26, Mike Bishop wrote: > Therefore, ACK works iff we *know* that the client sent something > ack-eliciting in 1-RTT. I think that you have to make it symmetric, not just "client sends". Because we don't have implicit acknowledgement for Handshake packets from the server, the server can enter the same state that the client does in Marten's deadlock scenario. In other words, both need to send something ack-eliciting. And it's not just anything at any time, it has to be anything within some bounded time. The upper bound is probably high, but it is at least before the Handshake packets consume all the available congestion window (which might be a long time, but I haven't worked out how long that could take). > So one solution is to require clients to send .....and servers :) --000000000000622b1e059622ee01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I don=E2=80=99t see = a need for HANDSHAKE_DONE in both directions although it won=E2=80=99t hurt= .

<= div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:= 13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">An argument for sym= metric HANDSHAKE_DONE is that it decouples the handshake transition from th= e handshake logic which makes it easier to replace TLS with something simpl= er, for example in a QUIC version for constrained devices.

On 30 October 2019 at 16.46.10, Mike Bishop (mbishop@evequefou.be) wrote:

And this is the piece I= 9;m not getting, I think.

The minimum requirement for the server to know the client got the whole= handshake is to receive the Client Finished; receipt of any 1-RTT traffic = from the client demonstrates they derived the correct keys. The server can= drop Handshake keys at that point. However, the server can no longer retr= ansmit the ACK or even know if it was delivered, so the client needs a reli= able sync point based on 1-RTT traffic to know that the server received the= Client Finished.

Since the server can send 1-RTT packets before the handshake completes,= receipt of 1-RTT packets isn't sufficient. Since the 0-RTT and 1-RTT = packets share a space, receiving an ACK in a 1-RTT packet isn't suffici= ent. The client knows that the server has seen the whole handshake once it= receives an ACK of a 1-RTT packet. As soon as any packet sent in 1-RTT is= ACK'd, the client can drop handshake keys.

As you explain in the other fork, organic traffic isn't sufficient,= so we have to force something into 1-RTT to ensure these signals happen. = If the client sends HANDSHAKE_DONE in 1-RTT, probably coalesced with Client= Finished, that's an ack-eliciting 1-RTT packet. The server will ACK i= t; if the ACK gets lost, the client will PTO its 1-RTT packet and the serve= r will ack *that*, and so on. Eventually the client gets an ACK of a 1-RTT= packet, which is what it needs. It drops keys.

If the server sends HANDSHAKE_DONE upon receipt of the Finished, that i= s a more direct signal, and the client can drop keys upon receipt of that f= rame.. If the ACK of the server's HANDSHAKE_DONE gets lost, the server= will PTO it, and the client will ACK, and so on. But those things aren'= ;t really necessary -- the client and server have both already gotten their= signal. I can see the appeal of having the server send it, so that we'= ;re not driving off of ACKs of particular packets.

The only reason I see for both sides to send it is distaste for implici= t acknowledgements, trying to avoid letting the Client Finished be what tel= ls the server that all its Handshake data clearly made it. Is this just pr= eference for one solution over another, or is there a technical reason I= 9;m missing?

-----Original Message-----
From: QUIC <quic-bounces@ie= tf.org> On Behalf Of Martin Thomson
Sent: Tuesday, October 29, 2019 7:46 PM
To: quic@ietf.org
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino

On Wed, Oct 30, 2019, at 05:26, Mike Bishop wrote:
> Therefore, ACK works iff we *know* that the client sent something = =20
> ack-eliciting in 1-RTT.

I think that you have to make it symmetric, not just "client sends= ". Because we don't have implicit acknowledgement for Handshake p= ackets from the server, the server can enter the same state that the client= does in Marten's deadlock scenario. In other words, both need to send= something ack-eliciting. And it's not just anything at any time, it h= as to be anything within some bounded time. The upper bound is probably hi= gh, but it is at least before the Handshake packets consume all the availab= le congestion window (which might be a long time, but I haven't worked = out how long that could take).

> So one solution is to require clients to send

.....and servers :)

--000000000000622b1e059622ee01-- From nobody Wed Oct 30 09:29:18 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB10120133 for ; Wed, 30 Oct 2019 09:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=ham 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 o9HZ0dZR8UOf for ; Wed, 30 Oct 2019 09:29:13 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730099.outbound.protection.outlook.com [40.107.73.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10E3120108 for ; Wed, 30 Oct 2019 09:29:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jsdPBke1GWthEMNaBRrkUVbTXMleiyP0Z7mmqgxfeJx2WGn4l1tKDq5zxsUrYZ4tgA1QR6UdyVYg4gTXys6UjvzFsbbYwNk4oJtmVVOM20psEkH6wvTHMCRbyfWlHyPn280fCoGFdnAkXfegdC6wkf/gqSrilZoAFEpMAv9QBVzDK6BNfmVDFY98YAHI15FoXJyKLLaTskBNRvrbkxTMjHJbjhaBC7nRdYDKVIUPRZ1Li1x+tIBrYQ5I9ojwrYv2aW/pg6yyH5iDGTXq3Gkd8O+eieU6dPV7cTBPQjA0RrpWMXuXkG+gGrxEImvXFJjtdk3NQmwkGkXFXhecQaPrFA== 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=iFM++fOWI+d2gOICzCd4Uy5rKigeULtlpwZvpjxvveo=; b=myu9cmLi4vGBE7QrxWNn9dddTOiyf40Lopa7z92o6BOexylsdYJm+rlSw32m1LR2r21FRWICeyp4tD55sKKOyYRuZKAevS3wEB+hOf8p3BbeOQTcUNpksDav4HyWJwasXdijpggBxoGnVW8jKv2zpyI18mB2Fny/d0vFBVY+09eTnAqp5peUKnmOWS3GOvY15k2L4AEAae77pcjgZy+53w8GmuLx/to90+I1iGcKsI20BfJEL8N/o1qlN5+e8PrvYAw7Tjsijeesyvxn05inKSJigCnx4caMQaa70GqR3vhLMmvIRVZj5uImF3RlpLND+nau7Us2N3sp80n8POCJ5w== 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=iFM++fOWI+d2gOICzCd4Uy5rKigeULtlpwZvpjxvveo=; b=VMIOD/91OQ5KUEVQyK5OG+ArtPf9gdWBhlQ/NI6T4Z1J2eXxKsh2+UmyBS5zW2nIFdFMAJuqHiZh2oUt3PrK+i5XerQ2ST7HO1B064kdSLaxWfQsDl9LH1ZwCktlruXyMn74C1OPR3ySFP11Dc3bitq6LRGlT/uiL2vspQi/ye0= Received: from BN6PR2201MB1700.namprd22.prod.outlook.com (10.161.152.144) by BN6PR2201MB1330.namprd22.prod.outlook.com (10.174.81.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.24; Wed, 30 Oct 2019 16:29:11 +0000 Received: from BN6PR2201MB1700.namprd22.prod.outlook.com ([fe80::7cb4:5e4e:334c:a737]) by BN6PR2201MB1700.namprd22.prod.outlook.com ([fe80::7cb4:5e4e:334c:a737%7]) with mapi id 15.20.2387.028; Wed, 30 Oct 2019 16:29:11 +0000 From: Mike Bishop To: Qing An , quic , jri.ietf , mt CC: =?utf-8?B?5YiY5aSn6bmPKOm5j+aIkCk=?= Subject: RE: Fast Address Validation - about Thread-Topic: Fast Address Validation - about Thread-Index: AQHVjye9CowM5E5v+kqJ9Ajt0q5CdadzX6PA Date: Wed, 30 Oct 2019 16:29:11 +0000 Message-ID: References: <4974ed86-0fa9-435d-880f-80af637ef180.anqing.aq@alibaba-inc.com> In-Reply-To: <4974ed86-0fa9-435d-880f-80af637ef180.anqing.aq@alibaba-inc.com> 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: [2600:2b00:931f:a301:d929:1930:fc03:fdc0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b2f6713a-8f51-450a-8676-08d75d564bc8 x-ms-traffictypediagnostic: BN6PR2201MB1330: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(39830400003)(396003)(136003)(199004)(189003)(11346002)(6506007)(102836004)(7696005)(52536014)(53546011)(6116002)(790700001)(8936002)(186003)(86362001)(5660300002)(110136005)(25786009)(316002)(76176011)(99286004)(33656002)(7736002)(486006)(74316002)(446003)(46003)(476003)(14444005)(54896002)(66946007)(508600001)(606006)(71190400001)(55016002)(66476007)(256004)(6306002)(14454004)(66556008)(229853002)(236005)(81166006)(966005)(4326008)(9686003)(2906002)(81156014)(8676002)(64756008)(76116006)(6436002)(71200400001)(6246003)(66446008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR2201MB1330; H:BN6PR2201MB1700.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: LMSsBgdEOgm3OV56HhoyDSHEk5M4CerqDVy2bJsV/wZK51dG3UTxdwBwq29ndG4qYipjGOF4WZEWqIHPy/aJg9ZMLC3e0MZEvH4C6ldtDz6xHOdw+u4+MlnRHJdp4XIDju7xD8xDHllt569bI37n5zIP9RO87P/d/SB7rTahZIp5jR4WkfHQXqVv0TI72LopLrbeRmtc0K8O6ndvib8+YBeDEo/dQ6UfHDVRQ+J7d6lLEwGyIIxHdygFTf5/m7FBaH17f5hbpactIn2oeqHBjz4iHDF0AVFieL41+85sVjl2UmcCFQPACzEBVMhZe2ZDlybHiiAaZaSjbrTd3Mx7F2LXfxOuBR7oK2TOJJ84H8M5nAh23/o+pdDvbaqzrx//Ypgz5bNaYRtyv86ykDB0UY5X7OW6boCarH1XzVZckyBk1n3y3BNMcIhYAx8La0yMkxYddvEo9zOwDYKm9kJzFKzRQ10Te8Kw02gu1xlBoBg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR2201MB1700F72F3DC8F6C3CF79902CDA600BN6PR2201MB1700_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: b2f6713a-8f51-450a-8676-08d75d564bc8 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2019 16:29:11.4598 (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: C986Lt3IEaWqK3d+bNnucNzxJ8fu7OJxKVcY8XgQk0pnxrdl1/qiI4B4ozyexLgR2Xe9cN8jIcCMBtHXwvgFvA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1330 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, 30 Oct 2019 16:29:16 -0000 --_000_BN6PR2201MB1700F72F3DC8F6C3CF79902CDA600BN6PR2201MB1700_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGFkdmFudGFnZSBvZiB1c2luZyBSZXRyeSwgaG93ZXZlciwgaXMgdGhhdCB0aGUgc2VydmVy IGlzIGFibGUgdG8ga2VlcCBtaW5pbWFsIChpZiBhbnkpIHN0YXRlIGFib3V0IHRoZSBjbGllbnQu ICBFeGNoYW5naW5nIHRoZSB0b2tlbiBhdCB0aGUgSGFuZHNoYWtlIGVuY3J5cHRpb24gbGV2ZWwg bWVhbnMgdGhlIHNlcnZlciBpcyBhbHJlYWR5IGRvaW5nIHdvcmsgYW5kIG1haW50YWluaW5nIHN0 YXRlIGluIG9yZGVyIHRvIHByb2Nlc3MgdGhlIGhhbmRzaGFrZSwgd2hpY2ggaXMgZXhhY3RseSB3 aGF0IHRoZSBzZXJ2ZXIgaXMgdHJ5aW5nIHRvIGF2b2lkLg0KDQpGcm9tOiBRVUlDIDxxdWljLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBRaW5nIEFuDQpTZW50OiBXZWRuZXNkYXksIE9j dG9iZXIgMzAsIDIwMTkgOTo0MSBBTQ0KVG86IHF1aWMgPHF1aWNAaWV0Zi5vcmc+OyBqcmkuaWV0 ZiA8anJpLmlldGZAZ21haWwuY29tPjsgbXQgPG10QGxvd2VudHJvcHkubmV0Pg0KQ2M6IOWImOWk p+m5jyjpuY/miJApIDxtYXgubGRwQGFsaWJhYmEtaW5jLmNvbT4NClN1YmplY3Q6IEZhc3QgQWRk cmVzcyBWYWxpZGF0aW9uIC0gYWJvdXQNCg0KDQoNCkhpIE1hcnRpbiwgSmFuYSwNCg0KSSByZWFk IHRocm91Z2ggaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9y dC0yMy50eHQgYW5kIGhhdmUgYSBmZXcgY29tbWVudHMgYW5kIGlkZWFzIHRvIGRpc2N1c3MuDQoN CltRVUlDLVRyYW5zXSBkZWZpbmVzIGEgdG9rZW4gYmFzZWQgc2NoZW1lIHRvIGZhY2lsaXRhdGUg YWRkcmVzcyB2YWxpZGF0aW9uIG9mIGEgY2xpZW50LiBUaGUgdG9rZW4gTVVTVCBiZSBjb3ZlcmVk IGJ5IGludGVncml0eSBwcm90ZWN0aW9uIGFnYWluc3QgbW9kaWZpY2F0aW9uIG9yIGZhbHNpZmlj YXRpb24gYnkgY2xpZW50cy4gVGhlIHNlcnZlciByZW1lbWJlcnMgdGhlIHZhbHVlIGl0IHNlbmRz IHRvIGNsaWVudHMgYW5kIHZhbGlkYXRlcyB0aGUgdG9rZW4gc2VudCBiYWNrIGZyb20gYSBjbGll bnQuIEluIGl0cyBkZXNpZ24sIFJldHJ5IHBhY2tldCBpcyB1c2VkIHRvIGRlbGl2ZXIgdGhlIHRv a2VuIHRvIGEgY2xpZW50IHdoaWNoIGFkZHJlc3MgaGFzIG5vdCB5ZXQgYmVlbiB2YWxpZGF0ZWQu IEl0IHZvaWRzIHRoZSBmaXJzdCB0cmFuc21pc3Npb24gb2YgdGhlIEluaXRpYWwgcGFja2V0IHNl bnQgYnkgdGhlIGNsaWVudCwgYW5kIHRyaWdnZXJzIGEgc2Vjb25kIEluaXRpYWwgcGFja2V0IHRv IGJlIHNlbnQgd2l0aCB0aGUgdG9rZW4uIFRoZSBleGNoYW5nZSBvZiB0b2tlbiB3aWxsIGNhdXNl IGxvbmdlciBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgZGVsYXkgZm9yIGEgY2xpZW50Lg0KDQpU byBpbXByb3ZlIHRoZSBlZmZpY2llbmN5IG9mIGFkZHJlc3MgdmFsaWRhdGlvbiBkdXJpbmcgaGFu ZHNoYWtlLCBvbmUgaWRlYSBpcyB0aGF0IHRoZSBzYW1lIHRva2VuIGNhbiBiZSBleGNoYW5nZWQg dmlhIGEgZGlmZmVyZW50IGNvbnRhaW5lciBpLmUuIHRoZSBIYW5kc2hha2UgcGFja2V0LCB0aGF0 IGVsaW1pbmF0ZXMgdGhlIHVzZSBvZiBSZXRyeSBwYWNrZXQgZm9yIHRva2VuIGRlbGl2ZXJ5Lg0K DQpJIGFtIHdvcmtpbmcgb24gdGhlIGNvbXBsZXRlIGRyYWZ0IGFuZCB3aWxsIHN1Ym1pdCBpdCBi eSBGcmlkYXkuIEJlZm9yZSB0aGF0LCBob3BlIHRoaXMgY2FuIGJlIGRpc2N1c3NlZCBpbiBlbWFp bCBmaXJzdC4NCg0KQlIsDQpRaW5nIEFuDQo= --_000_BN6PR2201MB1700F72F3DC8F6C3CF79902CDA600BN6PR2201MB1700_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgSmhlbmdIZWkiOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWljcm9zb2Z0 IEpoZW5nSGVpIjt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJ cGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYWR2YW50YWdlIG9mIHVzaW5nIFJldHJ5LCBo b3dldmVyLCBpcyB0aGF0IHRoZSBzZXJ2ZXIgaXMgYWJsZSB0byBrZWVwIG1pbmltYWwgKGlmIGFu eSkgc3RhdGUgYWJvdXQgdGhlIGNsaWVudC4mbmJzcDsgRXhjaGFuZ2luZyB0aGUgdG9rZW4gYXQg dGhlIEhhbmRzaGFrZSBlbmNyeXB0aW9uIGxldmVsIG1lYW5zIHRoZSBzZXJ2ZXIgaXMgYWxyZWFk eSBkb2luZyB3b3JrIGFuZCBtYWludGFpbmluZyBzdGF0ZSBpbiBvcmRlcg0KIHRvIHByb2Nlc3Mg dGhlIGhhbmRzaGFrZSwgd2hpY2ggaXMgZXhhY3RseSB3aGF0IHRoZSBzZXJ2ZXIgaXMgdHJ5aW5n IHRvIGF2b2lkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyAmbHQ7 cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KUWluZyBBbjxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgMzAsIDIwMTkgOTo0MSBBTTxicj4N CjxiPlRvOjwvYj4gcXVpYyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IGpyaS5pZXRmICZsdDtqcmku aWV0ZkBnbWFpbC5jb20mZ3Q7OyBtdCAmbHQ7bXRAbG93ZW50cm9weS5uZXQmZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7l iJjlpKc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBKaGVu Z0hlaSZxdW90OyxzYW5zLXNlcmlmIj7puY88L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtNaWNyb3NvZnQgSmhlbmdIZWkmcXVvdDssc2Fucy1zZXJpZiI+6bmP5oiQPC9zcGFu PikgJmx0O21heC5sZHBAYWxpYmFiYS1pbmMuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBG YXN0IEFkZHJlc3MgVmFsaWRhdGlvbiAtIGFib3V0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+SGkmbmJzcDtNYXJ0aW4sJm5ic3A7SmFuYSwmbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5JJm5ic3A7cmVhZCZuYnNwO3Rocm91Z2gmbmJzcDs8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0 LTIzLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9y dC0yMy50eHQ8L2E+Jm5ic3A7YW5kJm5ic3A7aGF2ZSBhJm5ic3A7ZmV3Jm5ic3A7Y29tbWVudHMm bmJzcDthbmQmbmJzcDtpZGVhcyB0byBkaXNjdXNzLjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPltRVUlDLVRyYW5zXSBkZWZpbmVzJm5i c3A7YSZuYnNwO3Rva2VuJm5ic3A7YmFzZWQmbmJzcDtzY2hlbWUgdG8mbmJzcDtmYWNpbGl0YXRl Jm5ic3A7YWRkcmVzcyZuYnNwO3ZhbGlkYXRpb24mbmJzcDtvZiZuYnNwO2EmbmJzcDtjbGllbnQu Jm5ic3A7VGhlJm5ic3A7dG9rZW4mbmJzcDtNVVNUJm5ic3A7YmUmbmJzcDtjb3ZlcmVkJm5ic3A7 YnkgaW50ZWdyaXR5IHByb3RlY3Rpb24mbmJzcDthZ2FpbnN0Jm5ic3A7bW9kaWZpY2F0aW9uJm5i c3A7b3ImbmJzcDtmYWxzaWZpY2F0aW9uJm5ic3A7YnkmbmJzcDtjbGllbnRzLiZuYnNwO1RoZQ0K IHNlcnZlciZuYnNwO3JlbWVtYmVycyB0aGUmbmJzcDt2YWx1ZSBpdCBzZW5kcyB0byZuYnNwO2Ns aWVudHMmbmJzcDthbmQmbmJzcDt2YWxpZGF0ZXMmbmJzcDt0aGUmbmJzcDt0b2tlbiZuYnNwO3Nl bnQgYmFjayZuYnNwO2Zyb20mbmJzcDthJm5ic3A7Y2xpZW50LiZuYnNwO0luJm5ic3A7aXRzJm5i c3A7ZGVzaWduLCZuYnNwO1JldHJ5Jm5ic3A7cGFja2V0Jm5ic3A7aXMmbmJzcDt1c2VkJm5ic3A7 dG8mbmJzcDtkZWxpdmVyJm5ic3A7dGhlJm5ic3A7dG9rZW4mbmJzcDt0byBhJm5ic3A7Y2xpZW50 Jm5ic3A7d2hpY2gmbmJzcDthZGRyZXNzJm5ic3A7aGFzJm5ic3A7bm90Jm5ic3A7eWV0Jm5ic3A7 YmVlbiZuYnNwO3ZhbGlkYXRlZC4gSXQmbmJzcDt2b2lkcyZuYnNwO3RoZSZuYnNwO2ZpcnN0IHRy YW5zbWlzc2lvbiZuYnNwO29mIHRoZSZuYnNwO0luaXRpYWwgcGFja2V0DQogc2VudCBieSB0aGUg Y2xpZW50LCBhbmQmbmJzcDt0cmlnZ2VycyZuYnNwO2EmbmJzcDtzZWNvbmQgSW5pdGlhbCZuYnNw O3BhY2tldCZuYnNwO3RvJm5ic3A7YmUmbmJzcDtzZW50Jm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNw O3Rva2VuLiZuYnNwO1RoZSZuYnNwO2V4Y2hhbmdlJm5ic3A7b2YmbmJzcDt0b2tlbiZuYnNwO3dp bGwmbmJzcDtjYXVzZSBsb25nZXImbmJzcDtjb25uZWN0aW9uJm5ic3A7ZXN0YWJsaXNobWVudCZu YnNwO2RlbGF5Jm5ic3A7Zm9yJm5ic3A7YSZuYnNwO2NsaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztib3JkZXI6bm9uZSB3aW5k b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5UbyZuYnNwO2ltcHJvdmUmbmJzcDt0aGUmbmJzcDtl ZmZpY2llbmN5Jm5ic3A7b2YmbmJzcDthZGRyZXNzJm5ic3A7dmFsaWRhdGlvbiZuYnNwO2R1cmlu ZyZuYnNwO2hhbmRzaGFrZSwgb25lIGlkZWEgaXMgdGhhdCB0aGUmbmJzcDtzYW1lIHRva2VuIGNh biBiZSBleGNoYW5nZWQmbmJzcDt2aWEmbmJzcDthJm5ic3A7ZGlmZmVyZW50Jm5ic3A7Y29udGFp bmVyJm5ic3A7aS5lLiZuYnNwO3RoZSZuYnNwO0hhbmRzaGFrZSZuYnNwO3BhY2tldCwmbmJzcDt0 aGF0DQogZWxpbWluYXRlcyB0aGUgdXNlJm5ic3A7b2YmbmJzcDtSZXRyeSZuYnNwO3BhY2tldCBm b3ImbmJzcDt0b2tlbiBkZWxpdmVyeS4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjaztib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGlu Ij5JIGFtIHdvcmtpbmcgb24gdGhlIGNvbXBsZXRlIGRyYWZ0IGFuZCB3aWxsIHN1Ym1pdCBpdCBi eSBGcmlkYXkuIEJlZm9yZSB0aGF0LCBoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5vcGUNCiB0aGlzIGNhbiBiZSBkaXNjdXNzZWQgaW4gZW1haWwgZmlyc3QuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5C Uiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UWluZyBBbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR2201MB1700F72F3DC8F6C3CF79902CDA600BN6PR2201MB1700_-- From nobody Wed Oct 30 14:01:27 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80327120881 for ; Wed, 30 Oct 2019 14:01:25 -0700 (PDT) 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 S7cXfN343n5e for ; Wed, 30 Oct 2019 14:01:23 -0700 (PDT) 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 339A912086F for ; Wed, 30 Oct 2019 14:01:23 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id c4so4208440lja.11 for ; Wed, 30 Oct 2019 14:01:23 -0700 (PDT) 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=C39PSocb0qWiPZPJ1FCvQ6I6YqcEVVHEcohDAjVg4WU=; b=CM/zPnyc4sfv89Np/He5lMFPKzI0GWxabQbqpC4pahhpklVpaiOO5ab/vUt4MRgb5U iTJXt7AmDwtr4kOkpixmPAFBFla1mSR812nHLNAZGwviqxXjHsn8/2NK6cc7rIetEDdt z9HeJQYiJG+OX1u54heFvWHIAHBMg+F9Koj1kg0Fq7zTatTLDgUtfFqIpKUyoio+T0QH UeVsNRNgCn1BCPWXR/qHmp6eRJS3RoOE2w3jRPTqercORpNIDLyqHkI+PSFRP3DoXa43 EZPDJfwbgGAiYwp8612dRXzp94fIhT+rKZc8GnoGHRK564Tgvkmloj22ueqw4CAsotbn aUbg== 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=C39PSocb0qWiPZPJ1FCvQ6I6YqcEVVHEcohDAjVg4WU=; b=XkybbXG8Re7oq1KcOzJJ+rLKuQWZIV6nyo+0DHVTXwtXmBYg6Wm1cAVPFAqV8R27F2 SC4k+abshovyWgRT4uPEWF2Lfu7pRKUa+QiryaomQGJ9zhrKYh0jZA/s1evEG8rlvIQt wKUOJZovsXsZ4uW09lEnzLQJwNB+C0opF3tGaS8AJdMW1Yd4wDX862sIhpQj8ANM7EJs Et500Vy/xl7SX4jKj23SExQ6IulguVe1vDkE22GL3+AbS3k1QkSrXIEGcHdgco4JEslI sg4CPT9h4arYijBiWMq66pUV+KnjHg6e0kMDF9xV2biH0rggOOUg44KjgNacJOo5448M v55A== X-Gm-Message-State: APjAAAV4h+yTbdln2y7LE+iTCwDnqxWujODsnDq8wqvo+S9IJSmTYzIC Kt5WuzUuSZ/R6EUa9V54qKYP2P130W37LB5f7qevnw== X-Google-Smtp-Source: APXvYqxksz58Mhp506bFSgWFdz7TtmHJahpYnwmwG7neI86vRBxKDAZNMyYxYL+6Zey5PJouom/zmU8/DvzSDC162aU= X-Received: by 2002:a2e:3e18:: with SMTP id l24mr1250720lja.48.1572469281426; Wed, 30 Oct 2019 14:01:21 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> In-Reply-To: <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> From: Eric Rescorla Date: Wed, 30 Oct 2019 14:00:44 -0700 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Martin Thomson Cc: Martin Duke , Jana Iyengar , Mike Bishop , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000f0a21105962708ad" 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, 30 Oct 2019 21:01:26 -0000 --000000000000f0a21105962708ad Content-Type: text/plain; charset="UTF-8" On Tue, Oct 29, 2019 at 10:02 PM Martin Thomson wrote: > On Wed, Oct 30, 2019, at 10:58, Eric Rescorla wrote: > > On Mon, Oct 28, 2019 at 8:32 PM Martin Thomson > wrote: > > > On Tue, Oct 29, 2019, at 10:34, Eric Rescorla wrote: > > > > On Sun, Oct 27, 2019 at 7:47 PM Martin Thomson > wrote: > > > > > On Mon, Oct 28, 2019, at 10:01, Eric Rescorla wrote: > > > > > > I think we're clearly going to need to spend some time on this. > I don't > > > > > > think the spec is satisfactory as-is: we should be designing a > > > > > > transport that works for all use cases, not just H3. That said, > I also > > > > > > don't agree that we need an additional explicit signal. We have > one, > > > > > > it's called "ACK". We should figure out how to make that work. > > > > > > > > > > I think that we've established that ACK doesn't work without > something to push it along. > > > > > > > > No, I don't agree with that assessment. > > > > > > Well, I'd like some proof. I shared what I believe to be proof > earlier. Happy to walk through it again though. > > > > Yeah, I think that would help. I've gotten a little lost on the list, > > so maybe you can re-point it out to me. > > Let me try restating it more thoroughly: > > The problem that Marten identified is a deadlock because one side discards > keys at a time that might be significantly in advance of the other. If the > endpoint that retains keys still hasn't received acknowledgments, it enters > a deadlock state if it exhausts the congestion window by sending Handshake > packets. > I'm going to stop here, because it seems that you're assuming we don't just keep the keys indefinitely. How does that lead to deadlock? -Ekr > --000000000000f0a21105962708ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 29, 2019 at 10:02 PM Mart= in Thomson <mt@lowentropy.net&g= t; wrote:
On Wed= , Oct 30, 2019, at 10:58, Eric Rescorla wrote:
> On Mon, Oct 28, 2019 at 8:32 PM Martin Thomson <mt@lowentropy.net> wrote:
> > On Tue, Oct 29, 2019, at 10:34, Eric Rescorla wrote:
> >=C2=A0 > On Sun, Oct 27, 2019 at 7:47 PM Martin Thomson <mt@lowentropy.net&g= t; wrote:
> >=C2=A0 > > On Mon, Oct 28, 2019, at 10:01, Eric Rescorla wro= te:
> >=C2=A0 > > > I think we're clearly going to need to s= pend some time on this. I don't
> >=C2=A0 > > > think the spec is satisfactory as-is: we sho= uld be designing a
> >=C2=A0 > > > transport that works for all use cases, not = just H3. That said, I also
> >=C2=A0 > > > don't agree that we need an additional e= xplicit signal. We have one,
> >=C2=A0 > > > it's called "ACK". We should f= igure out how to make that work.
> >=C2=A0 > >
> >=C2=A0 > > I think that we've established that ACK doesn= 't work without something to push it along.
> >=C2=A0 >
> >=C2=A0 > No, I don't agree with that assessment.
> >
> >=C2=A0 Well, I'd like some proof. I shared what I believe to b= e proof earlier. Happy to walk through it again though.
>
> Yeah, I think that would help. I've gotten a little lost on the li= st,
> so maybe you can re-point it out to me.

Let me try restating it more thoroughly:

The problem that Marten identified is a deadlock because one side discards = keys at a time that might be significantly in advance of the other.=C2=A0 I= f the endpoint that retains keys still hasn't received acknowledgments,= it enters a deadlock state if it exhausts the congestion window by sending= Handshake packets.

I'm going to st= op here, because it seems that you're assuming we don't just keep t= he keys indefinitely. How does that lead to deadlock?

-Ekr




--000000000000f0a21105962708ad-- From nobody Wed Oct 30 14:07:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F4F120103 for ; Wed, 30 Oct 2019 14:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 hemLcO-jEjRd for ; Wed, 30 Oct 2019 14:06:59 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 0419E12008C for ; Wed, 30 Oct 2019 14:06:59 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id y7so2995666edo.12 for ; Wed, 30 Oct 2019 14:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=NB8JwAs4S4HjSrH3hV0B8HV+3n3OY4FPsLe7EQwc6eU=; b=Obb+lmDmZfjAZiRmy5q4LA4t/BU7jzZwXXdhyMxNRYnyYg29d5Q3GeTHxUdp/aBsSb dUhoutQLRPqWHMZgnNS4bjyYEx0g6HH5Ti/4Nga6lt9CakYv0wjfyDpDn3bWyCh3DIOk Qkchyo8GKzK7lyse/nQvxSxU8nuV0l/USD+ygbhLGDMLYt8tCm8g2Ng78GotZVVqxGZk mFOd+ugrfaUTdgxHvuW+uDGGkW5VfamAhKrHtT/lbq264IyW7uZXGRcPI0+c5/k3VBXP hV3Eh7WRHVqUJIIspZ8qkE6ZVJtDxc69dHaU4usi9mIKupP5kGGyJEJ9pGwsidZ51NQt SOvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=NB8JwAs4S4HjSrH3hV0B8HV+3n3OY4FPsLe7EQwc6eU=; b=shlnqRsUHvadBxemyCrznCF+B+svuXRr6b2iOlAc7XvFTM52LGlTYe2E9C/pSb56kp qRqi7FXmCsgsOEtsvz57FDLhHQAEG3X3jkTT6/b3Luez/kR3ax8hgknc6tR/nGnJPn77 qcnAldrBoSjIlcVSNDYvvV2J4m/yiJzOwp9q5zFT1+5AvFr3D0HB6Gl8s7CJ//lgqO/N RJh3k7ML4w+XYvQziJWs+N5iab+nbkdC9NoqYyGRZDxjXOtjEb/DPb26y54QlTrdi/dH krESbAqiLtrIai3D6G6xzAPHfUlZP9t/khUS1vRq3EW2gYzFuLjN9Uj4TcuAtCBY/jAb biqQ== X-Gm-Message-State: APjAAAU8jtat2cKk6ih/ENEO39Kym/cdoMAghXlcts2IcXWAitNyapJj 5xzbuWvKGe+dcrqbGJOIz74hs3WVUtj/TyUCyNE= X-Google-Smtp-Source: APXvYqxk6/UoFGY3hAIK6sxbI6pXfchHoiAnQflqfYVXCfC/ZI2gN6sp0snLHTzk0pVml4r8nO96f6hEzeQJv3FE8HI= X-Received: by 2002:a17:906:4a4d:: with SMTP id a13mr300682ejv.65.1572469617591; Wed, 30 Oct 2019 14:06:57 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 30 Oct 2019 14:06:56 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 30 Oct 2019 14:06:56 -0700 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Eric Rescorla , Martin Thomson Cc: David Schinazi , Jana Iyengar , Mike Bishop , Martin Duke , IETF QUIC WG , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000fa0bdc0596271cbc" 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, 30 Oct 2019 21:07:01 -0000 --000000000000fa0bdc0596271cbc Content-Type: text/plain; charset="UTF-8" I'm going to stop here, because it seems that you're assuming we don't just keep the keys indefinitely. How does that lead to deadlock? The problem is that having keys indefinitely leads to various problems. If the goal is to decide when the handshake is complete at both ends in finite time with high probability, then it appears that an explicit signal is required because you cannot rely on random (organic) 1-RTT traffic to drive this process. -Ekr > --000000000000fa0bdc0596271cbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
<= span>
I'm goi= ng to stop here, because it seems that you're assuming we don't jus= t keep the keys indefinitely. How does that lead to deadlock?


The problem is that= having keys indefinitely leads to various problems. If the goal is to deci= de when the handshake is complete at both ends in finite time with high pro= bability, then it appears that an explicit signal is required because you c= annot rely on random (organic) 1-RTT traffic to drive this process.

<= div>


-Ekr





<= /html> --000000000000fa0bdc0596271cbc-- From nobody Wed Oct 30 14:20:13 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC7D120B1B for ; Wed, 30 Oct 2019 14:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBHiR8nG79S7 for ; Wed, 30 Oct 2019 14:20:00 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 512D1120B02 for ; Wed, 30 Oct 2019 14:20:00 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id u16so2746010lfq.3 for ; Wed, 30 Oct 2019 14:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zl79tnl3Mm7hN9HRvVX5Dq60Mhx63+vlAwSYBj7y/k8=; b=j8UOaZkGGCDIRsIlunPmNtdhzH3daxvdvaphJSu6aMahCg/0ucovHoS7BTka2jQi0l It+reGDjstr1JnCqMxHaiHWm4KiVCH/FML/qmnhll6/pC7EiOlXicD0zv1+G4HC46Xy1 IxSZMaYyoJ78V4v0zbaw2+c6SXt5EauEVTS1rujT1fhphx3YfcMI5Hxzb/TakgMo7/jL /HY6DzrIrgTmocRJ9S3B7A313RDvmxDKagd3jUKTHOoRn0uRjYUqmgEr5FdOQlR17nV+ He/C0Nw6YUxFgaA9dZxhxyfGdrHJDFK53kZoJF5j1gFIKLAsS9g94H31PxY57MxPrZIV FCjw== 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=Zl79tnl3Mm7hN9HRvVX5Dq60Mhx63+vlAwSYBj7y/k8=; b=Y80q9AGgync1Oacn6QAtu9n9ypQTZR36dFCHuwP02APWSADvkhR0y8J6irx6gxs0Ld zvxkOHDqbqgZTFgb2/glgjYqQ8LrLJZkw6POb1lNhiVfhRIbkSD4n03FqJwsw2VjITzT 5iByfb91CKVtvA36JsJMjRGrSisGkSWcmZSopUVKZPLQHRFZ4/RDPZAwVbVWiwUisdLJ nSSLwUpUC7VNWCwB9UK6UbXYGCmWtMK6HXxotgfzATveP8eotJw/YkyQ+T3N8lO0fOxz mQsUxVk4TcvzE3KDWrGuFSA6WO96p8HFTajV3LkzHqn/mSVeLLyFGLk+70sWjimtJc3m gwCQ== X-Gm-Message-State: APjAAAWDS/Qx7ASvx5PTJcgUcTth6OE+ZSpEjDMRXVp5hacKwC7Jemm1 IlJ9lz1Z8H5v39K1Ve6L03GY33osyPlr0zOPeHQ= X-Google-Smtp-Source: APXvYqzs4A8BFE2+A3AkngGgv1Lf7WS8XPP4QU9F7/Dd3+6zL/D2y9X0EeL5avMiSQ1JZtU8CTG+cqRS/VLgFoF/plg= X-Received: by 2002:a19:e058:: with SMTP id g24mr235294lfj.8.1572470398364; Wed, 30 Oct 2019 14:19:58 -0700 (PDT) MIME-Version: 1.0 References: <36b10565-1c64-4a42-a1c2-648e4c8eee37@www.fastmail.com> In-Reply-To: <36b10565-1c64-4a42-a1c2-648e4c8eee37@www.fastmail.com> From: David Schinazi Date: Wed, 30 Oct 2019 14:19:46 -0700 Message-ID: Subject: Re: Making QUIC less constraining for innovation To: Martin Thomson Cc: QUIC Content-Type: multipart/alternative; boundary="00000000000083afc60596274b97" 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, 30 Oct 2019 21:20:10 -0000 --00000000000083afc60596274b97 Content-Type: text/plain; charset="UTF-8" Thanks for writing this up! My main pushback against Provisional Registrations was that I expected them to expire after some number of days, and seeing that this is not the case in the PR explains things. The PR sounds like a reasonable approach to me, I sent some more specific comments there. I'm supportive of trying out First Come First Served for provisional entries. We can change the rules later if we see the space fill up too quickly. On Tue, Oct 29, 2019 at 11:50 PM Martin Thomson wrote: > I've written up this proposal here: > > https://github.com/quicwg/base-drafts/pull/3170 > > Thanks to everyone who provided input here. I think that I got all of it, > but feel free to pitch in on the PR with notes about errors and omissions. > > The only bit of this that I'm hesitant over is the use of Expert Review > for the provisional entries. I don't know if we could instead use > First-Come, First-Served and rely on IANA to watch for spamming. It would > probably be faster without an expert review step involved. > > On Thu, Oct 24, 2019, at 14:26, Martin Thomson wrote: > > Issue 3020 (https://github.com/quicwg/base-drafts/issues/3020) raises > > the question of IANA registration policies in the core drafts. The > > thesis is that the constraints on registrations pushes people into a > > small space of available numbers (in that specific case the space is > > 256 values) or has registration requirements that are too onerous. > > > > We aim to address this in most places in QUIC and h3 with varints, > > which all have a similar registration scheme. I think that David's > > intent with #3020 was to push more of our code to use varints. But > > we're nothing if not consistent when it comes to these things and after > > lengthy discussion in Cupertino the group decided not to use varints > > for transport parameters. > > > > Instead, we want to revise the registration policies to better allow > > implementations to experiment with new features (which is what I think > > David intended by the use of the word "innovation"). For varints, we > > divide the space into three partitions: > > > > 0-63 = Standards Action > > 64-16383 = Specification Required > > 16384+ = Private Use > > > > David's PR #3109 (https://github.com/quicwg/base-drafts/pull/3109) > > proposes the same split for transport parameters. That greatly > > increases the size of the Private Use space. The Private Use section > > is still a lot smaller than with varints, but the cut points are the > > same and the belief is that ~2^16 values is plenty of room to play with. > > > > The main problem with all of these policies is described in RFC 6648, > > namely that a codepoint from Private Use space can get wide adoption. > > RFC 6648 basically concludes that these can be impossible to move to a > > registered portion of the codepoint space. Furthermore, RFC 8126 says > > that IANA doesn't register these codepoints and so no mechanism exists > > to prevent collisions. That's a shame, because that's what registries > > are for. > > > > --- > > I propose that we instead remove Private Use space from specifications > > and instead adopt a Specification Required policy for all codepoints > > except the first 64 values of a varint value (we can keep that as > > Standards Action). > > > > To allow for experimentation and proprietary extensions, add the > > ability to provisionally register any codepoint. Provisional > > registrations are registrations can omit values that would be required > > for a permanent registration, include an expiry date, and operate on > > First-Come, First-Served basis. > > > > This is intentionally lightweight so that anyone can initiate > > registration, even without complete information. A Designated Expert > > will be assigned to ensure that the registries don't end up crammed > > with junk and to discourage use of codepoints with small encodings, > > large blocks of codepoints, or codepoints that are likely to be used by > > future standardization (those that are adjacent the first contiguous > > block of allocated values, which we might want to use later). I > > emphasize discourage intentionally, because this can't be a hard rule - > > this is why we use a human for this job and not a machine. > > > > To recognize that people will inevitably use values before they even > > provisionally register them, we should encourage people to select from > > the space at random. Random selection from a larger space greatly > > reduces the chances of collision. For varints, people will be > > encouraged to choose values that have the longest encoding tolerable > > for their use case. In particular, extensions that are fully > > proprietary will be encouraged to use values that encode to 4 or 8 > > bytes. I recognize that this might not avoid people having inflated > > notions of the value of their extension. And maybe it's not worth > > protecting the 2 byte space on the basis that we might never run out of > > the 16320 values available. Either way, I think that it's worth > > providing some text to help the expert in case this protocol gets > > unexpectedly busy. > > > > Registrants are specify the codepoint they want when registering, > > rather than have IANA make an allocation on request. For standards > > that want to use codepoints that are adjacent the first set of values, > > we might still use TBD in specifications to avoid having the same value > > specified in multiple specifications. The TLS working group had the > > same codepoint in three different drafts last year, which wasn't great. > > > > Provisional registrations can be removed or refreshed after a year > > (period negotiable) after consultation with the expert, who is > > encouraged to consult with the broader community. Experts would be > > advised to refresh registrations unless there is evidence that the > > value is no longer in use and there is a need to free up space for new > > registrations. > > > > The motivation behind this proposal is to recognize that the overriding > > goal of a protocol registry is to avoid the interoperability failures > > that arise from codepoint collisions. In particular, registries are > > not an access control mechanism. > > > > > > --00000000000083afc60596274b97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for writing this up! My main pushback against Provi= sional Registrations was that I expected them to expire after some number o= f days, and seeing that this is not the case in the PR explains things.
The PR sounds like a reasonable=C2=A0approach to me, I sent= some more specific comments there.

I'm suppor= tive of trying out First Come First Served for provisional entries. We can = change the rules later if we see the space fill up too quickly.
=
On Tue= , Oct 29, 2019 at 11:50 PM Martin Thomson <mt@lowentropy.net> wrote:
I've written up this proposal here:

https://github.com/quicwg/base-drafts/pull/3170
Thanks to everyone who provided input here.=C2=A0 I think that I got all of= it, but feel free to pitch in on the PR with notes about errors and omissi= ons.

The only bit of this that I'm hesitant over is the use of Expert Review= for the provisional entries.=C2=A0 I don't know if we could instead us= e First-Come, First-Served and rely on IANA to watch for spamming.=C2=A0 It= would probably be faster without an expert review step involved.

On Thu, Oct 24, 2019, at 14:26, Martin Thomson wrote:
> Issue 3020 (https://github.com/quicwg/base-dra= fts/issues/3020) raises
> the question of IANA registration policies in the core drafts.=C2=A0 T= he
> thesis is that the constraints on registrations pushes people into a <= br> > small space of available numbers (in that specific case the space is <= br> > 256 values) or has registration requirements that are too onerous.
>
> We aim to address this in most places in QUIC and h3 with varints, > which all have a similar registration scheme.=C2=A0 I think that David= 's
> intent with #3020 was to push more of our code to use varints.=C2=A0 B= ut
> we're nothing if not consistent when it comes to these things and = after
> lengthy discussion in Cupertino the group decided not to use varints <= br> > for transport parameters.
>
> Instead, we want to revise the registration policies to better allow <= br> > implementations to experiment with new features (which is what I think=
> David intended by the use of the word "innovation").=C2=A0 F= or varints, we
> divide the space into three partitions:
>
>=C2=A0 =C2=A00-63 =3D Standards Action
>=C2=A0 =C2=A064-16383 =3D Specification Required
>=C2=A0 =C2=A016384+ =3D Private Use
>
> David's PR #3109 (https://github.com/quicwg/= base-drafts/pull/3109)
> proposes the same split for transport parameters.=C2=A0 That greatly <= br> > increases the size of the Private Use space.=C2=A0 The Private Use sec= tion
> is still a lot smaller than with varints, but the cut points are the <= br> > same and the belief is that ~2^16 values is plenty of room to play wit= h.
>
> The main problem with all of these policies is described in RFC 6648, =
> namely that a codepoint from Private Use space can get wide adoption.= =C2=A0
> RFC 6648 basically concludes that these can be impossible to move to a=
> registered portion of the codepoint space.=C2=A0 Furthermore, RFC 8126= says
> that IANA doesn't register these codepoints and so no mechanism ex= ists
> to prevent collisions.=C2=A0 That's a shame, because that's wh= at registries
> are for.
>
> ---
> I propose that we instead remove Private Use space from specifications=
> and instead adopt a Specification Required policy for all codepoints <= br> > except the first 64 values of a varint value (we can keep that as
> Standards Action).
>
> To allow for experimentation and proprietary extensions, add the
> ability to provisionally register any codepoint.=C2=A0 Provisional > registrations are registrations can omit values that would be required=
> for a permanent registration, include an expiry date, and operate on <= br> > First-Come, First-Served basis.=C2=A0
>
> This is intentionally lightweight so that anyone can initiate
> registration, even without complete information.=C2=A0 A Designated Ex= pert
> will be assigned to ensure that the registries don't end up cramme= d
> with junk and to discourage use of codepoints with small encodings, > large blocks of codepoints, or codepoints that are likely to be used b= y
> future standardization (those that are adjacent the first contiguous <= br> > block of allocated values, which we might want to use later).=C2=A0 I =
> emphasize discourage intentionally, because this can't be a hard r= ule -
> this is why we use a human for this job and not a machine.
>
> To recognize that people will inevitably use values before they even <= br> > provisionally register them, we should encourage people to select from=
> the space at random.=C2=A0 Random selection from a larger space greatl= y
> reduces the chances of collision.=C2=A0 For varints, people will be > encouraged to choose values that have the longest encoding tolerable <= br> > for their use case.=C2=A0 In particular, extensions that are fully > proprietary will be encouraged to use values that encode to 4 or 8 > bytes.=C2=A0 I recognize that this might not avoid people having infla= ted
> notions of the value of their extension.=C2=A0 And maybe it's not = worth
> protecting the 2 byte space on the basis that we might never run out o= f
> the 16320 values available.=C2=A0 Either way, I think that it's wo= rth
> providing some text to help the expert in case this protocol gets
> unexpectedly busy.
>
> Registrants are specify the codepoint they want when registering,
> rather than have IANA make an allocation on request.=C2=A0 For standar= ds
> that want to use codepoints that are adjacent the first set of values,=
> we might still use TBD in specifications to avoid having the same valu= e
> specified in multiple specifications.=C2=A0 The TLS working group had = the
> same codepoint in three different drafts last year, which wasn't g= reat.
>
> Provisional registrations can be removed or refreshed after a year > (period negotiable) after consultation with the expert, who is
> encouraged to consult with the broader community. Experts would be > advised to refresh registrations unless there is evidence that the > value is no longer in use and there is a need to free up space for new=
> registrations.
>
> The motivation behind this proposal is to recognize that the overridin= g
> goal of a protocol registry is to avoid the interoperability failures =
> that arise from codepoint collisions.=C2=A0 In particular, registries = are
> not an access control mechanism.
>
>

--00000000000083afc60596274b97-- From nobody Wed Oct 30 14:22:02 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C53120A4D for ; Wed, 30 Oct 2019 14:22:00 -0700 (PDT) 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 0mfnD3oMmipg for ; Wed, 30 Oct 2019 14:21:58 -0700 (PDT) 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 F3E57120A8E for ; Wed, 30 Oct 2019 14:21:57 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id 195so2738846lfj.6 for ; Wed, 30 Oct 2019 14:21:57 -0700 (PDT) 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=vRYfa/JW4XX/f3Eoy2K7a2SEhWh9UcOnKZUR9nxjolk=; b=VfESEk4V/yubzZqhqNHNMfCk0zuvcmLHSng6hvLOYiz/UVFdIBDhsHjdCxX5D2SVd8 aAiUPA4PJF67KAIToixApizI0ivP7diHaZ4wMdcBzCwyGmU5rfH355pW0EH81Tw5TDTV 6Rc+lGm+GHW/nYg9jHmSmusaifPvvThJNyvRRbPey/Jcw7TMfZEVi8jW0/O8+SeH3PHk JFZKiiHkbOJOnFBwIXvOLuaU+JsgLaa7xx2t3uoTIxy8cAfS3s3RyqNDG8dpN4JGA03W D3WLjeRGmQhr4UdLQb4hK+OkOywQothR9PhOgjsq9OEe7Vn1bV08V9WbBGuLnrw8Qp9V 3HyA== 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=vRYfa/JW4XX/f3Eoy2K7a2SEhWh9UcOnKZUR9nxjolk=; b=oroaBcSGOyMwswnFtinRTJq4gsWlDTrrLH5S95AqsZrJrJJKcnC3Fzvd5YFaxUeZx2 d94UqkJc0fWzjjSMrO4p3SvRjtiKPHG5gMeJYj2z0GsT68eQc3+xkMyHEsDZIy76Qlwy MUJCgb6R/vN71wTdPLiVFTcc21ODEt4maECUJ4Z29N0vg/SLXVgqAPucDTgkUmSFchoP QCLl5EMk3y1/v+1QuvQUjHAbBy86QfsXPGLG1wgI72FDA2Y+KDh4KoHAFJxXdyMCq1hp LfcgcHk0sCvIFT8WKPGczDQ44mvuG/xFnov1RU3VGTddtnbXPisW46AozMqpYgo4eBix NNBw== X-Gm-Message-State: APjAAAWLsoo/l+OZBpbA/B2JXKA/t7O8KOK6pYLkCtBFO+itsJCJQ2dT QuomabsNDHhG4SQ/wddCKPUL+Dsp0n6jS/+ZX07TGg== X-Google-Smtp-Source: APXvYqxbLMRsUqqNU5Lls0RbsPAfoVd8hCXGLjsGM68vAg4tQIg41fs+2gNwmdxdnk5C5hY8YvL/+Zw4Rorgzi2rGFo= X-Received: by 2002:a19:f107:: with SMTP id p7mr195169lfh.91.1572470516313; Wed, 30 Oct 2019 14:21:56 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Wed, 30 Oct 2019 14:21:19 -0700 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Martin Thomson , David Schinazi , Jana Iyengar , Mike Bishop , Martin Duke , IETF QUIC WG , Kazuho Oku Content-Type: multipart/alternative; boundary="0000000000008b862205962752c0" 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, 30 Oct 2019 21:22:01 -0000 --0000000000008b862205962752c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 30, 2019 at 2:06 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > I'm going to stop here, because it seems that you're assuming we don't > just keep the keys indefinitely. How does that lead to deadlock? > > > The problem is that having keys indefinitely leads to various problems. > I've heard that asserted but I'm not so sure. > If the goal is to decide when the handshake is complete at both ends in > finite time with high probability, then it appears that an explicit signa= l > is required because you cannot rely on random (organic) 1-RTT traffic to > drive this process. > Well, it's not clear to me that one needs to know this, actually. I agree we've used this as a proxy for various things, but it's not actually clear to me that we need to, so we should re-examine those cases to see what the real preconditions are. -Ekr > > -Ekr > > > > >> > --0000000000008b862205962752c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 30, 2019 at 2:06 PM Mikke= l Fahn=C3=B8e J=C3=B8rgensen <mikk= elfj@gmail.com> wrote:

I'm going to stop here, because it seems th= at you're assuming we don't just keep the keys indefinitely. How do= es that lead to deadlock?
=


The problem is that having keys indefinitely leads to v= arious problems.

I've heard that asserted bu= t I'm not so sure.
=C2=A0

If the go= al is to decide when the handshake is complete at both ends in finite time = with high probability, then it appears that an explicit signal is required = because you cannot rely on random (organic) 1-RTT traffic to drive this pro= cess.

Well, it's not clear to me that one ne= eds to know this, actually. I agree we've used this as a proxy for vari= ous things, but it's not actually clear to me that we need to, so we sh= ould re-examine those cases to see what the real preconditions are.

-Ekr




-Ekr





--0000000000008b862205962752c0-- From nobody Wed Oct 30 14:33:22 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D368D1208F8 for ; Wed, 30 Oct 2019 14:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 n7Qey3O1Pu3I for ; Wed, 30 Oct 2019 14:33:20 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 135DC1200D6 for ; Wed, 30 Oct 2019 14:33:20 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id w3so733004edt.2 for ; Wed, 30 Oct 2019 14:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=tTmqvx2VE60E3Fn35HCGp0h9+BWTST49AXXu+bXfOvQ=; b=YKJ2L7bd3QjuRxcdvh2w5k22YBPTrzCqmk5+R2mIp5btT6Wp2VvsVvYfJdrMLz0QdQ A8N/onKYMAYPUoGoXY2AYI1HZHyCR104mmBl5sq/ohcGj0DKb14jUe6YxrWlb7bjpC6h RDgHB6BVGVxTxCXfCb82ICsdUME1zIz2evdyMsS1xssljaEbD9BV6xssWemXkNXA46lq /uV1fBeJpx9JqViyhG4Ib5qpFAM/KE7wfrBL/Phrjy6Hj+6lUp8wyN2rNJltFX523dnu B8ThEPO9DbUsTEJNwynniTQ9EngLzbjCSNiLwvbOZ7UGE6R3WXs09nIWFxCK4dZk3mrB qrZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=tTmqvx2VE60E3Fn35HCGp0h9+BWTST49AXXu+bXfOvQ=; b=mYQsnhsfodX6vEccZs597CD/leg0p80ZKqSthcNsYxryv0DL5TQ2S8DEij5rGLYjJs goghM2vTrewGmDVhtcBcoo4nfFhEQs6lB4+3T+rKJ3KfZKZZUFZ7hwkXwtlFuLQMDhNq 2L65ro2BdaloT3vgFjdNsjxZsiAAaOyQiiFVViu4F0oN8j5RLmPgfiebzeqE4wE0pCad B1egosrCTu/egqrnXLhU05/jY3TouuUAUgPjQViGl/fF2bxMf/T2I10bmAGaxcJxVpgh 1LaRsv/pA0EiMyLYW18TAtEiYvIMix/bvNS8oFJgQoJswfgHK8ud4AQ24A0mXAgYJizW oYzw== X-Gm-Message-State: APjAAAXr/NUvFRSPmDNoVED7SyAv4eWfvo9cCeUIvBoWOLmrqfvZMtmX EpqwDGPxWxI+npyilTsqBfuK93xAsEgcgyOAv6o= X-Google-Smtp-Source: APXvYqyk1mYFj1Y8V9WrafBRU5pgl0vC2AJS9gX0KotAWkzJ4yLZivxwFQrxWXUjMDLwPHb6HHLkYCEOizkiRg+rLXU= X-Received: by 2002:a17:906:a981:: with SMTP id jr1mr372934ejb.255.1572471198631; Wed, 30 Oct 2019 14:33:18 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 30 Oct 2019 14:33:17 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 30 Oct 2019 14:33:17 -0700 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: Eric Rescorla Cc: Jana Iyengar , Mike Bishop , Martin Thomson , IETF QUIC WG , David Schinazi , Martin Duke , Kazuho Oku Content-Type: multipart/alternative; boundary="00000000000036cc830596277bfa" 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, 30 Oct 2019 21:33:22 -0000 --00000000000036cc830596277bfa Content-Type: text/plain; charset="UTF-8" If the goal is to decide when the handshake is complete at both ends in > finite time with high probability, then it appears that an explicit signal > is required because you cannot rely on random (organic) 1-RTT traffic to > drive this process. > Well, it's not clear to me that one needs to know this, actually. I agree we've used this as a proxy for various things, but it's not actually clear to me that we need to, so we should re-examine those cases to see what the real preconditions are. For one thing, I would be sad if an optimised implementation needs to handle multiple packet number spaces. That complicates implementations because you need to think performance through all layers. Of course you can just suck it up an deal with it. Likewise, you can probably find a way around path migration. By compared to sending a single 1-byte HANDSHAKE_DONE frame, why would you do that? To marginally simplify the handshake? --00000000000036cc830596277bfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

If the goal is to decide when the= handshake is complete at both ends in finite time with high probability, t= hen it appears that an explicit signal is required because you cannot rely = on random (organic) 1-RTT traffic to drive this process.

Well, it's not clear to me that one needs to know this, actual= ly. I agree we've used this as a proxy for various things, but it's= not actually clear to me that we need to, so we should re-examine those ca= ses to see what the real preconditions are.

For one thing, I would be sad if an optimised im= plementation needs to handle multiple packet number spaces. That complicate= s implementations because you need to think performance through all layers.= Of course you can just suck it up an deal with it. Likewise, you can proba= bly find a way around path migration.

By compared to sending a single= 1-byte HANDSHAKE_DONE frame, why would you do that? To marginally simplify= the handshake?

--00000000000036cc830596277bfa-- From nobody Wed Oct 30 14:49:29 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AF212011C for ; Wed, 30 Oct 2019 14:49:27 -0700 (PDT) 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 zr9Qww2M8rfZ for ; Wed, 30 Oct 2019 14:49:25 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8F61200D6 for ; Wed, 30 Oct 2019 14:49:25 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id q64so4322233ljb.12 for ; Wed, 30 Oct 2019 14:49:25 -0700 (PDT) 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=X4KlA0GNxWSk7ijvRjhrPNPuIGsaYqZoT0UXFQyZRIA=; b=IggEzGBBuNYMyYdXmZgwR4SnHWWsG0r5XIyrHzWiUOaQzNeQ9ql+/UO7qPg1g2H6/F 3E2H8WX8VW72XXIL4xNpD/dubnjsYhAKfFKL+N3Kuk30Nv0ZMgR76mISLX54TBVEBnaj p8MHUZVMg894/p4aIS2vi6GWR7ji4AUKYUGuUMEnq4/doIefcLr0WXvn20v12LTdSsFw wwAUJOmgIOEJgTcs1hR4gjWfC/wjRbGo8LCw/w0hkslqpJKSx9BFXSRR/a38uniFN9f3 DJ0IKfiJrg0OvYpxG6iunU34p2BmP3IzOWXculzpI6wekMARTM068B0A6OnyCGyp3R61 A/hg== 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=X4KlA0GNxWSk7ijvRjhrPNPuIGsaYqZoT0UXFQyZRIA=; b=A9pH2UGq5rWeT3pE3LzfKghomC4ZzyjH7PeGeIVOHZoSwbOXW5Kp2ryljr3aZ9Sdsq yVoWxUdYNnM47Q85vsJ2VZ8cjNbjabNRCqo2Hntmx57WBcCVDTC2Cmn+FwuOE35sbY7s u73SZ8Mc3yHuqvWuSMZT1nFvD6a3KoqpluyCQ0G6W3i7iMnfq26+Ae6x5PrIfQggU1Xp lkShe4zBCiVgEAo+DGJFjSERJh0aXVr67Lat+0BdmR1/WaARd18JTRhz3dPmH3ZrHz1N FS2hQnK0A5GaDW+ONHxDw+YeyGVHH/xJQqNvOm3+Ox7Yz7OqLwLwpKfCCkI0ArlH/UQw ZskA== X-Gm-Message-State: APjAAAXU+0K/6toBAmk41RygZFYHFeCOtDfj9kqY2kee5BBkIxva6LBh zxgdmjC1NE9iGMSoseEpkx+Ru8GtK6J9MrorojHu5A== X-Google-Smtp-Source: APXvYqw7AnHmyLpzHcI1pQySyYzFeDG8oEXi2v65xlugQA4DwzU7HbvwB7Ji6JtZmadDB0B+Vn/therIUNTu/zh9Bi0= X-Received: by 2002:a05:651c:10c:: with SMTP id a12mr1305049ljb.93.1572472163584; Wed, 30 Oct 2019 14:49:23 -0700 (PDT) MIME-Version: 1.0 References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Wed, 30 Oct 2019 14:48:46 -0700 Message-ID: Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Jana Iyengar , Mike Bishop , Martin Thomson , IETF QUIC WG , David Schinazi , Martin Duke , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000bae191059627b466" 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, 30 Oct 2019 21:49:28 -0000 --000000000000bae191059627b466 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 30, 2019 at 2:33 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > If the goal is to decide when the handshake is complete at both ends in >> finite time with high probability, then it appears that an explicit sign= al >> is required because you cannot rely on random (organic) 1-RTT traffic to >> drive this process. >> > Well, it's not clear to me that one needs to know this, actually. I agree > we've used this as a proxy for various things, but it's not actually clea= r > to me that we need to, so we should re-examine those cases to see what th= e > real preconditions are. > > For one thing, I would be sad if an optimised implementation needs to > handle multiple packet number spaces. That complicates implementations > because you need to think performance through all layers. Of course you c= an > just suck it up an deal with it. Likewise, you can probably find a way > around path migration. > > By compared to sending a single 1-byte HANDSHAKE_DONE frame, why would yo= u > do that? To marginally simplify the handshake? > This isn't an argument that keeping the keys around doesn't work, but rather that you think it's the wrong engineering tradeoff. It's possible you're right about that, but I'd like to start by establishing the agreed upon facts of what will and will not work before we debate engineering tradeoffs. -Ekr --000000000000bae191059627b466 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 30, 2019 at 2:33 PM Mikke= l Fahn=C3=B8e J=C3=B8rgensen <mikk= elfj@gmail.com> wrote:
<= p>If the goal is to decide when the handshake is complete at both ends in f= inite time with high probability, then it appears that an explicit signal i= s required because you cannot rely on random (organic) 1-RTT traffic to dri= ve this process.

Well, it's not clear to me = that one needs to know this, actually. I agree we've used this as a pro= xy for various things, but it's not actually clear to me that we need t= o, so we should re-examine those cases to see what the real preconditions a= re.

For one thing= , I would be sad if an optimised implementation needs to handle multiple pa= cket number spaces. That complicates implementations because you need to th= ink performance through all layers. Of course you can just suck it up an de= al with it. Likewise, you can probably find a way around path migration.

By compared to sending a single 1-byte HANDSHAKE_DONE frame, why would = you do that? To marginally simplify the handshake?

This isn't an argument that keeping the keys around doesn't work= , but rather that you think it's the wrong engineering tradeoff. It'= ;s possible you're right about that, but I'd like to start by estab= lishing the agreed upon facts of what will and will not work before we deba= te engineering tradeoffs.

-Ekr

--000000000000bae191059627b466-- From nobody Wed Oct 30 15:07:43 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8D512080C for ; Wed, 30 Oct 2019 15:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=lowentropy.net header.b=BkT7AznS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DPKXfzOm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNj7XuHjvWb0 for ; Wed, 30 Oct 2019 15:07:40 -0700 (PDT) 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 0AAC412011A for ; Wed, 30 Oct 2019 15:07:40 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2881B22402 for ; Wed, 30 Oct 2019 18:07:39 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 30 Oct 2019 18:07:39 -0400 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:content-transfer-encoding; s=fm3; bh=knIEA 69cxW4G2xSRvnXlYlNPWeFnNcQ0dAJSn+mvm3Q=; b=BkT7AznSbLBnAvpnu3Id3 cwEz8BTTsf2Sl8lFQIug/wbADTyDV7JX08dLKji9lTugbQgFMBsxMk3EHcZwxsWn KdLBo9I1A5ug4qWxykmCohdceYtNGhsLQF4JPdnYIxner2pZQ7tau+JFs31yS6a+ fm5oNfvxcNF50fuVARtY19rRyxI68t6GH4JnHdnCI1wZ9OAq76o0lCaGiOV1NCNC KEHgStJ++hHxf5ORuN4YPOEwj0ZOZy7gZWe8nnyE7ME4+citRcXQeqhxIX/eSx0c /HRT6balgeiKytv1YIQbsAgNDfgYNQbgebNj/x5pBXn8ZAHg9N7aYl0RA9Ehh8WX A== 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=fm1; bh=knIEA69cxW4G2xSRvnXlYlNPWeFnNcQ0dAJSn+mvm 3Q=; b=DPKXfzOmA0c6eMsDpyHG6Zh0iFdWPTsRAMwOADOk4oCWIobzwjMMEmjlX cC2L3irD8TbaY8CrxRUs/5zL31gSIG3s/Zw8AjOXzr91dT3R/mYVO2gwRYML2Yrd BqNo7A4amKAmAkNwbJMmUrO3+NXQtw3U7td6s6pej1WamaS1CMGz7TorkJSU9GNm In8AY4J1uLcscYFkQheBor0xsMF/vigE7TGcSubDfgzux/Rl6VUH/363NluuV6KG /oYkCv2Y5cQTSjAiC/NmcedYmXB592E10bRTHy8HdfRbNPnoAG9mUAQd16qC2XLJ HDXFZN+5iFQAfzvSUMIOYAxzZz+eQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtfedgudeivdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmthes lhhofigvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 918D8E00A3; Wed, 30 Oct 2019 18:07:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4974ed86-0fa9-435d-880f-80af637ef180.anqing.aq@alibaba-inc.com> Date: Thu, 31 Oct 2019 09:07:19 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Fast Address Validation - about 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: Wed, 30 Oct 2019 22:07:42 -0000 Also note that exchange of Handshake packets provides proof of return ro= uteability via the use of the encryption keys, so there is no need to ex= change tokens at that level. On Thu, Oct 31, 2019, at 03:29, Mike Bishop wrote: > =20 > The advantage of using Retry, however, is that the server is able to=20= > keep minimal (if any) state about the client. Exchanging the token at=20= > the Handshake encryption level means the server is already doing work=20= > and maintaining state in order to process the handshake, which is=20 > exactly what the server is trying to avoid. >=20 >=20 > *From:* QUIC *On Behalf Of * Qing An > *Sent:* Wednesday, October 30, 2019 9:41 AM > *To:* quic ; jri.ietf ; mt=20 > > *Cc:* =E5=88=98=E5=A4=A7=E9=B9=8F(=E9=B9=8F=E6=88=90) > *Subject:* Fast Address Validation - about >=20 >=20 >=20 >=20 > Hi Martin, Jana,=20 >=20 > I read through https://www.ietf.org/id/draft-ietf-quic-transport-23.tx= t=20 > and have a few comments and ideas to discuss. >=20 >=20 > [QUIC-Trans] defines a token based scheme to facilitate address=20 > validation of a client. The token MUST be covered by integrity=20 > protection against modification or falsification by clients. The serve= r=20 > remembers the value it sends to clients and validates the token sent=20= > back from a client. In its design, Retry packet is used to deliver the= =20 > token to a client which address has not yet been validated. It voids=20= > the first transmission of the Initial packet sent by the client, and=20= > triggers a second Initial packet to be sent with the token. The=20 > exchange of token will cause longer connection establishment delay for= =20 > a client. >=20 >=20 > To improve the efficiency of address validation during handshake, one=20= > idea is that the same token can be exchanged via a different container= =20 > i.e. the Handshake packet, that eliminates the use of Retry packet for= =20 > token delivery.=20 >=20 >=20 > I am working on the complete draft and will submit it by Friday. Befor= e=20 > that, hope this can be discussed in email first. >=20 >=20 > BR, >=20 > Qing An > From nobody Wed Oct 30 16:52:51 2019 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 845BE120220; Wed, 30 Oct 2019 16:52:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: magnus.westerlund@ericsson.com, mnot@mnot.net, quic@ietf.org, quic-chairs@ietf.org Subject: quic - New Interim Meeting Request X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157247956947.32502.2198494518875878990.idtracker@ietfa.amsl.com> Date: Wed, 30 Oct 2019 16:52:49 -0700 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, 30 Oct 2019 23:52:50 -0000 A new interim meeting request has just been submitted by Mark Nottingham. This request requires approval by the Area Director of the Transport Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-quic-01 --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Mark Nottingham City: Zurich Country: CH Session 1: Date: 2020-02-05 Start Time: 09:30 Europe/Zurich Duration: 07:00 Remote Participation Information: See arrangements page Agenda Note: Arrangements at: https://github.com/quicwg/wg-materials/blob/master/interim-20-02/arrangements.md Session 2: Date: 2020-02-06 Start Time: 09:30 Europe/Zurich Duration: 07:00 Remote Participation Information: See arrangements page Agenda Note: Arrangements at: https://github.com/quicwg/wg-materials/blob/master/interim-20-02/arrangements.md --------------------------------------------------------- From nobody Wed Oct 30 17:54:35 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916021208E0 for ; Wed, 30 Oct 2019 17:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=obuori3g; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rlVKXZRy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuxQZvCnP4Ut for ; Wed, 30 Oct 2019 17:54:27 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3328A1208FF for ; Wed, 30 Oct 2019 17:54:27 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6E23F21CDD for ; Wed, 30 Oct 2019 20:54:26 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 30 Oct 2019 20:54:26 -0400 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:content-transfer-encoding; s=fm3; bh=ggpny 8ywCsobdxUAc1VEo5Ld+MB9CRPmVvdOTtL29Jg=; b=obuori3g1mwQZrQZ/tLMV HeL3tcpDQiyoQAhvcgu9w40XgYp9dpvi3yuV8XA/MaJijRZx7gH+LjkFyY6SrHpu WuGb3/yArh/hJhO+GVcXskaJeG6HyeJH0dHvDnv19gG42WrUANhfDQ5ljaCuP8N6 XY0V46xBhhTlderDudj0713J70Wmf80ALYn13g4xCq0eMpQU08BA6+Aci4Y0SF+c d+NNAzVOv3p2GmnAH+NYH95KpulS56CpsET+ph8Pk0gscgWXrphsyr6vYvsOaGXd GyohWUm7JGk7vPvZTl8y3Tl8P1oJDs6MdrmLkR7ULnsmOUv+op6tEPeFyzq26vsF g== 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=fm1; bh=ggpny8ywCsobdxUAc1VEo5Ld+MB9CRPmVvdOTtL29 Jg=; b=rlVKXZRygqEx+HXADO3SLAW49AV+DbUmpqyCpFmEuluJgxXX3O0GYMCom B2U0+5pQHBYLZVWwPIQbT0Dfhrsoob5F6bmfm8jSggLs0Z3tRR968slVpQiFSdJe fMApN1Ba7Y6MlpMFOAXk8xoWX06T8Ej0laZlV0UanZ/1II20P02zEWHnRhtsSBi+ hnYU1EY0ICgZHyQ2c1/rFsBB+xu3eS/ykfeF+yikgs7PJYwa64X8eMfiZst+eZ/0 vT9p/Kv+h3rs4cCGztyFmAZcQTQQzZ09ZzvuczBhkYOBTLKZlBE/4atvXfksEuCK KPRGwmng3q4EKOfeDfojZZ7WVdTzw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtgedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslh hofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 045A0E00A5; Wed, 30 Oct 2019 20:54:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <3d4976da-b03d-469c-9242-4073d88048e3@www.fastmail.com> In-Reply-To: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> Date: Thu, 31 Oct 2019 11:54:06 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino 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, 31 Oct 2019 00:54:34 -0000 On Thu, Oct 31, 2019, at 08:21, Eric Rescorla wrote: > On Wed, Oct 30, 2019 at 2:06 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen=20 > wrote: > >> I'm going to stop here, because it seems that you're assuming we do= n't just keep the keys indefinitely. How does that lead to deadlock? > >=20 >=20 > > The problem is that having keys indefinitely leads to various proble= ms. >=20 > I've heard that asserted but I'm not so sure. The problems I'm aware of are largely edifices of our own construction. The primary one I am aware of is that we don't know what to do about sen= ding Handshake packets after a migration. This is fixable, because it i= s a definitional problem. We haven't defined what to do. The problem i= s, I think just limited to the use of Source Connection ID on long heade= r packets. I personally would prefer not to have to fix this one. If you don't continue sending Handshake packets, that has the same effec= t as discarding keys for the side that is being starved of acknowledgmen= ts. We could also build, as Mike alludes to, an implicit acknowledgment. We= currently have one for the Initial->Handshake transition and we could b= uild another. That only reduces this from a symmetric issue to an asymm= etric one unless we address the existing problem. If we were able to reduce this to just a client-side problem, then we mi= ght also say that clients can't migrate prior to verifying that all Hand= shake data was transmitted to as to avoid any need for problems. Then m= igration becomes proof positive that the client is done transmitting and= that can be the signal. Of course, this is all getting increasingly byzantine. From nobody Wed Oct 30 18:10:10 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2E412006D for ; Wed, 30 Oct 2019 18:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=35crqIx9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WEFiM7Pd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oIfJYnya81b for ; Wed, 30 Oct 2019 18:10:06 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86AAB12006B for ; Wed, 30 Oct 2019 18:10:06 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id BD81B557; Wed, 30 Oct 2019 21:10:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 30 Oct 2019 21:10:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm1; bh=NZlq2FHTP8FBV7KfL+TYKvuORsHUgn k4uLrAu1H7dAI=; b=35crqIx9vFrkQ8L1O4IwucuziAmsZ5vlHZG9ft94yCBbib FI3A9CebLrhbuw8xhA4oFsLOFVQgTWENdMBM+soGwQrgYCtKuDBRP0VD2+Y+rZ3p GXluf0h1v7oBT6NFqCD6gEYLmo68YxbpqHVTJz2fuO7+O+VMO31gYX5qzVej6VXR e1ypE1pGcPvmDj2Sy3/8jrCleCSrzwUiGfc8LNwPg792UrJmhD23OY16HEEPRXo2 n5JheLw1PEPLKGsF77+RADOz10S6OdbBbljelhfBqcdL4o/mGGzPrXSqBUSwhr/y v55qXqFORitjnHwhw/cHzEP+E3lQEdD6AZX+Acxg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=NZlq2F HTP8FBV7KfL+TYKvuORsHUgnk4uLrAu1H7dAI=; b=WEFiM7PdFGRGJiQ8UFBYLi hU8oP4h3uUFj+LM07G1+ZYOf/2RAqX9pCa7EgDxl3PraLg5jNXBE7NiA9aOwFX5i LqIlu8Ocu/OQMe+0YMPuCEu20UjWCmF57l5/SGgtzKGdXgtjnLz65TpylBQdtj/K ATUB3iGoU4TLbXS+sWRgT1pnfvEmRWW5ljFQqDA4jq2MybzyXozd/xN8CxOJ+zaz C9QoesGeBdQPNfVba4RmQyKtI9T954UlgyCSoxJqrLZsadkHA0fZahsO+HTVH2eh b2sNxkBmfW5xAEngHD110/5nJHLSSP5IT6a/UQmdLj7aVhmXUEsoJFNyJWV27u3A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtgedgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhephh htthhpfedrihhnnecukfhppeduudelrddujedrudehkedrvdehudenucfrrghrrghmpehm rghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 83CAB80063; Wed, 30 Oct 2019 21:10:02 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Proposed response to the 3GPP Liaison Statement Message-Id: <3218A80B-DAFD-43EF-8200-F99C660DF9C9@mnot.net> Date: Thu, 31 Oct 2019 12:09:57 +1100 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3594.4.19) 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, 31 Oct 2019 01:10:09 -0000 QUIC WG participants, Lars and I have discussed a response to this statement and plan on = sending the message below. If you have comments, please respond to this = e-mail by 6 November. Regards, ~~~ Thank you for your input to our specifications. Regarding the encryption of headers in addition to payload, this was a = conscious design decision by the Working Group. Transport header = encryption prevents modification by middleboxes, thereby avoiding = ossification of the protocol, and also makes traffic analysis more = difficult. The impact upon network operators was discussed extensively = as part of that decision. Regarding the spin bit, we believe that your characterisation is = correct. Regarding packet loss measurements, QUIC does support them, but only by = the endpoints of communication -- not by third parties observing it. = Keys may be exported by one of the endpoints to allow decoding of packet = traces (e.g., with Wireshark), but that is not part of the QUIC = standard. Regarding performance analysis, it would be helpful if you described = your use case in more detail. However, it's important to know that the = Working Group decided early on that QUICv1 would focus on the use case = of HTTP/3. In turn, HTTP standardisation focuses primarily on the Web browsing use = case; while we acknowledge that there are other uses of the protocol, = and we accommodate them where possible, we cannot change the protocol in = ways that harms that use. Exposing transport metadata would likely do = so. Kind regards, Mark Nottingham and Lars Eggert, QUIC Working Group chairs ~~~ From nobody Wed Oct 30 18:14:10 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36CB12006D for ; Wed, 30 Oct 2019 18:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=lowentropy.net header.b=UiRLF6XR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=awer+1Zb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AcWXTz903hp for ; Wed, 30 Oct 2019 18:14:07 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BFA12006B for ; Wed, 30 Oct 2019 18:14:07 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B56BD2239D for ; Wed, 30 Oct 2019 21:14:06 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 30 Oct 2019 21:14:06 -0400 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=fm3; bh=+/anGVrTY5kZWu984J/1dj0knpzdG14 MKxcHQnrBB24=; b=UiRLF6XRYoIM8ohCtAxIBUGPbeSFXit0TlGePbzJJDLYdEk 54HP4HM7VtTZGoYZ5dRo05xdQOoZ6y7mdUAI0EHm3E34Jn3mnGbJrwD9aT7Dyjof Mv9R1X0CbK4j3Tk8SRNoNICE9TZ8gOGgN3IJzREfcvUZeKlbjp96TKquVDNlvjqo VXLb4LRiCghlpxlk6JhPzGIVimqVKUglL7ATBCMxrB3TKZOSF3xQ38lsTZONryDQ iEmIeN265vQaIKhtlUCu+fNvnJR/1BenG8xizTfaYegj0fF0BTlouXZ3mjqV/WvS edafNC9edvY3/5JUa2KcNEtvuQkkighGyqjBFfw== 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=fm1; bh=+/anGV rTY5kZWu984J/1dj0knpzdG14MKxcHQnrBB24=; b=awer+1Zb0g3PWiBw10YOH+ jynw1Z72r5HAudLD7kTEhxNJWA4LYQ62uXiUmgD894kq1Gp8GkDwml70fpzsl+mP C3FKttKc5vM/XYJGUqU2TPdd9mnErEa8LrEYdKoTHqh534RIlFRRjUVGJihUQhTd 88sbTY8YZSGZS74dmdQHnt3zH9IDxInZzVJ45ZTCu5qq10NiKkfY14VhGHxFw1Tt YJfL1yRrweZPfHMLNkBx9yPhPCfzxeWL0ytS/7Wd8UhMrW9wujRZhgSw7mVZ5VXm KqjZOBV0X7e63ElIx6/DOlloa9tI76ajlA2Lxx214UheafwhX+8deQd4sLIPB1fw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtgedgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhephhhtthhpfedrihhnpdhivghtfh drohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidr nhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 570CBE00A3; Wed, 30 Oct 2019 21:14:06 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <5557f717-ae03-46a2-aa9f-54f019a07533@www.fastmail.com> In-Reply-To: <3218A80B-DAFD-43EF-8200-F99C660DF9C9@mnot.net> References: <3218A80B-DAFD-43EF-8200-F99C660DF9C9@mnot.net> Date: Thu, 31 Oct 2019 12:13:48 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Proposed response to the 3GPP Liaison Statement 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: Thu, 31 Oct 2019 01:14:09 -0000 https://tools.ietf.org/html/draft-iab-path-signals-03 seems like it might be a helpful supporting document. On Thu, Oct 31, 2019, at 12:09, Mark Nottingham wrote: > QUIC WG participants, > > Lars and I have discussed a response to this statement and plan on > sending the message below. If you have comments, please respond to this > e-mail by 6 November. > > Regards, > > ~~~ > Thank you for your input to our specifications. > > Regarding the encryption of headers in addition to payload, this was a > conscious design decision by the Working Group. Transport header > encryption prevents modification by middleboxes, thereby avoiding > ossification of the protocol, and also makes traffic analysis more > difficult. The impact upon network operators was discussed extensively > as part of that decision. > > Regarding the spin bit, we believe that your characterisation is correct. > > Regarding packet loss measurements, QUIC does support them, but only by > the endpoints of communication -- not by third parties observing it. > Keys may be exported by one of the endpoints to allow decoding of > packet traces (e.g., with Wireshark), but that is not part of the QUIC > standard. > > Regarding performance analysis, it would be helpful if you described > your use case in more detail. However, it's important to know that the > Working Group decided early on that QUICv1 would focus on the use case > of HTTP/3. > > In turn, HTTP standardisation focuses primarily on the Web browsing use > case; while we acknowledge that there are other uses of the protocol, > and we accommodate them where possible, we cannot change the protocol > in ways that harms that use. Exposing transport metadata would likely > do so. > > Kind regards, > > Mark Nottingham and Lars Eggert, QUIC Working Group chairs > ~~~ > > From nobody Wed Oct 30 18:32:36 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE6A12006D for ; Wed, 30 Oct 2019 18:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 rUr9YdQye09D for ; Wed, 30 Oct 2019 18:32:33 -0700 (PDT) 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 7A5C012006B for ; Wed, 30 Oct 2019 18:32:33 -0700 (PDT) Received: from xse119.mail2web.com ([66.113.196.119] helo=xse.mail2web.com) by mx42.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iPzKB-0000pX-63 for quic@ietf.org; Thu, 31 Oct 2019 02:32:31 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 473SVh5wsbzDJ0g for ; Wed, 30 Oct 2019 18:32:28 -0700 (PDT) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iPzK8-0005dR-Mz for quic@ietf.org; Wed, 30 Oct 2019 18:32:28 -0700 Received: (qmail 6105 invoked from network); 31 Oct 2019 01:32:28 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.43.199]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 31 Oct 2019 01:32:28 -0000 To: Martin Thomson , quic@ietf.org References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> <3d4976da-b03d-469c-9242-4073d88048e3@www.fastmail.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: Consensus Calls for Transport/TLS issues, post-Cupertino Message-ID: Date: Wed, 30 Oct 2019 18:32:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: <3d4976da-b03d-469c-9242-4073d88048e3@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.119 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.119/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.119/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0eT2jivapI8P7M2alpZfRhCpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fsHUAwQyAS6Z16OrymzkVrfU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+5TET6yHkPghP15YtvjJl4PfOdU2kQFJEzfkq4ITozmM46jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhMjx7v77N42Z/zX3DQBtZa/0j9rMdVQseW3F+doIupqmER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnIICQUXeDwOf eh9dq5sN87Num+bgkQ4H2FNFlS4D2FvpWwfcySviKCNdCicCm/3F75q98CzvL6WklUVeB43D+95U PVcmx1QL+XiKf76y/BgKy6+v15iWes3ERNufthmnDfKY2AXNZGS5G93aGyH8MqMlOQRMVMd0HCeT skOZ5TL8tRsi33jcP56s/k+61AD1KzXg724gFzhHYUe+7aKm0vVLM1yZAmAuF8Lt5QD5O45/Ti+J 2sBvM/O0p+zizleC4va6FPcpDHjXMKZJK8+chiZLiCUk/wm5a/nDs/3HETCT7cTs80/2FnZg/IMs IAdedSzLrjsyfTPCYbMCLdmf5h2vfxw3Qvb2Glio5Cia/9Kfg4kJ0WtAYbrpe3OOAtQNb87OBHCz Hbokiue7PjVB1S6AQRz4SqXhOP5fdiQt7lu5Jm5nk4BSgYHOJJgUtm67rBRli6kULE5BQDZnPvvF VsQ= X-Report-Abuse-To: spam@quarantine9.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, 31 Oct 2019 01:32:35 -0000 On 10/30/2019 5:54 PM, Martin Thomson wrote: > On Thu, Oct 31, 2019, at 08:21, Eric Rescorla wrote: >> On Wed, Oct 30, 2019 at 2:06 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen=20 >> wrote: >>>> I'm going to stop here, because it seems that you're assuming we don= 't just keep the keys indefinitely. How does that lead to deadlock? >>> The problem is that having keys indefinitely leads to various problem= s. >> I've heard that asserted but I'm not so sure. > The problems I'm aware of are largely edifices of our own construction.= > > The primary one I am aware of is that we don't know what to do about se= nding Handshake packets after a migration. This is fixable, because it i= s a definitional problem. We haven't defined what to do. The problem is= , I think just limited to the use of Source Connection ID on long header = packets. I personally would prefer not to have to fix this one. > > If you don't continue sending Handshake packets, that has the same effe= ct as discarding keys for the side that is being starved of acknowledgmen= ts. There is the half-way step of only sending acknowledgements, only upon receipt of new Handshake packets. > We could also build, as Mike alludes to, an implicit acknowledgment. W= e currently have one for the Initial->Handshake transition and we could b= uild another. That only reduces this from a symmetric issue to an asymme= tric one unless we address the existing problem. I would assume that implementations, in practice, will consider implicit acknowledgements. This is fairly obvious on the server side: receiving the "handshake complete" from the stack means that all required handshake packets have been received by both parties. The server knows that there is no point in re-transmitting any of the previous handshake packets. It can implement the "implicit ack" logic without breaking anything on the server side. I assume that implementations will just do that, no matter what the Quic spec says, because it makes the server stack robust to silly scenario in which the client's acks of handshake packets get lost. Which means that the Quic spec might just as well say i= t. So the problem really is asymmetric. The client is fine, because it eventually receives an ACK of its final handshake packet can can consider the handshake confirmed at that point. But the server never knows whether the ack of the final handshake was properly received. > If we were able to reduce this to just a client-side problem, then we m= ight also say that clients can't migrate prior to verifying that all Hand= shake data was transmitted to as to avoid any need for problems. Then mi= gration becomes proof positive that the client is done transmitting and t= hat can be the signal. Migration is only initiated by the client in V1, so waiting for the last handshake ACK on the client side is good enough. But key rotation could be initiated by the server, and doing that before handshake confirmed is a bit problematic. Which means that the server needs to know whether the client's handshake is confirmed, which is where the Handshake Done signal becomes useful. My preference would be for the server to send that signal and repeat it until it is acknowledged by the client. When that ACK is received, the server knows that the handshake is confirmed. -- Christian Huitema From nobody Wed Oct 30 18:44:54 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E62C12008B for ; Wed, 30 Oct 2019 18:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=KLbq9KrT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GTAmBn2C Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xBcGfUOpyAi for ; Wed, 30 Oct 2019 18:44:50 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F3412006B for ; Wed, 30 Oct 2019 18:44:50 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C7CBF223E6 for ; Wed, 30 Oct 2019 21:44:49 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 30 Oct 2019 21:44:49 -0400 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=fm3; bh=iJzge3cdpI8rcuFkA8Tb/Nesw8TAjsS G+AlOOFxpPng=; b=KLbq9KrTcCJBoI+w7bREeA48r4kD/J6t0ZBHll5rgWo2dY8 I5q2HkhbJ/a6b4X60VO5AFzPZ3C1XeAv1YVFYLjIxFXITr5JbADChrTRMa7A1nob e3+kQf68HI1pknTXHD9kz2mfnEx4o+GwyYwKekS4y8Pv14LF9MwxzrJS3WSDvz6p rTaTFHF3Fev/CWXw0RcXL+OM+JmUldq1XHBbLu+MH38xqqLLbh/Xj7ktpz7y/DJ9 7xXBFgoVGhO2qLerlkEvHZTyXo6ogP70ThVrBFhZwYDHtDyXOncxlonl44gGdqDv IGE02nvSnMm6a60bkUL39Yqv+cQ5otppfsQV8hw== 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=fm1; bh=iJzge3 cdpI8rcuFkA8Tb/Nesw8TAjsSG+AlOOFxpPng=; b=GTAmBn2Cx6KpED+nu6CJKf XygQEFKvxtM6hQxAPkJR8jYDGbND3UUp99TzzKJQMqr1WTEcAqxJD4erknSOUEcS 74EPZYSGu6gg+gCu/Z5eabP9l4CciRVwd0QloWqxSmzMXhxmDt8zjvhs4VdhnJI3 UFEOFhPqUeXP4B9MHmBZUI2sbWy00vPbaqir+XtyOoLZ9cmc9dTEwHCRtO1d8jXo zt7FYhkwVL83iOf/Xhw18IswyZv8gftH9BNQQ5TMgnBJOXXoxtrpVPlrFzAqtk2X Ubd83EjDUFL7Q0IGSU6keAjSGNfCxpUtwCjbYoZm6sp+eJ0EVzqN9dTdGsmrHCCg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtgedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3C06CE00A3; Wed, 30 Oct 2019 21:44:49 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <536ff4e2-ccf3-4a83-a071-da5bedd3a8d6@www.fastmail.com> In-Reply-To: References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> <3d4976da-b03d-469c-9242-4073d88048e3@www.fastmail.com> Date: Thu, 31 Oct 2019 12:44:30 +1100 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino 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: Thu, 31 Oct 2019 01:44:52 -0000 On Thu, Oct 31, 2019, at 12:32, Christian Huitema wrote: > Migration is only initiated by the client in V1, so waiting for the last > handshake ACK on the client side is good enough. But key rotation could > be initiated by the server, and doing that before handshake confirmed is > a bit problematic. I don't see how this is problematic. Handshake packets use Handshake keys, so they aren't updated. From nobody Wed Oct 30 19:45:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640071208DC for ; Wed, 30 Oct 2019 19:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 HFyduY0dd4mw for ; Wed, 30 Oct 2019 19:44:57 -0700 (PDT) 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 9DAE3120233 for ; Wed, 30 Oct 2019 19:44:57 -0700 (PDT) Received: from xse190.mail2web.com ([66.113.196.190] helo=xse.mail2web.com) by mx63.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iQ0SD-0002Hi-0p for quic@ietf.org; Thu, 31 Oct 2019 03:44:56 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 473V2t4vGPz34Gl for ; Wed, 30 Oct 2019 19:41:58 -0700 (PDT) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iQ0PO-00042w-IJ for quic@ietf.org; Wed, 30 Oct 2019 19:41:58 -0700 Received: (qmail 4114 invoked from network); 31 Oct 2019 02:41:57 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.43.199]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 31 Oct 2019 02:41:57 -0000 To: Martin Thomson , quic@ietf.org References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> <3d4976da-b03d-469c-9242-4073d88048e3@www.fastmail.com> <536ff4e2-ccf3-4a83-a071-da5bedd3a8d6@www.fastmail.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: Consensus Calls for Transport/TLS issues, post-Cupertino Message-ID: Date: Wed, 30 Oct 2019 19:41:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: <536ff4e2-ccf3-4a83-a071-da5bedd3a8d6@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------8D8397F4113A14719D77299F" Content-Language: en-US X-Originating-IP: 66.113.196.190 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.190/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.190/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0eT2jivapI8P7M2alpZfRhCpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fsEkidX8PDRLDQGuvLgICHkU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+5aB4itzNZ07CdqP+KMfGjQPLhBThvdgyPN49yzDQzRHY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhMjx7v77N42Z/zX3DQBtZa/0j9rMdVQseW3F+doIupqmER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnOu9dHI/x63E XXKWrOjLtA8Ya0DFhKR0reMjbnA+hNVVyZFKy9acGP2G9wefCwJk0jKR6RgQ6scM/oDJnhhySxmk 8ddidt497ukgeh2bxPKOmhlKb/lC+C9AijoWgc8vkIGThCScvU0cCIiHSQbmcVLsSBUDU8DB/PRo DwE+cXXrIPeg9WrzDXOtahmLPdT6/MzO9jkpm3KO2unVpqAXWIbyHjShwajqro3QwvhsmEoiXPWl FdaGOH191uXjgjQN/RTaYTLUj/RFhcnr3QktcdhpZEgTfRD7Oi9PJMfVrBSi1vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM= X-Report-Abuse-To: spam@quarantine9.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, 31 Oct 2019 02:45:03 -0000 This is a multi-part message in MIME format. --------------8D8397F4113A14719D77299F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/30/2019 6:44 PM, Martin Thomson wrote: > On Thu, Oct 31, 2019, at 12:32, Christian Huitema wrote: >> Migration is only initiated by the client in V1, so waiting for the la= st >> handshake ACK on the client side is good enough. But key rotation coul= d >> be initiated by the server, and doing that before handshake confirmed = is >> a bit problematic.=20 > I don't see how this is problematic. Handshake packets use Handshake k= eys, so they aren't updated. Yes, that should work. The client could also consider the server-initiated key rotation as an implicit acknowledgement of the Handshake packets, since the server is only supposed to initiate a rotation after Handshake Confirmed. The client can delete the Handshake Key at that point. In fact, If the server successfully sees the client rotating the keys, it can induce that the client has received an implicit ack of all the handshake packets, and it too can delete its Handshake Keys. So if either side initiates a key rotation and the key rotation succeeds, both sides can jettison the Handshake keys -- provided the server only initiates after receiving the Client Finished message, and the client only initiates after receiving an ACK of that message. So we have a solution that works if the server if willing to keep the Handshake key forever, and allows the server to jettison the Handshake keys if it is willing to rotate the 1RTT key. -- Christian Huitema --------------8D8397F4113A14719D77299F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 10/30/2019 6:44 PM, Martin Thomson wrote:

On Thu, Oct 31, 2019, at 12:32, Christian Huitema wrote:

Migration is only initiated by the client in V1, so waiting for the last
handshake ACK on the client side is good enough. But key rotation could
be initiated by the server, and doing that before handshake confirmed is
a bit problematic. 

I don't see how this is problematic.  Handshake packets use Handshake keys, so they aren't updated.

Yes, that should work. The client could also consider the server-initiated key rotation as an implicit acknowledgement of the Handshake packets, since the server is only supposed to initiate a rotation after Handshake Confirmed. The client can delete the Handshake Key at that point.

In fact, If the server successfully sees the client rotating the keys, it can induce that the client has received an implicit ack of all the handshake packets, and it too can delete its Handshake Keys. So if either side initiates a key rotation and the key rotation succeeds, both sides can jettison the Handshake keys -- provided the server only initiates after receiving the Client Finished message, and the client only initiates after receiving an ACK of that message.

So we have a solution that works if the server if willing to keep the Handshake key forever, and allows the server to jettison the Handshake keys if it is willing to rotate the 1RTT key.

-- Christian Huitema

--------------8D8397F4113A14719D77299F-- From nobody Wed Oct 30 19:52:49 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D08B1200D6 for ; Wed, 30 Oct 2019 19:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=YXYzgKmb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tdmAU2hq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZttnjBsygfm for ; Wed, 30 Oct 2019 19:52:44 -0700 (PDT) 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 BE061120059 for ; Wed, 30 Oct 2019 19:52:44 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 2060347D; Wed, 30 Oct 2019 22:52:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 30 Oct 2019 22:52:43 -0400 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=5 C+sgrEmEwsLL3gbivFlZjbEPFYI4f2KTEXGWWpxWLY=; b=YXYzgKmbDcekDmW4J TrADc1K8SQoVfsp8jsBJjT8ft9ItXcI8kIYi/DB3gGYwSwU1aadGOKQieWdZcAIZ 6REEGjILKFK1/VMqWCACogXEMeA5Yb9Vr/uslaYdkFjwfKuht6YXIebZV19ciUpl Vqa0lR/rA5FA4pMiqbq+GTh1dfZls75UyMgT2qfvu4yI0YQb8jPqU9EB+8l77AGE OwmGWO5mVfwsPjBCEIPUslDvmXSk7ZFhjdr3asMdkvuog3WF1yZFMXqw7RC1MAi1 rQ/D53O4K42XkDWb+M7OdfAznC7cbAIj4Bp0noOFyVJynTe9fzR6VmGUNLuQOte+ HG4xw== 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=fm1; bh=5C+sgrEmEwsLL3gbivFlZjbEPFYI4f2KTEXGWWpxW LY=; b=tdmAU2hqUKRrnyUiMBLldBe4AwTj0qJbyCVvwRx7Sbz1zLeI+fA9IE3o2 KmkB9iu/fqQjLae3xh4KeqkgglJE5HbNL2AV5I6CY1B3ImsB5uPaUIVLSevD4yPk bKBVUang1APDrEWtgSIbJNsdEtcqR7gY4l+fry+Y3vsUpKP547aoh5K/+YG2R3qW Z3T5KbWeSJb7CdKfdFcuVwFRxVeka3wFc53Oxmy2HqFy8MX5BlPHex7In+czVQLq CmjKRNAKuSSBBxq+YUpIlsuFutzix+aPad61xNcNYDQiF81GQtRGWRb4eNi/HROW MqBa0o2jP90w5UDPHby/dNkNCU7iw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtgedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudduledrudejrdduheek rddvhedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 562FD8005B; Wed, 30 Oct 2019 22:52:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino From: Mark Nottingham In-Reply-To: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> Date: Thu, 31 Oct 2019 13:52:34 +1100 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <21A8E0BB-888C-48E6-83C6-D095546CC23A@mnot.net> References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> To: IETF QUIC WG X-Mailer: Apple Mail (2.3594.4.19) 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, 31 Oct 2019 02:52:47 -0000 With the exception of #2863 (where we'll continue discussion), consensus = declared. Cheers, > On 22 Oct 2019, at 11:42 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 next week. >=20 > See for the current = state of issues in the Late Stage process, itself defined at = . >=20 > * #3097: Is CONNECTION_CLOSE ACK-eliciting? > The proposal is >=20 > * #3085: Stateless reset detection should be datagram-based > The proposal is >=20 > * #3054: Label for key updates > The proposal is >=20 > * #3046: Handling of Retire Prior To field > The proposal is >=20 > * #3037: Require peers to check if RETIRE_CONNECTION_ID sequence = number is valid > The proposal is >=20 > * #3027: Codes for frame encoding errors > The proposal is >=20 > * #2944: Layout of PreferredAddress > The proposal is to close with no action. >=20 > * #2928: Lift single-packet ClientHello requirement? > The proposal is >=20 > * #2863: unrecoverable loss pattern leads to deadlock > The proposal is >=20 > * #2823: Do Initial secrets change after Retry packet? > The proposal is >=20 > * #2741: Re-visit initial keys discard > The proposal is to close with no action. >=20 > * #2152: Why does stateless reset have to be checked after MAC failure > The proposal is >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu Oct 31 05:56:07 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133B8120851 for ; Thu, 31 Oct 2019 05:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=alibaba-inc.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 vXovrFVfUL3Y for ; Thu, 31 Oct 2019 05:56:02 -0700 (PDT) Received: from out0-139.mail.aliyun.com (out0-139.mail.aliyun.com [140.205.0.139]) (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 F17F9120074 for ; Thu, 31 Oct 2019 05:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1572526558; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=9OYjlGlBnsFYukVDzTTwanctfkqp9wje8Y+21HYSKy0=; b=lGkMFiPyohDs5PZ/dzG7KOsifnOmEIBMBy4nylx9vsAZ9ibKrHZqGw5pEKG1rQqqbGf7IIF0x0gD5y5IkSZJlF8wwHtmlNgR531tweDriv7rtuZ9DfCuLVrmzSupVQljCjkHYVAWnnoagCeYuFSU0IIkZzqNQ70Al8ptW2aEkjA= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03310; MF=anqing.aq@alibaba-inc.com; NM=1; PH=DW; RN=4; SR=0; TI=W4_5657687_v5ForWebDing_0A930BF4_1572515468662_o7001c4443s; Received: from WS-web (anqing.aq@alibaba-inc.com[W4_5657687_v5ForWebDing_0A930BF4_1572515468662_o7001c4443s]) by e02c03267.eu6 at Thu, 31 Oct 2019 20:55:56 +0800 Date: Thu, 31 Oct 2019 20:55:56 +0800 From: "Qing An" To: "quic" , "jri.ietf" , "mt" , "mikkelfj" Reply-To: "Qing An" Message-ID: Subject: =?UTF-8?B?UmU6IEZhc3QgQWRkcmVzcyBWYWxpZGF0aW9uIC0gYWJvdXQ=?= X-Mailer: [Alimail-Mailagent revision 2765257][W4_5657687][v5ForWebDing][Chrome] MIME-Version: 1.0 References: <4974ed86-0fa9-435d-880f-80af637ef180.anqing.aq@alibaba-inc.com> , x-aliyun-mail-creator: W4_5657687_v5ForWebDing_NTMTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTVfMCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzc4LjAuMzkwNC43MCBTYWZhcmkvNTM3LjM2XQ In-Reply-To: Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_80694_4c170940_5dbad9dc_324138" 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, 31 Oct 2019 12:56:05 -0000 ------=ALIBOUNDARY_80694_4c170940_5dbad9dc_324138 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 CgpUbyBjbGFyaWZ5LCB0aGUgcHJvcG9zYWwgaXMgbm90IHRvIHJlcGxhY2UgdGhlIGV4aXN0aW5n IFJldHJ5LWJhc2VkIHZhbGlkYXRpb24sIGJ1dCB0byBwcm92aWRlIGFub3RoZXIgb3B0aW9uIGZv ciBzZXJ2ZXIgdG8gZG8gdGhlIGNsaWVudCB2YWxpZGF0aW9uLgoKSSB1bmRlcnN0YW5kIHRoYXQg aW4gc2VydmVyIHNpZGUsIGV4Y2hhbmdpbmcgdGhlIHRva2VuIGF0IHRoZSBIYW5kc2hha2UgZW5j cnlwdGlvbiBsZXZlbCB3aWxsIG1ha2UgdGhlIHNlcnZlciBzdGFydCB0byBtYWludGFpbiBoYW5k c2hha2Ugc3RhdGVzLiBCdXQgaW4gY2xpZW50IHNpZGUsIGl0IGNhbiBhY2NlbGVyYXRlIHRoZSBj b25uZWN0aW9uIGVzdGFibGlzaG1lbnQgZnJvbSBjbGllbnQgdG8gc2VydmVyLgoKQW5kIGl0IGlz IHRoZSBzZXJ2ZXIncyBkZWNpc2lvbiB3aGV0aGVyIHRvIGV4Y2hhbmdlIHRva2VuIGluIFJldHJ5 IG9yIGluIEhhbmRzaGFrZS4gSWYgc2VydmVyIGNob29zZXMgdG8gYWNjZXB0IHRoZSBjb3N0IGJy b3VnaHQgYnkgdG9rZW4gZXhjaGFuZ2luZyBpbiBIYW5kc2hha2UsIGl0IHdpbGwgYnJpbmcgbW9y ZSBlbmhhbmNlZCBleHBlcmllbmNlIGluIGNsaWVudCBzaWRlLgoKCkJSLApRaW5nCgoKCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQpGcm9tOk1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldD4KU2VuZCBUaW1lOjIw MTnlubQxMOaciDMx5pelKOaYn+acn+WbmykgMDY6MDcKVG86cXVpYyA8cXVpY0BpZXRmLm9yZz4K U3ViamVjdDpSZTogRmFzdCBBZGRyZXNzIFZhbGlkYXRpb24gLSBhYm91dAoKQWxzbyBub3RlIHRo YXQgZXhjaGFuZ2Ugb2YgSGFuZHNoYWtlIHBhY2tldHMgcHJvdmlkZXMgcHJvb2Ygb2YgcmV0dXJu IHJvdXRlYWJpbGl0eSB2aWEgdGhlIHVzZSBvZiB0aGUgZW5jcnlwdGlvbiBrZXlzLCBzbyB0aGVy ZSBpcyBubyBuZWVkIHRvIGV4Y2hhbmdlIHRva2VucyBhdCB0aGF0IGxldmVsLgoKT24gVGh1LCBP Y3QgMzEsIDIwMTksIGF0IDAzOjI5LCBNaWtlIEJpc2hvcCB3cm90ZToKPiAgCj4gVGhlIGFkdmFu dGFnZSBvZiB1c2luZyBSZXRyeSwgaG93ZXZlciwgaXMgdGhhdCB0aGUgc2VydmVyIGlzIGFibGUg dG8gCj4ga2VlcCBtaW5pbWFsIChpZiBhbnkpIHN0YXRlIGFib3V0IHRoZSBjbGllbnQuIEV4Y2hh bmdpbmcgdGhlIHRva2VuIGF0IAo+IHRoZSBIYW5kc2hha2UgZW5jcnlwdGlvbiBsZXZlbCBtZWFu cyB0aGUgc2VydmVyIGlzIGFscmVhZHkgZG9pbmcgd29yayAKPiBhbmQgbWFpbnRhaW5pbmcgc3Rh dGUgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgaGFuZHNoYWtlLCB3aGljaCBpcyAKPiBleGFjdGx5 IHdoYXQgdGhlIHNlcnZlciBpcyB0cnlpbmcgdG8gYXZvaWQuCj4gCj4gCj4gKkZyb206KiBRVUlD IDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+ICpPbiBCZWhhbGYgT2YgKiBRaW5nIEFuCj4gKlNlbnQ6 KiBXZWRuZXNkYXksIE9jdG9iZXIgMzAsIDIwMTkgOTo0MSBBTQo+ICpUbzoqIHF1aWMgPHF1aWNA aWV0Zi5vcmc+OyBqcmkuaWV0ZiA8anJpLmlldGZAZ21haWwuY29tPjsgbXQgCj4gPG10QGxvd2Vu dHJvcHkubmV0Pgo+ICpDYzoqIOWImOWkp+m5jyjpuY/miJApIDxtYXgubGRwQGFsaWJhYmEtaW5j LmNvbT4KPiAqU3ViamVjdDoqIEZhc3QgQWRkcmVzcyBWYWxpZGF0aW9uIC0gYWJvdXQKPiAKPiAK PiAKPiAKPiBIaSBNYXJ0aW4sIEphbmEsIAo+IAo+IEkgcmVhZCB0aHJvdWdoIGh0dHBzOi8vd3d3 LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQtMjMudHh0IAo+IGFuZCBoYXZl IGEgZmV3IGNvbW1lbnRzIGFuZCBpZGVhcyB0byBkaXNjdXNzLgo+IAo+IAo+IFtRVUlDLVRyYW5z XSBkZWZpbmVzIGEgdG9rZW4gYmFzZWQgc2NoZW1lIHRvIGZhY2lsaXRhdGUgYWRkcmVzcyAKPiB2 YWxpZGF0aW9uIG9mIGEgY2xpZW50LiBUaGUgdG9rZW4gTVVTVCBiZSBjb3ZlcmVkIGJ5IGludGVn cml0eSAKPiBwcm90ZWN0aW9uIGFnYWluc3QgbW9kaWZpY2F0aW9uIG9yIGZhbHNpZmljYXRpb24g YnkgY2xpZW50cy4gVGhlIHNlcnZlciAKPiByZW1lbWJlcnMgdGhlIHZhbHVlIGl0IHNlbmRzIHRv IGNsaWVudHMgYW5kIHZhbGlkYXRlcyB0aGUgdG9rZW4gc2VudCAKPiBiYWNrIGZyb20gYSBjbGll bnQuIEluIGl0cyBkZXNpZ24sIFJldHJ5IHBhY2tldCBpcyB1c2VkIHRvIGRlbGl2ZXIgdGhlIAo+ IHRva2VuIHRvIGEgY2xpZW50IHdoaWNoIGFkZHJlc3MgaGFzIG5vdCB5ZXQgYmVlbiB2YWxpZGF0 ZWQuIEl0IHZvaWRzIAo+IHRoZSBmaXJzdCB0cmFuc21pc3Npb24gb2YgdGhlIEluaXRpYWwgcGFj a2V0IHNlbnQgYnkgdGhlIGNsaWVudCwgYW5kIAo+IHRyaWdnZXJzIGEgc2Vjb25kIEluaXRpYWwg cGFja2V0IHRvIGJlIHNlbnQgd2l0aCB0aGUgdG9rZW4uIFRoZSAKPiBleGNoYW5nZSBvZiB0b2tl biB3aWxsIGNhdXNlIGxvbmdlciBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgZGVsYXkgZm9yIAo+ IGEgY2xpZW50Lgo+IAo+IAo+IFRvIGltcHJvdmUgdGhlIGVmZmljaWVuY3kgb2YgYWRkcmVzcyB2 YWxpZGF0aW9uIGR1cmluZyBoYW5kc2hha2UsIG9uZSAKPiBpZGVhIGlzIHRoYXQgdGhlIHNhbWUg dG9rZW4gY2FuIGJlIGV4Y2hhbmdlZCB2aWEgYSBkaWZmZXJlbnQgY29udGFpbmVyIAo+IGkuZS4g dGhlIEhhbmRzaGFrZSBwYWNrZXQsIHRoYXQgZWxpbWluYXRlcyB0aGUgdXNlIG9mIFJldHJ5IHBh Y2tldCBmb3IgCj4gdG9rZW4gZGVsaXZlcnkuIAo+IAo+IAo+IEkgYW0gd29ya2luZyBvbiB0aGUg Y29tcGxldGUgZHJhZnQgYW5kIHdpbGwgc3VibWl0IGl0IGJ5IEZyaWRheS4gQmVmb3JlIAo+IHRo YXQsIGhvcGUgdGhpcyBjYW4gYmUgZGlzY3Vzc2VkIGluIGVtYWlsIGZpcnN0Lgo+IAo+IAo+IEJS LAo+IAo+IFFpbmcgQW4KPgoK ------=ALIBOUNDARY_80694_4c170940_5dbad9dc_324138 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iX19hbGl5dW5fZW1haWxfYm9keV9ibG9jayI+PGRpdiAgc3R5bGU9ImxpbmUt aGVpZ2h0OjEuNztmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1z aXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48YnIg PjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PGJyID48L2Rpdj48ZGl2ICBzdHlsZT0i Y2xlYXI6Ym90aDsiPlRvIGNsYXJpZnksIHRoZSBwcm9wb3NhbCBpcyBub3QgdG8gcmVwbGFjZSB0 aGUgZXhpc3RpbmcgUmV0cnktYmFzZWQgdmFsaWRhdGlvbiwgYnV0IHRvIHByb3ZpZGUgYW5vdGhl ciBvcHRpb24gZm9yIHNlcnZlciB0byBkbyB0aGUgY2xpZW50IHZhbGlkYXRpb24uPGJyID48L2Rp dj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxiciA+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFy OmJvdGg7Ij5JIHVuZGVyc3RhbmQgdGhhdCBpbiBzZXJ2ZXIgc2lkZSwgZTxzcGFuICBzdHlsZT0i Y29sb3I6IzAwMDAwMDtmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9u dC1zaXplOjE0LjBweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5v cm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtYWxpZ246 c3RhcnQ7dGV4dC1pbmRlbnQ6LjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO2JhY2tncm91bmQtY29s b3I6I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24t Y29sb3I6aW5pdGlhbDtmbG9hdDpub25lO2Rpc3BsYXk6aW5saW5lOyI+eGNoYW5naW5nJm5ic3A7 dGhlJm5ic3A7dG9rZW4mbmJzcDthdCZuYnNwOzwvc3Bhbj48c3BhbiAgc3R5bGU9ImNvbG9yOiMw MDAwMDA7Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZTox NC4wcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0LWFsaWduOnN0YXJ0O3Rl eHQtaW5kZW50Oi4wcHg7dGV4dC10cmFuc2Zvcm06bm9uZTtiYWNrZ3JvdW5kLWNvbG9yOiNmZmZm ZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmlu aXRpYWw7ZmxvYXQ6bm9uZTtkaXNwbGF5OmlubGluZTsiPnRoZSZuYnNwO0hhbmRzaGFrZSZuYnNw O2VuY3J5cHRpb24mbmJzcDtsZXZlbCB3aWxsIG1ha2UgdGhlIHNlcnZlciBzdGFydCB0byBtYWlu dGFpbiBoYW5kc2hha2Ugc3RhdGVzLiBCdXQgaW4gY2xpZW50IHNpZGUsIGl0IGNhbiBhY2NlbGVy YXRlIHRoZSBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgZnJvbSBjbGllbnQgdG8gc2VydmVyLjwv c3Bhbj48L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0iY29sb3I6 IzAwMDAwMDtmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1zaXpl OjE0LjBweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtYWxpZ246c3RhcnQ7 dGV4dC1pbmRlbnQ6LjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO2JhY2tncm91bmQtY29sb3I6I2Zm ZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6 aW5pdGlhbDtmbG9hdDpub25lO2Rpc3BsYXk6aW5saW5lOyI+PGJyID48L3NwYW4+PC9kaXY+PGRp diAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48c3BhbiAgc3R5bGU9ImNvbG9yOiMwMDAwMDA7Zm9udC1m YW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7Zm9udC1z dHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNh cHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4w cHg7dGV4dC10cmFuc2Zvcm06bm9uZTtiYWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNv cmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7ZmxvYXQ6 bm9uZTtkaXNwbGF5OmlubGluZTsiPkFuZCBpdCBpcyB0aGUgc2VydmVyJ3MgZGVjaXNpb24gd2hl dGhlciB0byBleGNoYW5nZSB0b2tlbiBpbiBSZXRyeSBvciBpbiBIYW5kc2hha2UuIElmIHNlcnZl ciBjaG9vc2VzIHRvIGFjY2VwdCB0aGUgY29zdCBicm91Z2h0IGJ5IHRva2VuIGV4Y2hhbmdpbmcg aW4gSGFuZHNoYWtlLCBpdCB3aWxsIGJyaW5nIG1vcmUgZW5oYW5jZWQgZXhwZXJpZW5jZSBpbiBj bGllbnQgc2lkZS48L3NwYW4+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48c3BhbiAg c3R5bGU9ImNvbG9yOiMwMDAwMDA7Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2lt U3VuO2ZvbnQtc2l6ZToxNC4wcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0 dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0 LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7dGV4dC10cmFuc2Zvcm06bm9uZTtiYWNrZ3Jv dW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNv cmF0aW9uLWNvbG9yOmluaXRpYWw7ZmxvYXQ6bm9uZTtkaXNwbGF5OmlubGluZTsiPjxiciA+PC9z cGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJjb2xvcjoj MDAwMDAwO2ZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNpbVN1bjtmb250LXNpemU6 MTQuMHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2Zv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC1hbGlnbjpzdGFydDt0 ZXh0LWluZGVudDouMHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7YmFja2dyb3VuZC1jb2xvcjojZmZm ZmZmO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjpp bml0aWFsO2Zsb2F0Om5vbmU7ZGlzcGxheTppbmxpbmU7Ij48YnIgPjwvc3Bhbj48L2Rpdj48ZGl2 ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0iY29sb3I6IzAwMDAwMDtmb250LWZh bWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtmb250LXN0 eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6LjBw eDt0ZXh0LXRyYW5zZm9ybTpub25lO2JhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt0ZXh0LWRlY29y YXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtmbG9hdDpu b25lO2Rpc3BsYXk6aW5saW5lOyI+QlIsPC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpi b3RoOyI+PHNwYW4gIHN0eWxlPSJjb2xvcjojMDAwMDAwO2ZvbnQtZmFtaWx5OlRhaG9tYSxBcmlh bCxTVEhlaXRpLFNpbVN1bjtmb250LXNpemU6MTQuMHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQt dmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdl aWdodDo0MDA7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDouMHB4O3RleHQtdHJhbnNmb3Jt Om5vbmU7YmFja2dyb3VuZC1jb2xvcjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0 aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO2Zsb2F0Om5vbmU7ZGlzcGxheTppbmxp bmU7Ij5RaW5nPC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PGJyID48L2Rp dj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxiciA+PC9kaXY+PGJsb2NrcXVvdGUgIF9xdW90 ZT0iMSIgc3R5bGU9Im1hcmdpbi1yaWdodDouMHB4O21hcmdpbi10b3A6LjBweDttYXJnaW4tYm90 dG9tOi4wcHg7Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6 ZToxNC4wcHg7Y29sb3I6IzAwMDAwMDsiPjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij5Gcm9tOk1hcnRpbiBUaG9tc29uICZs dDttdEBsb3dlbnRyb3B5Lm5ldCZndDs8L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPlNl bmQgVGltZToyMDE55bm0MTDmnIgzMeaXpSjmmJ/mnJ/lm5spIDA2OjA3PC9kaXY+PGRpdiAgc3R5 bGU9ImNsZWFyOmJvdGg7Ij5UbzpxdWljICZsdDtxdWljQGlldGYub3JnJmd0OzwvZGl2PjxkaXYg IHN0eWxlPSJjbGVhcjpib3RoOyI+U3ViamVjdDpSZTogRmFzdCBBZGRyZXNzIFZhbGlkYXRpb24g LSBhYm91dDwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PGJyID48L2Rpdj5BbHNvJm5i c3A7bm90ZSZuYnNwO3RoYXQmbmJzcDtleGNoYW5nZSZuYnNwO29mJm5ic3A7SGFuZHNoYWtlJm5i c3A7cGFja2V0cyZuYnNwO3Byb3ZpZGVzJm5ic3A7cHJvb2YmbmJzcDtvZiZuYnNwO3JldHVybiZu YnNwO3JvdXRlYWJpbGl0eSZuYnNwO3ZpYSZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7ZW5jcnlwdGlvbiZuYnNwO2tleXMsJm5ic3A7c28mbmJzcDt0aGVyZSZuYnNwO2lz Jm5ic3A7bm8mbmJzcDtuZWVkJm5ic3A7dG8mbmJzcDtleGNoYW5nZSZuYnNwO3Rva2VucyZuYnNw O2F0Jm5ic3A7dGhhdCZuYnNwO2xldmVsLjxiciA+PGJyID5PbiZuYnNwO1RodSwmbmJzcDtPY3Qm bmJzcDszMSwmbmJzcDsyMDE5LCZuYnNwO2F0Jm5ic3A7MDM6MjksJm5ic3A7TWlrZSZuYnNwO0Jp c2hvcCZuYnNwO3dyb3RlOjxiciA+Jmd0OyZuYnNwOyZuYnNwOzxiciA+Jmd0OyZuYnNwO1RoZSZu YnNwO2FkdmFudGFnZSZuYnNwO29mJm5ic3A7dXNpbmcmbmJzcDtSZXRyeSwmbmJzcDtob3dldmVy LCZuYnNwO2lzJm5ic3A7dGhhdCZuYnNwO3RoZSZuYnNwO3NlcnZlciZuYnNwO2lzJm5ic3A7YWJs ZSZuYnNwO3RvJm5ic3A7PGJyID4mZ3Q7Jm5ic3A7a2VlcCZuYnNwO21pbmltYWwmbmJzcDsoaWYm bmJzcDthbnkpJm5ic3A7c3RhdGUmbmJzcDthYm91dCZuYnNwO3RoZSZuYnNwO2NsaWVudC4mbmJz cDtFeGNoYW5naW5nJm5ic3A7dGhlJm5ic3A7dG9rZW4mbmJzcDthdCZuYnNwOzxiciA+Jmd0OyZu YnNwO3RoZSZuYnNwO0hhbmRzaGFrZSZuYnNwO2VuY3J5cHRpb24mbmJzcDtsZXZlbCZuYnNwO21l YW5zJm5ic3A7dGhlJm5ic3A7c2VydmVyJm5ic3A7aXMmbmJzcDthbHJlYWR5Jm5ic3A7ZG9pbmcm bmJzcDt3b3JrJm5ic3A7PGJyID4mZ3Q7Jm5ic3A7YW5kJm5ic3A7bWFpbnRhaW5pbmcmbmJzcDtz dGF0ZSZuYnNwO2luJm5ic3A7b3JkZXImbmJzcDt0byZuYnNwO3Byb2Nlc3MmbmJzcDt0aGUmbmJz cDtoYW5kc2hha2UsJm5ic3A7d2hpY2gmbmJzcDtpcyZuYnNwOzxiciA+Jmd0OyZuYnNwO2V4YWN0 bHkmbmJzcDt3aGF0Jm5ic3A7dGhlJm5ic3A7c2VydmVyJm5ic3A7aXMmbmJzcDt0cnlpbmcmbmJz cDt0byZuYnNwO2F2b2lkLjxiciA+Jmd0OyZuYnNwOzxiciA+Jmd0OyZuYnNwOzxiciA+Jmd0OyZu YnNwOypGcm9tOiombmJzcDtRVUlDJm5ic3A7Jmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsm bmJzcDsqT24mbmJzcDtCZWhhbGYmbmJzcDtPZiZuYnNwOyombmJzcDtRaW5nJm5ic3A7QW48YnIg PiZndDsmbmJzcDsqU2VudDoqJm5ic3A7V2VkbmVzZGF5LCZuYnNwO09jdG9iZXImbmJzcDszMCwm bmJzcDsyMDE5Jm5ic3A7OTo0MSZuYnNwO0FNPGJyID4mZ3Q7Jm5ic3A7KlRvOiombmJzcDtxdWlj Jm5ic3A7Jmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyZuYnNwO2pyaS5pZXRmJm5ic3A7Jmx0O2pyaS5p ZXRmQGdtYWlsLmNvbSZndDs7Jm5ic3A7bXQmbmJzcDs8YnIgPiZndDsmbmJzcDsmbHQ7bXRAbG93 ZW50cm9weS5uZXQmZ3Q7PGJyID4mZ3Q7Jm5ic3A7KkNjOiombmJzcDvliJjlpKfpuY8o6bmP5oiQ KSZuYnNwOyZsdDttYXgubGRwQGFsaWJhYmEtaW5jLmNvbSZndDs8YnIgPiZndDsmbmJzcDsqU3Vi amVjdDoqJm5ic3A7RmFzdCZuYnNwO0FkZHJlc3MmbmJzcDtWYWxpZGF0aW9uJm5ic3A7LSZuYnNw O2Fib3V0PGJyID4mZ3Q7Jm5ic3A7PGJyID4mZ3Q7Jm5ic3A7PGJyID4mZ3Q7Jm5ic3A7PGJyID4m Z3Q7Jm5ic3A7PGJyID4mZ3Q7Jm5ic3A7SGkmbmJzcDtNYXJ0aW4sJm5ic3A7SmFuYSwmbmJzcDs8 YnIgPiZndDsmbmJzcDs8YnIgPiZndDsmbmJzcDtJJm5ic3A7cmVhZCZuYnNwO3Rocm91Z2gmbmJz cDs8YSAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1xdWljLXRyYW5z cG9ydC0yMy50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFm dC1pZXRmLXF1aWMtdHJhbnNwb3J0LTIzLnR4dDwvYT4mbmJzcDs8YnIgPiZndDsmbmJzcDthbmQm bmJzcDtoYXZlJm5ic3A7YSZuYnNwO2ZldyZuYnNwO2NvbW1lbnRzJm5ic3A7YW5kJm5ic3A7aWRl YXMmbmJzcDt0byZuYnNwO2Rpc2N1c3MuPGJyID4mZ3Q7Jm5ic3A7PGJyID4mZ3Q7Jm5ic3A7PGJy ID4mZ3Q7Jm5ic3A7W1FVSUMtVHJhbnNdJm5ic3A7ZGVmaW5lcyZuYnNwO2EmbmJzcDt0b2tlbiZu YnNwO2Jhc2VkJm5ic3A7c2NoZW1lJm5ic3A7dG8mbmJzcDtmYWNpbGl0YXRlJm5ic3A7YWRkcmVz cyZuYnNwOzxiciA+Jmd0OyZuYnNwO3ZhbGlkYXRpb24mbmJzcDtvZiZuYnNwO2EmbmJzcDtjbGll bnQuJm5ic3A7VGhlJm5ic3A7dG9rZW4mbmJzcDtNVVNUJm5ic3A7YmUmbmJzcDtjb3ZlcmVkJm5i c3A7YnkmbmJzcDtpbnRlZ3JpdHkmbmJzcDs8YnIgPiZndDsmbmJzcDtwcm90ZWN0aW9uJm5ic3A7 YWdhaW5zdCZuYnNwO21vZGlmaWNhdGlvbiZuYnNwO29yJm5ic3A7ZmFsc2lmaWNhdGlvbiZuYnNw O2J5Jm5ic3A7Y2xpZW50cy4mbmJzcDtUaGUmbmJzcDtzZXJ2ZXImbmJzcDs8YnIgPiZndDsmbmJz cDtyZW1lbWJlcnMmbmJzcDt0aGUmbmJzcDt2YWx1ZSZuYnNwO2l0Jm5ic3A7c2VuZHMmbmJzcDt0 byZuYnNwO2NsaWVudHMmbmJzcDthbmQmbmJzcDt2YWxpZGF0ZXMmbmJzcDt0aGUmbmJzcDt0b2tl biZuYnNwO3NlbnQmbmJzcDs8YnIgPiZndDsmbmJzcDtiYWNrJm5ic3A7ZnJvbSZuYnNwO2EmbmJz cDtjbGllbnQuJm5ic3A7SW4mbmJzcDtpdHMmbmJzcDtkZXNpZ24sJm5ic3A7UmV0cnkmbmJzcDtw YWNrZXQmbmJzcDtpcyZuYnNwO3VzZWQmbmJzcDt0byZuYnNwO2RlbGl2ZXImbmJzcDt0aGUmbmJz cDs8YnIgPiZndDsmbmJzcDt0b2tlbiZuYnNwO3RvJm5ic3A7YSZuYnNwO2NsaWVudCZuYnNwO3do aWNoJm5ic3A7YWRkcmVzcyZuYnNwO2hhcyZuYnNwO25vdCZuYnNwO3lldCZuYnNwO2JlZW4mbmJz cDt2YWxpZGF0ZWQuJm5ic3A7SXQmbmJzcDt2b2lkcyZuYnNwOzxiciA+Jmd0OyZuYnNwO3RoZSZu YnNwO2ZpcnN0Jm5ic3A7dHJhbnNtaXNzaW9uJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtJbml0aWFs Jm5ic3A7cGFja2V0Jm5ic3A7c2VudCZuYnNwO2J5Jm5ic3A7dGhlJm5ic3A7Y2xpZW50LCZuYnNw O2FuZCZuYnNwOzxiciA+Jmd0OyZuYnNwO3RyaWdnZXJzJm5ic3A7YSZuYnNwO3NlY29uZCZuYnNw O0luaXRpYWwmbmJzcDtwYWNrZXQmbmJzcDt0byZuYnNwO2JlJm5ic3A7c2VudCZuYnNwO3dpdGgm bmJzcDt0aGUmbmJzcDt0b2tlbi4mbmJzcDtUaGUmbmJzcDs8YnIgPiZndDsmbmJzcDtleGNoYW5n ZSZuYnNwO29mJm5ic3A7dG9rZW4mbmJzcDt3aWxsJm5ic3A7Y2F1c2UmbmJzcDtsb25nZXImbmJz cDtjb25uZWN0aW9uJm5ic3A7ZXN0YWJsaXNobWVudCZuYnNwO2RlbGF5Jm5ic3A7Zm9yJm5ic3A7 PGJyID4mZ3Q7Jm5ic3A7YSZuYnNwO2NsaWVudC48YnIgPiZndDsmbmJzcDs8YnIgPiZndDsmbmJz cDs8YnIgPiZndDsmbmJzcDtUbyZuYnNwO2ltcHJvdmUmbmJzcDt0aGUmbmJzcDtlZmZpY2llbmN5 Jm5ic3A7b2YmbmJzcDthZGRyZXNzJm5ic3A7dmFsaWRhdGlvbiZuYnNwO2R1cmluZyZuYnNwO2hh bmRzaGFrZSwmbmJzcDtvbmUmbmJzcDs8YnIgPiZndDsmbmJzcDtpZGVhJm5ic3A7aXMmbmJzcDt0 aGF0Jm5ic3A7dGhlJm5ic3A7c2FtZSZuYnNwO3Rva2VuJm5ic3A7Y2FuJm5ic3A7YmUmbmJzcDtl eGNoYW5nZWQmbmJzcDt2aWEmbmJzcDthJm5ic3A7ZGlmZmVyZW50Jm5ic3A7Y29udGFpbmVyJm5i c3A7PGJyID4mZ3Q7Jm5ic3A7aS5lLiZuYnNwO3RoZSZuYnNwO0hhbmRzaGFrZSZuYnNwO3BhY2tl dCwmbmJzcDt0aGF0Jm5ic3A7ZWxpbWluYXRlcyZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5i c3A7UmV0cnkmbmJzcDtwYWNrZXQmbmJzcDtmb3ImbmJzcDs8YnIgPiZndDsmbmJzcDt0b2tlbiZu YnNwO2RlbGl2ZXJ5LiZuYnNwOzxiciA+Jmd0OyZuYnNwOzxiciA+Jmd0OyZuYnNwOzxiciA+Jmd0 OyZuYnNwO0kmbmJzcDthbSZuYnNwO3dvcmtpbmcmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO2NvbXBs ZXRlJm5ic3A7ZHJhZnQmbmJzcDthbmQmbmJzcDt3aWxsJm5ic3A7c3VibWl0Jm5ic3A7aXQmbmJz cDtieSZuYnNwO0ZyaWRheS4mbmJzcDtCZWZvcmUmbmJzcDs8YnIgPiZndDsmbmJzcDt0aGF0LCZu YnNwO2hvcGUmbmJzcDt0aGlzJm5ic3A7Y2FuJm5ic3A7YmUmbmJzcDtkaXNjdXNzZWQmbmJzcDtp biZuYnNwO2VtYWlsJm5ic3A7Zmlyc3QuPGJyID4mZ3Q7Jm5ic3A7PGJyID4mZ3Q7Jm5ic3A7PGJy ID4mZ3Q7Jm5ic3A7QlIsPGJyID4mZ3Q7Jm5ic3A7PGJyID4mZ3Q7Jm5ic3A7UWluZyZuYnNwO0Fu PGJyID4mZ3Q7PC9ibG9ja3F1b3RlPjxkaXYgIHN0eWxlPSJsaW5lLWhlaWdodDoyMC4wcHg7Y2xl YXI6Ym90aDsiPjxiciA+PC9kaXY+PC9kaXY+PC9kaXY+ ------=ALIBOUNDARY_80694_4c170940_5dbad9dc_324138-- From nobody Thu Oct 31 06:58:23 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230EB120048 for ; Thu, 31 Oct 2019 06:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHPKiyqxeNUq for ; Thu, 31 Oct 2019 06:58:19 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 BA908120044 for ; Thu, 31 Oct 2019 06:58:19 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id s6so5490818iln.0 for ; Thu, 31 Oct 2019 06:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SGs1XoEMy/FxmHz6DjsJ+CzebnlbhYWdsSx2QdSgbEY=; b=MN0Khgy/FcyfRRtQBcuadLdyudL3JR0Us95+OkXniuv24ZYA/ZavvvhLUZhWW9dcKF qB9k6w0gmGSUp2TOEL9QJbQvMV12atekzXHAYHowLjyyWehuhYWTJ06OupAYFBxsb24W 9aeUIfKbqy7JZOgnl/u3cBAoHbZPQZc8mn9EcM7yeVAnESjRyQSZlEcFfMom5U5fRxzr NFByje58NSNd12iOATLmQRKfE3N5vZYEJBwWl4eEIHpgeHr4BZeFS9a+AwsP/MmizFag 7CXQo/eC6W3ekyFHSzVGsJx2GJFMvTolH6D2p+iF5F99c3tfSATqS7cIy7jt4aOthLsb MvpQ== 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=SGs1XoEMy/FxmHz6DjsJ+CzebnlbhYWdsSx2QdSgbEY=; b=EFs9JS9AUW78GVLARxqf91Nw21pMfWAEfNgvVsAmmmn/qKQoML7B+gqhoVzrNIowPq r6Q0N5TCP+xZA1J8O7IjaoAvpmeQIy0WUs/Xy3fE6cHmcHHPI5d+yTzUH5U12EhVWLMO jhxw6JhigCjU7X55sLh1zPeG8+/Rz8ve25PjRLxcGbhCi6iqZ6r+/nXsFES+eSdBF1a8 cKk+1t/z6lKMgrYZajEZLSIXl+kfj3/TzMbfLAgFWuy2O3zV45kO9zB8QH7Ed73WvVt8 qXnYXoRn5pgbOcUP/Cvny5/XVRB+SES40Ge5E7YqpFW06hMACnmcSwOLJDXfFj0pFHOX HPzg== X-Gm-Message-State: APjAAAXttY4vOWIBfR9eKYoe2bsw98+z7MCScax5noIM9jH47CmDUN0+ 3TKenwyEVoVIhPmvGdfzlbT1YPMuVLOjnrcW+7AKjQ== X-Google-Smtp-Source: APXvYqxOdjfrWGdQ8eyHdYNSLdc+GU1rOcJ8KKIhg2vPp8mPwPPPa3hv2kmIlZshFZ8zaDOYpWTshdiOL9r1LyvYsLE= X-Received: by 2002:a05:6e02:cc1:: with SMTP id c1mr3047958ilj.139.1572530298817; Thu, 31 Oct 2019 06:58:18 -0700 (PDT) MIME-Version: 1.0 References: <3218A80B-DAFD-43EF-8200-F99C660DF9C9@mnot.net> <5557f717-ae03-46a2-aa9f-54f019a07533@www.fastmail.com> In-Reply-To: <5557f717-ae03-46a2-aa9f-54f019a07533@www.fastmail.com> From: Ted Hardie Date: Thu, 31 Oct 2019 06:58:06 -0700 Message-ID: Subject: Re: Proposed response to the 3GPP Liaison Statement To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000dc18e70596353dec" 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, 31 Oct 2019 13:58:22 -0000 --000000000000dc18e70596353dec Content-Type: text/plain; charset="UTF-8" On Wed, Oct 30, 2019 at 6:14 PM Martin Thomson wrote: > https://tools.ietf.org/html/draft-iab-path-signals-03 seems like it might > be a helpful supporting document. > > If you do choose to cite it, it has been published as RFC 8558, so it would be best to use that. Ted > On Thu, Oct 31, 2019, at 12:09, Mark Nottingham wrote: > > QUIC WG participants, > > > > Lars and I have discussed a response to this statement and plan on > > sending the message below. If you have comments, please respond to this > > e-mail by 6 November. > > > > Regards, > > > > ~~~ > > Thank you for your input to our specifications. > > > > Regarding the encryption of headers in addition to payload, this was a > > conscious design decision by the Working Group. Transport header > > encryption prevents modification by middleboxes, thereby avoiding > > ossification of the protocol, and also makes traffic analysis more > > difficult. The impact upon network operators was discussed extensively > > as part of that decision. > > > > Regarding the spin bit, we believe that your characterisation is correct. > > > > Regarding packet loss measurements, QUIC does support them, but only by > > the endpoints of communication -- not by third parties observing it. > > Keys may be exported by one of the endpoints to allow decoding of > > packet traces (e.g., with Wireshark), but that is not part of the QUIC > > standard. > > > > Regarding performance analysis, it would be helpful if you described > > your use case in more detail. However, it's important to know that the > > Working Group decided early on that QUICv1 would focus on the use case > > of HTTP/3. > > > > In turn, HTTP standardisation focuses primarily on the Web browsing use > > case; while we acknowledge that there are other uses of the protocol, > > and we accommodate them where possible, we cannot change the protocol > > in ways that harms that use. Exposing transport metadata would likely > > do so. > > > > Kind regards, > > > > Mark Nottingham and Lars Eggert, QUIC Working Group chairs > > ~~~ > > > > > > --000000000000dc18e70596353dec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 30, 2019 at 6:14 PM Martin Th= omson <mt@lowentropy.net> wr= ote:
https://tools.ietf.org/html/dra= ft-iab-path-signals-03 seems like it might be a helpful supporting docu= ment.

If you do choose to cite it, it has been published as= RFC 8558, so it would be best to use that.

Ted

=C2=A0
On Thu, Oct 31, 2019, at 12:09, Mark Nottingham wrote:
> QUIC WG participants,
>
> Lars and I have discussed a response to this statement and plan on > sending the message below. If you have comments, please respond to thi= s
> e-mail by 6 November.
>
> Regards,
>
> ~~~
> Thank you for your input to our specifications.
>
> Regarding the encryption of headers in addition to payload, this was a=
> conscious design decision by the Working Group. Transport header
> encryption prevents modification by middleboxes, thereby avoiding
> ossification of the protocol, and also makes traffic analysis more > difficult. The impact upon network operators was discussed extensively=
> as part of that decision.
>
> Regarding the spin bit, we believe that your characterisation is corre= ct.
>
> Regarding packet loss measurements, QUIC does support them, but only b= y
> the endpoints of communication -- not by third parties observing it. <= br> > Keys may be exported by one of the endpoints to allow decoding of
> packet traces (e.g., with Wireshark), but that is not part of the QUIC=
> standard.
>
> Regarding performance analysis, it would be helpful if you described <= br> > your use case in more detail. However, it's important to know that= the
> Working Group decided early on that QUICv1 would focus on the use case=
> of HTTP/3.
>
> In turn, HTTP standardisation focuses primarily on the Web browsing us= e
> case; while we acknowledge that there are other uses of the protocol, =
> and we accommodate them where possible, we cannot change the protocol =
> in ways that harms that use. Exposing transport metadata would likely =
> do so.
>
> Kind regards,
>
> Mark Nottingham and Lars Eggert, QUIC Working Group chairs
> ~~~
>
>

--000000000000dc18e70596353dec-- From nobody Thu Oct 31 09:05:34 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CD312097D for ; Thu, 31 Oct 2019 09:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=ham 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 3ojHtpwhMl46 for ; Thu, 31 Oct 2019 09:05:25 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700098.outbound.protection.outlook.com [40.107.70.98]) (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 46F12120A27 for ; Thu, 31 Oct 2019 09:05:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j49G4hV2BsX78PC5xsD3ERogt38YhHVHNZTH+TNaO8cswufBFTmnieFvXNYo2naodRvc/vqwqz9kdEi7oiEQDugUC55uVbuMJtcQgHozWzOQGrI1vxqe4kKLSP1nlkMt1VwSJnYeQ1TDdtjy80nBuNb1AQe5jv6uxsWSX15H8Z6ZCeDCHouwWHkQOvTBzekhY5W/AAV28YGDHOWxk7OdNbn8utGZ9xLDPC3a3WSqheIE84sBmBSAGC/LSPrnArIBtw0+ioy7HRsFJ7CtLLqqW6lZwN1Ocwlmng1wzLNiGg0l9u9vtQm0UbzXvjoHNQzFpgGLgzqgoM23xNvVyNbr9Q== 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=buxKVCE2kuTY0Q3aLihdyeCWVheiRPobPZIaHC9TLsA=; b=C5KN6prRkWeGxVKF9Nldg7lrRsoooJg49EGNdFqhkIKYet4bFNMFYq4XC+rIlmYKBIoisGTHDjAs2UrT/JQdhEeqsB++FKkcTJ99Hn9QrjT3zMYdzJFeieh5q/3nar6AaB0LkjyIA9nMOCXNyPNDQsKrXEYTL1ULbIUbGgqh2EHSc1KHkObg86T9v6mPIcEeyuZ4UjjebiYEVKIisyv6SczXDrCFTULuInAwIwaWGUnoveoLiq+xEkhL3h7+HgFCJ9Bjin/ZSTO5GtqsDuJPSeU4PvwOhng+01BhvsHWKRThP1R1FYp+CAkdrcYow7sB63JPVfkTAc9CTBAvXLvFzQ== 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=buxKVCE2kuTY0Q3aLihdyeCWVheiRPobPZIaHC9TLsA=; b=DpWqnmsAn3txfUzb94vcyqNUTlDahgcSC37gniKF8baRXWh7EEfpSBISFbZhnQ6pEy2Gepq3MGDQ/v+xTVZ0JR5NnelGsL9HpFsgj6DtaizYXKIiPWkkZsn6BB/aAXP7VOzbkxIu6YUaLMrKRAJ6ltzJ8PmBygRqlmEUF2VXF6Y= Received: from BN6PR2201MB1700.namprd22.prod.outlook.com (10.161.152.144) by BN6PR2201MB1459.namprd22.prod.outlook.com (10.174.88.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.24; Thu, 31 Oct 2019 16:05:17 +0000 Received: from BN6PR2201MB1700.namprd22.prod.outlook.com ([fe80::7cb4:5e4e:334c:a737]) by BN6PR2201MB1700.namprd22.prod.outlook.com ([fe80::7cb4:5e4e:334c:a737%7]) with mapi id 15.20.2387.028; Thu, 31 Oct 2019 16:05:17 +0000 From: Mike Bishop To: Qing An , quic , jri.ietf , mt , mikkelfj Subject: RE: Fast Address Validation - about Thread-Topic: Fast Address Validation - about Thread-Index: AQHVjye9CowM5E5v+kqJ9Ajt0q5CdadzX6PAgABe2ICAAPhHAIAANIug Date: Thu, 31 Oct 2019 16:05:16 +0000 Message-ID: References: <4974ed86-0fa9-435d-880f-80af637ef180.anqing.aq@alibaba-inc.com> , 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: [2600:2b00:931f:a301:d09f:75d0:3565:b179] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4ba7fbd3-d8be-42bf-3f1b-08d75e1c1f2c x-ms-traffictypediagnostic: BN6PR2201MB1459: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(376002)(346002)(396003)(366004)(136003)(199004)(189003)(966005)(66946007)(76116006)(99286004)(64756008)(66446008)(14454004)(66476007)(66556008)(8936002)(14444005)(25786009)(256004)(7736002)(74316002)(508600001)(8676002)(606006)(81156014)(81166006)(2906002)(790700001)(6116002)(71190400001)(71200400001)(561944003)(6436002)(229853002)(33656002)(6246003)(6306002)(54896002)(9686003)(236005)(55016002)(6506007)(53546011)(46003)(186003)(102836004)(11346002)(446003)(476003)(110136005)(7696005)(52536014)(76176011)(86362001)(486006)(316002)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR2201MB1459; H:BN6PR2201MB1700.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: PXf1qcwoSOsoBbuhSIk9KmqI0xuVm1CSqS93e96XSSK5Sg6dYAhahO3cqcu7xE2lUPbQyfnrEttrT471OISwm/epuVjGydGqexpsLT2gLQ5yqKUotECYPBCZK8+/DFQgInT65jQL3m6Z/MSdgsD9vfPTam+mWsyEvFsTaF8i9C/PvjtJ1SB9cpV3RzdhgeYd2/8moXEQ9NfbXMdoLE4n1hQTX6QbAdx2fhPk8M47LMj/aXmrN2i9mR2+DBQ54WX1f+waMvCa/cooh4g0VEsAKPhP2B3/Su/YB302Hjowa5y7fJ38mohuNgx2XyVelO8qjop5Y2ghIrgm2lRJJB8wDH78lKiemRXBh12+zfgWEsi3DZ4+JUUoMcRDmw1a7NG0az+2EhhSstde38tnwTHx+SwhF7IHBF7AnP3fKzIUMR48RovyG62ZAUnPr3vb+UHNaoyPO0GbDFpp9sReFSt4jvNcDm/fgNFc91aan0w14AI= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR2201MB17005571E88F1C68769091A3DA630BN6PR2201MB1700_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 4ba7fbd3-d8be-42bf-3f1b-08d75e1c1f2c X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 16:05:16.8944 (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: 5QyMk1yZcV/aKpsjz6liwYIBhSOzBLFXgH+u7VMqxt+JM96B+OUFoPAybzoI0fkLcBY/dAzE+ZY2qsl/uQl3HA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1459 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, 31 Oct 2019 16:05:32 -0000 --_000_BN6PR2201MB17005571E88F1C68769091A3DA630BN6PR2201MB1700_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgTWFydGluIHBvaW50ZWQgb3V0IGluIHRoZSBlLW1haWwgeW91IHJlcGxpZWQgdG8sIGlmIHRo ZSBzZXJ2ZXIgaXMgd2lsbGluZyB0byBtYWludGFpbiBzdGF0ZSwgYW55IHBhY2tldCBhdCB0aGUg SGFuZHNoYWtlIGVuY3J5cHRpb24gbGF5ZXIgcHJvdmVzIHJldHVybiByb3V0YWJpbGl0eS4gIFRo ZXJlIHNlZW1zIHRvIGJlIG5vIG5lZWQgZm9yIGEgc2VwYXJhdGUgYWRkcmVzcyB2YWxpZGF0aW9u IG1lY2hhbmlzbSBpZiB0aGUgc2VydmVyIGlzIHdpbGxpbmcgdG8gcHJvY2VlZCB3aXRoIHRoZSBo YW5kc2hha2UuDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm IE9mIFFpbmcgQW4NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDMxLCAyMDE5IDg6NTYgQU0NClRv OiBxdWljIDxxdWljQGlldGYub3JnPjsganJpLmlldGYgPGpyaS5pZXRmQGdtYWlsLmNvbT47IG10 IDxtdEBsb3dlbnRyb3B5Lm5ldD47IG1pa2tlbGZqIDxtaWtrZWxmakBnbWFpbC5jb20+DQpTdWJq ZWN0OiBSZTogRmFzdCBBZGRyZXNzIFZhbGlkYXRpb24gLSBhYm91dA0KDQoNCg0KVG8gY2xhcmlm eSwgdGhlIHByb3Bvc2FsIGlzIG5vdCB0byByZXBsYWNlIHRoZSBleGlzdGluZyBSZXRyeS1iYXNl ZCB2YWxpZGF0aW9uLCBidXQgdG8gcHJvdmlkZSBhbm90aGVyIG9wdGlvbiBmb3Igc2VydmVyIHRv IGRvIHRoZSBjbGllbnQgdmFsaWRhdGlvbi4NCg0KSSB1bmRlcnN0YW5kIHRoYXQgaW4gc2VydmVy IHNpZGUsIGV4Y2hhbmdpbmcgdGhlIHRva2VuIGF0IHRoZSBIYW5kc2hha2UgZW5jcnlwdGlvbiBs ZXZlbCB3aWxsIG1ha2UgdGhlIHNlcnZlciBzdGFydCB0byBtYWludGFpbiBoYW5kc2hha2Ugc3Rh dGVzLiBCdXQgaW4gY2xpZW50IHNpZGUsIGl0IGNhbiBhY2NlbGVyYXRlIHRoZSBjb25uZWN0aW9u IGVzdGFibGlzaG1lbnQgZnJvbSBjbGllbnQgdG8gc2VydmVyLg0KDQpBbmQgaXQgaXMgdGhlIHNl cnZlcidzIGRlY2lzaW9uIHdoZXRoZXIgdG8gZXhjaGFuZ2UgdG9rZW4gaW4gUmV0cnkgb3IgaW4g SGFuZHNoYWtlLiBJZiBzZXJ2ZXIgY2hvb3NlcyB0byBhY2NlcHQgdGhlIGNvc3QgYnJvdWdodCBi eSB0b2tlbiBleGNoYW5naW5nIGluIEhhbmRzaGFrZSwgaXQgd2lsbCBicmluZyBtb3JlIGVuaGFu Y2VkIGV4cGVyaWVuY2UgaW4gY2xpZW50IHNpZGUuDQoNCg0KQlIsDQpRaW5nDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpGcm9tOk1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldDxtYWlsdG86bXRAbG93 ZW50cm9weS5uZXQ+Pg0KU2VuZCBUaW1lOjIwMTnlubQxMOaciDMx5pelKOaYn+acn+WbmykgMDY6 MDcNClRvOnF1aWMgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVj dDpSZTogRmFzdCBBZGRyZXNzIFZhbGlkYXRpb24gLSBhYm91dA0KDQpBbHNvIG5vdGUgdGhhdCBl eGNoYW5nZSBvZiBIYW5kc2hha2UgcGFja2V0cyBwcm92aWRlcyBwcm9vZiBvZiByZXR1cm4gcm91 dGVhYmlsaXR5IHZpYSB0aGUgdXNlIG9mIHRoZSBlbmNyeXB0aW9uIGtleXMsIHNvIHRoZXJlIGlz IG5vIG5lZWQgdG8gZXhjaGFuZ2UgdG9rZW5zIGF0IHRoYXQgbGV2ZWwuDQoNCk9uIFRodSwgT2N0 IDMxLCAyMDE5LCBhdCAwMzoyOSwgTWlrZSBCaXNob3Agd3JvdGU6DQo+DQo+IFRoZSBhZHZhbnRh Z2Ugb2YgdXNpbmcgUmV0cnksIGhvd2V2ZXIsIGlzIHRoYXQgdGhlIHNlcnZlciBpcyBhYmxlIHRv DQo+IGtlZXAgbWluaW1hbCAoaWYgYW55KSBzdGF0ZSBhYm91dCB0aGUgY2xpZW50LiBFeGNoYW5n aW5nIHRoZSB0b2tlbiBhdA0KPiB0aGUgSGFuZHNoYWtlIGVuY3J5cHRpb24gbGV2ZWwgbWVhbnMg dGhlIHNlcnZlciBpcyBhbHJlYWR5IGRvaW5nIHdvcmsNCj4gYW5kIG1haW50YWluaW5nIHN0YXRl IGluIG9yZGVyIHRvIHByb2Nlc3MgdGhlIGhhbmRzaGFrZSwgd2hpY2ggaXMNCj4gZXhhY3RseSB3 aGF0IHRoZSBzZXJ2ZXIgaXMgdHJ5aW5nIHRvIGF2b2lkLg0KPg0KPg0KPiAqRnJvbToqIFFVSUMg PHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPj4gKk9u IEJlaGFsZiBPZiAqIFFpbmcgQW4NCj4gKlNlbnQ6KiBXZWRuZXNkYXksIE9jdG9iZXIgMzAsIDIw MTkgOTo0MSBBTQ0KPiAqVG86KiBxdWljIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYu b3JnPj47IGpyaS5pZXRmIDxqcmkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmpyaS5pZXRmQGdtYWls LmNvbT4+OyBtdA0KPiA8bXRAbG93ZW50cm9weS5uZXQ8bWFpbHRvOm10QGxvd2VudHJvcHkubmV0 Pj4NCj4gKkNjOiog5YiY5aSn6bmPKOm5j+aIkCkgPG1heC5sZHBAYWxpYmFiYS1pbmMuY29tPG1h aWx0bzptYXgubGRwQGFsaWJhYmEtaW5jLmNvbT4+DQo+ICpTdWJqZWN0OiogRmFzdCBBZGRyZXNz IFZhbGlkYXRpb24gLSBhYm91dA0KPg0KPg0KPg0KPg0KPiBIaSBNYXJ0aW4sIEphbmEsDQo+DQo+ IEkgcmVhZCB0aHJvdWdoIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtcXVpYy10 cmFuc3BvcnQtMjMudHh0DQo+IGFuZCBoYXZlIGEgZmV3IGNvbW1lbnRzIGFuZCBpZGVhcyB0byBk aXNjdXNzLg0KPg0KPg0KPiBbUVVJQy1UcmFuc10gZGVmaW5lcyBhIHRva2VuIGJhc2VkIHNjaGVt ZSB0byBmYWNpbGl0YXRlIGFkZHJlc3MNCj4gdmFsaWRhdGlvbiBvZiBhIGNsaWVudC4gVGhlIHRv a2VuIE1VU1QgYmUgY292ZXJlZCBieSBpbnRlZ3JpdHkNCj4gcHJvdGVjdGlvbiBhZ2FpbnN0IG1v ZGlmaWNhdGlvbiBvciBmYWxzaWZpY2F0aW9uIGJ5IGNsaWVudHMuIFRoZSBzZXJ2ZXINCj4gcmVt ZW1iZXJzIHRoZSB2YWx1ZSBpdCBzZW5kcyB0byBjbGllbnRzIGFuZCB2YWxpZGF0ZXMgdGhlIHRv a2VuIHNlbnQNCj4gYmFjayBmcm9tIGEgY2xpZW50LiBJbiBpdHMgZGVzaWduLCBSZXRyeSBwYWNr ZXQgaXMgdXNlZCB0byBkZWxpdmVyIHRoZQ0KPiB0b2tlbiB0byBhIGNsaWVudCB3aGljaCBhZGRy ZXNzIGhhcyBub3QgeWV0IGJlZW4gdmFsaWRhdGVkLiBJdCB2b2lkcw0KPiB0aGUgZmlyc3QgdHJh bnNtaXNzaW9uIG9mIHRoZSBJbml0aWFsIHBhY2tldCBzZW50IGJ5IHRoZSBjbGllbnQsIGFuZA0K PiB0cmlnZ2VycyBhIHNlY29uZCBJbml0aWFsIHBhY2tldCB0byBiZSBzZW50IHdpdGggdGhlIHRv a2VuLiBUaGUNCj4gZXhjaGFuZ2Ugb2YgdG9rZW4gd2lsbCBjYXVzZSBsb25nZXIgY29ubmVjdGlv biBlc3RhYmxpc2htZW50IGRlbGF5IGZvcg0KPiBhIGNsaWVudC4NCj4NCj4NCj4gVG8gaW1wcm92 ZSB0aGUgZWZmaWNpZW5jeSBvZiBhZGRyZXNzIHZhbGlkYXRpb24gZHVyaW5nIGhhbmRzaGFrZSwg b25lDQo+IGlkZWEgaXMgdGhhdCB0aGUgc2FtZSB0b2tlbiBjYW4gYmUgZXhjaGFuZ2VkIHZpYSBh IGRpZmZlcmVudCBjb250YWluZXINCj4gaS5lLiB0aGUgSGFuZHNoYWtlIHBhY2tldCwgdGhhdCBl bGltaW5hdGVzIHRoZSB1c2Ugb2YgUmV0cnkgcGFja2V0IGZvcg0KPiB0b2tlbiBkZWxpdmVyeS4N Cj4NCj4NCj4gSSBhbSB3b3JraW5nIG9uIHRoZSBjb21wbGV0ZSBkcmFmdCBhbmQgd2lsbCBzdWJt aXQgaXQgYnkgRnJpZGF5LiBCZWZvcmUNCj4gdGhhdCwgaG9wZSB0aGlzIGNhbiBiZSBkaXNjdXNz ZWQgaW4gZW1haWwgZmlyc3QuDQo+DQo+DQo+IEJSLA0KPg0KPiBRaW5nIEFuDQo+DQoNCg== --_000_BN6PR2201MB17005571E88F1C68769091A3DA630BN6PR2201MB1700_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJNaWNyb3NvZnQgSmhlbmdIZWkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWljcm9zb2Z0IEpoZW5nSGVpIjt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2 IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BcyBNYXJ0aW4gcG9pbnRlZCBvdXQgaW4gdGhlIGUtbWFpbCB5b3UgcmVwbGll ZCB0bywgaWYgdGhlIHNlcnZlciBpcyB3aWxsaW5nIHRvIG1haW50YWluIHN0YXRlLCBhbnkgcGFj a2V0IGF0IHRoZSBIYW5kc2hha2UgZW5jcnlwdGlvbiBsYXllciBwcm92ZXMgcmV0dXJuIHJvdXRh YmlsaXR5LiZuYnNwOyBUaGVyZSBzZWVtcyB0byBiZSBubyBuZWVkIGZvciBhIHNlcGFyYXRlIGFk ZHJlc3MgdmFsaWRhdGlvbiBtZWNoYW5pc20NCiBpZiB0aGUgc2VydmVyIGlzIHdpbGxpbmcgdG8g cHJvY2VlZCB3aXRoIHRoZSBoYW5kc2hha2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBRVUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBP ZiA8L2I+DQpRaW5nIEFuPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3RvYmVyIDMxLCAy MDE5IDg6NTYgQU08YnI+DQo8Yj5Ubzo8L2I+IHF1aWMgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBq cmkuaWV0ZiAmbHQ7anJpLmlldGZAZ21haWwuY29tJmd0OzsgbXQgJmx0O210QGxvd2VudHJvcHku bmV0Jmd0OzsgbWlra2VsZmogJmx0O21pa2tlbGZqQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IEZhc3QgQWRkcmVzcyBWYWxpZGF0aW9uIC0gYWJvdXQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+VG8gY2xhcmlmeSwgdGhlIHByb3Bvc2FsIGlzIG5vdCB0byBy ZXBsYWNlIHRoZSBleGlzdGluZyBSZXRyeS1iYXNlZCB2YWxpZGF0aW9uLCBidXQgdG8gcHJvdmlk ZSBhbm90aGVyIG9wdGlvbiBmb3Igc2VydmVyIHRvIGRvIHRoZSBjbGllbnQgdmFsaWRhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkkgdW5kZXJzdGFuZCB0aGF0IGluIHNlcnZlciBzaWRlLCBlPHNwYW4gc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPnhjaGFuZ2luZyZuYnNwO3RoZSZuYnNwO3Rva2VuJm5ic3A7YXQm bmJzcDt0aGUmbmJzcDtIYW5kc2hha2UmbmJzcDtlbmNyeXB0aW9uJm5ic3A7bGV2ZWwgd2lsbCBt YWtlIHRoZSBzZXJ2ZXIgc3RhcnQgdG8gbWFpbnRhaW4gaGFuZHNoYWtlDQogc3RhdGVzLiBCdXQg aW4gY2xpZW50IHNpZGUsIGl0IGNhbiBhY2NlbGVyYXRlIHRoZSBjb25uZWN0aW9uIGVzdGFibGlz aG1lbnQgZnJvbSBjbGllbnQgdG8gc2VydmVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3 aGl0ZSI+QW5kIGl0IGlzIHRoZSBzZXJ2ZXIncyBkZWNpc2lvbiB3aGV0aGVyIHRvIGV4Y2hhbmdl IHRva2VuIGluIFJldHJ5IG9yIGluIEhhbmRzaGFrZS4gSWYgc2VydmVyIGNob29zZXMgdG8gYWNj ZXB0IHRoZSBjb3N0IGJyb3VnaHQgYnkgdG9rZW4gZXhjaGFuZ2luZw0KIGluIEhhbmRzaGFrZSwg aXQgd2lsbCBicmluZyBtb3JlIGVuaGFuY2VkIGV4cGVyaWVuY2UgaW4gY2xpZW50IHNpZGUuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPkJSLDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7YmFja2dy b3VuZDp3aGl0ZSI+UWluZzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPkZyb206TWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptdEBsb3dlbnRy b3B5Lm5ldCI+bXRAbG93ZW50cm9weS5uZXQ8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5TZW5kIFRpbWU6MjAxOTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuW5tDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MTA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNr Ij7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjMxPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztj b2xvcjpibGFjayI+5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4oPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhp YyZxdW90Oztjb2xvcjpibGFjayI+5pif5pyf5ZubPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4pDQogMDY6MDc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VG86cXVpYyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TdWJqZWN0OlJlOiBGYXN0IEFkZHJlc3MgVmFs aWRhdGlvbiAtIGFib3V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkFsc28mbmJzcDtub3RlJm5ic3A7dGhhdCZuYnNwO2V4Y2hhbmdl Jm5ic3A7b2YmbmJzcDtIYW5kc2hha2UmbmJzcDtwYWNrZXRzJm5ic3A7cHJvdmlkZXMmbmJzcDtw cm9vZiZuYnNwO29mJm5ic3A7cmV0dXJuJm5ic3A7cm91dGVhYmlsaXR5Jm5ic3A7dmlhJm5ic3A7 dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtlbmNyeXB0aW9uJm5ic3A7a2V5cywm bmJzcDtzbyZuYnNwO3RoZXJlJm5ic3A7aXMmbmJzcDtubyZuYnNwO25lZWQmbmJzcDt0byZuYnNw O2V4Y2hhbmdlJm5ic3A7dG9rZW5zJm5ic3A7YXQmbmJzcDt0aGF0Jm5ic3A7bGV2ZWwuPGJyPg0K PGJyPg0KT24mbmJzcDtUaHUsJm5ic3A7T2N0Jm5ic3A7MzEsJm5ic3A7MjAxOSwmbmJzcDthdCZu YnNwOzAzOjI5LCZuYnNwO01pa2UmbmJzcDtCaXNob3AmbmJzcDt3cm90ZTo8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7PGJyPg0KJmd0OyZuYnNwO1RoZSZuYnNwO2FkdmFudGFnZSZuYnNwO29mJm5ic3A7 dXNpbmcmbmJzcDtSZXRyeSwmbmJzcDtob3dldmVyLCZuYnNwO2lzJm5ic3A7dGhhdCZuYnNwO3Ro ZSZuYnNwO3NlcnZlciZuYnNwO2lzJm5ic3A7YWJsZSZuYnNwO3RvJm5ic3A7PGJyPg0KJmd0OyZu YnNwO2tlZXAmbmJzcDttaW5pbWFsJm5ic3A7KGlmJm5ic3A7YW55KSZuYnNwO3N0YXRlJm5ic3A7 YWJvdXQmbmJzcDt0aGUmbmJzcDtjbGllbnQuJm5ic3A7RXhjaGFuZ2luZyZuYnNwO3RoZSZuYnNw O3Rva2VuJm5ic3A7YXQmbmJzcDs8YnI+DQomZ3Q7Jm5ic3A7dGhlJm5ic3A7SGFuZHNoYWtlJm5i c3A7ZW5jcnlwdGlvbiZuYnNwO2xldmVsJm5ic3A7bWVhbnMmbmJzcDt0aGUmbmJzcDtzZXJ2ZXIm bmJzcDtpcyZuYnNwO2FscmVhZHkmbmJzcDtkb2luZyZuYnNwO3dvcmsmbmJzcDs8YnI+DQomZ3Q7 Jm5ic3A7YW5kJm5ic3A7bWFpbnRhaW5pbmcmbmJzcDtzdGF0ZSZuYnNwO2luJm5ic3A7b3JkZXIm bmJzcDt0byZuYnNwO3Byb2Nlc3MmbmJzcDt0aGUmbmJzcDtoYW5kc2hha2UsJm5ic3A7d2hpY2gm bmJzcDtpcyZuYnNwOzxicj4NCiZndDsmbmJzcDtleGFjdGx5Jm5ic3A7d2hhdCZuYnNwO3RoZSZu YnNwO3NlcnZlciZuYnNwO2lzJm5ic3A7dHJ5aW5nJm5ic3A7dG8mbmJzcDthdm9pZC48YnI+DQom Z3Q7Jm5ic3A7PGJyPg0KJmd0OyZuYnNwOzxicj4NCiZndDsmbmJzcDsqRnJvbToqJm5ic3A7UVVJ QyZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5xdWljLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyZuYnNwOypPbiZuYnNwO0JlaGFsZiZuYnNwO09mJm5ic3A7 KiZuYnNwO1FpbmcmbmJzcDtBbjxicj4NCiZndDsmbmJzcDsqU2VudDoqJm5ic3A7V2VkbmVzZGF5 LCZuYnNwO09jdG9iZXImbmJzcDszMCwmbmJzcDsyMDE5Jm5ic3A7OTo0MSZuYnNwO0FNPGJyPg0K Jmd0OyZuYnNwOypUbzoqJm5ic3A7cXVpYyZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0Bp ZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7OyZuYnNwO2pyaS5pZXRmJm5ic3A7Jmx0Ozxh IGhyZWY9Im1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20iPmpyaS5pZXRmQGdtYWlsLmNvbTwvYT4m Z3Q7OyZuYnNwO210Jm5ic3A7PGJyPg0KJmd0OyZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86bXRA bG93ZW50cm9weS5uZXQiPm10QGxvd2VudHJvcHkubmV0PC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7 KkNjOiombmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7liJjlpKc8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IEpoZW5n SGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPum5jzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+KDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgSmhlbmdIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+6bmP5oiQPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4pJm5ic3A7Jmx0 OzxhIGhyZWY9Im1haWx0bzptYXgubGRwQGFsaWJhYmEtaW5jLmNvbSI+bWF4LmxkcEBhbGliYWJh LWluYy5jb208L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsqU3ViamVjdDoqJm5ic3A7RmFzdCZuYnNw O0FkZHJlc3MmbmJzcDtWYWxpZGF0aW9uJm5ic3A7LSZuYnNwO2Fib3V0PGJyPg0KJmd0OyZuYnNw Ozxicj4NCiZndDsmbmJzcDs8YnI+DQomZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZuYnNwOzxicj4NCiZn dDsmbmJzcDtIaSZuYnNwO01hcnRpbiwmbmJzcDtKYW5hLCZuYnNwOzxicj4NCiZndDsmbmJzcDs8 YnI+DQomZ3Q7Jm5ic3A7SSZuYnNwO3JlYWQmbmJzcDt0aHJvdWdoJm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yMy50eHQiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXF1aWMtdHJh bnNwb3J0LTIzLnR4dDwvYT4mbmJzcDs8YnI+DQomZ3Q7Jm5ic3A7YW5kJm5ic3A7aGF2ZSZuYnNw O2EmbmJzcDtmZXcmbmJzcDtjb21tZW50cyZuYnNwO2FuZCZuYnNwO2lkZWFzJm5ic3A7dG8mbmJz cDtkaXNjdXNzLjxicj4NCiZndDsmbmJzcDs8YnI+DQomZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZuYnNw O1tRVUlDLVRyYW5zXSZuYnNwO2RlZmluZXMmbmJzcDthJm5ic3A7dG9rZW4mbmJzcDtiYXNlZCZu YnNwO3NjaGVtZSZuYnNwO3RvJm5ic3A7ZmFjaWxpdGF0ZSZuYnNwO2FkZHJlc3MmbmJzcDs8YnI+ DQomZ3Q7Jm5ic3A7dmFsaWRhdGlvbiZuYnNwO29mJm5ic3A7YSZuYnNwO2NsaWVudC4mbmJzcDtU aGUmbmJzcDt0b2tlbiZuYnNwO01VU1QmbmJzcDtiZSZuYnNwO2NvdmVyZWQmbmJzcDtieSZuYnNw O2ludGVncml0eSZuYnNwOzxicj4NCiZndDsmbmJzcDtwcm90ZWN0aW9uJm5ic3A7YWdhaW5zdCZu YnNwO21vZGlmaWNhdGlvbiZuYnNwO29yJm5ic3A7ZmFsc2lmaWNhdGlvbiZuYnNwO2J5Jm5ic3A7 Y2xpZW50cy4mbmJzcDtUaGUmbmJzcDtzZXJ2ZXImbmJzcDs8YnI+DQomZ3Q7Jm5ic3A7cmVtZW1i ZXJzJm5ic3A7dGhlJm5ic3A7dmFsdWUmbmJzcDtpdCZuYnNwO3NlbmRzJm5ic3A7dG8mbmJzcDtj bGllbnRzJm5ic3A7YW5kJm5ic3A7dmFsaWRhdGVzJm5ic3A7dGhlJm5ic3A7dG9rZW4mbmJzcDtz ZW50Jm5ic3A7PGJyPg0KJmd0OyZuYnNwO2JhY2smbmJzcDtmcm9tJm5ic3A7YSZuYnNwO2NsaWVu dC4mbmJzcDtJbiZuYnNwO2l0cyZuYnNwO2Rlc2lnbiwmbmJzcDtSZXRyeSZuYnNwO3BhY2tldCZu YnNwO2lzJm5ic3A7dXNlZCZuYnNwO3RvJm5ic3A7ZGVsaXZlciZuYnNwO3RoZSZuYnNwOzxicj4N CiZndDsmbmJzcDt0b2tlbiZuYnNwO3RvJm5ic3A7YSZuYnNwO2NsaWVudCZuYnNwO3doaWNoJm5i c3A7YWRkcmVzcyZuYnNwO2hhcyZuYnNwO25vdCZuYnNwO3lldCZuYnNwO2JlZW4mbmJzcDt2YWxp ZGF0ZWQuJm5ic3A7SXQmbmJzcDt2b2lkcyZuYnNwOzxicj4NCiZndDsmbmJzcDt0aGUmbmJzcDtm aXJzdCZuYnNwO3RyYW5zbWlzc2lvbiZuYnNwO29mJm5ic3A7dGhlJm5ic3A7SW5pdGlhbCZuYnNw O3BhY2tldCZuYnNwO3NlbnQmbmJzcDtieSZuYnNwO3RoZSZuYnNwO2NsaWVudCwmbmJzcDthbmQm bmJzcDs8YnI+DQomZ3Q7Jm5ic3A7dHJpZ2dlcnMmbmJzcDthJm5ic3A7c2Vjb25kJm5ic3A7SW5p dGlhbCZuYnNwO3BhY2tldCZuYnNwO3RvJm5ic3A7YmUmbmJzcDtzZW50Jm5ic3A7d2l0aCZuYnNw O3RoZSZuYnNwO3Rva2VuLiZuYnNwO1RoZSZuYnNwOzxicj4NCiZndDsmbmJzcDtleGNoYW5nZSZu YnNwO29mJm5ic3A7dG9rZW4mbmJzcDt3aWxsJm5ic3A7Y2F1c2UmbmJzcDtsb25nZXImbmJzcDtj b25uZWN0aW9uJm5ic3A7ZXN0YWJsaXNobWVudCZuYnNwO2RlbGF5Jm5ic3A7Zm9yJm5ic3A7PGJy Pg0KJmd0OyZuYnNwO2EmbmJzcDtjbGllbnQuPGJyPg0KJmd0OyZuYnNwOzxicj4NCiZndDsmbmJz cDs8YnI+DQomZ3Q7Jm5ic3A7VG8mbmJzcDtpbXByb3ZlJm5ic3A7dGhlJm5ic3A7ZWZmaWNpZW5j eSZuYnNwO29mJm5ic3A7YWRkcmVzcyZuYnNwO3ZhbGlkYXRpb24mbmJzcDtkdXJpbmcmbmJzcDto YW5kc2hha2UsJm5ic3A7b25lJm5ic3A7PGJyPg0KJmd0OyZuYnNwO2lkZWEmbmJzcDtpcyZuYnNw O3RoYXQmbmJzcDt0aGUmbmJzcDtzYW1lJm5ic3A7dG9rZW4mbmJzcDtjYW4mbmJzcDtiZSZuYnNw O2V4Y2hhbmdlZCZuYnNwO3ZpYSZuYnNwO2EmbmJzcDtkaWZmZXJlbnQmbmJzcDtjb250YWluZXIm bmJzcDs8YnI+DQomZ3Q7Jm5ic3A7aS5lLiZuYnNwO3RoZSZuYnNwO0hhbmRzaGFrZSZuYnNwO3Bh Y2tldCwmbmJzcDt0aGF0Jm5ic3A7ZWxpbWluYXRlcyZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29m Jm5ic3A7UmV0cnkmbmJzcDtwYWNrZXQmbmJzcDtmb3ImbmJzcDs8YnI+DQomZ3Q7Jm5ic3A7dG9r ZW4mbmJzcDtkZWxpdmVyeS4mbmJzcDs8YnI+DQomZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZuYnNwOzxi cj4NCiZndDsmbmJzcDtJJm5ic3A7YW0mbmJzcDt3b3JraW5nJm5ic3A7b24mbmJzcDt0aGUmbmJz cDtjb21wbGV0ZSZuYnNwO2RyYWZ0Jm5ic3A7YW5kJm5ic3A7d2lsbCZuYnNwO3N1Ym1pdCZuYnNw O2l0Jm5ic3A7YnkmbmJzcDtGcmlkYXkuJm5ic3A7QmVmb3JlJm5ic3A7PGJyPg0KJmd0OyZuYnNw O3RoYXQsJm5ic3A7aG9wZSZuYnNwO3RoaXMmbmJzcDtjYW4mbmJzcDtiZSZuYnNwO2Rpc2N1c3Nl ZCZuYnNwO2luJm5ic3A7ZW1haWwmbmJzcDtmaXJzdC48YnI+DQomZ3Q7Jm5ic3A7PGJyPg0KJmd0 OyZuYnNwOzxicj4NCiZndDsmbmJzcDtCUiw8YnI+DQomZ3Q7Jm5ic3A7PGJyPg0KJmd0OyZuYnNw O1FpbmcmbmJzcDtBbjxicj4NCiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR2201MB17005571E88F1C68769091A3DA630BN6PR2201MB1700_-- From nobody Thu Oct 31 11:14:29 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CC6120073 for ; Thu, 31 Oct 2019 11:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 p7NW_2ze0oef for ; Thu, 31 Oct 2019 11:14:26 -0700 (PDT) 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 4E2B112006A for ; Thu, 31 Oct 2019 11:14:26 -0700 (PDT) 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 x9VI6ZBI030192; Thu, 31 Oct 2019 18:14:23 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=DWeUzKPCm+/pGXOWQ8TuYkZKfxUZQBW2fnun25V8bqA=; b=bqf2kUaOKgkPcOjd2oG0L0ZdgykBKYxQlmqWKuYeE7Fob5vkNWjan4rIR8ChFY7ZnDtY bwaEbIkfOwtzD8qiSejE1BFbfIYL3U1Tx/4htxojfvN9UcE6AI6ENLPQIBbcaVNNajYr NMn9oMbqSsmS+oTdrfP1Gd2DfJuDp5JUh/MEcruRzSufFyPjq0og5Hn9YZkg3RFfiV8A /SysE0l9oUw9x7k+w83xLNGgQF6X/wn0yY/kVJc2DwuYmsuw/WfhdCADq/Iaq7Z3u/PG vUsm05s7X/Lm1Da4x5oWc82iNisv5FvxN2GnIli/Y3EXEd38UDOSUJUNSdNjKVusQJNi dw== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2vxwgkhxp7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 18:14:23 +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 x9VI2GRG022759; Thu, 31 Oct 2019 14:14:22 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint8.akamai.com with ESMTP id 2vxwfp2k1n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 14:14:20 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.165.123) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 31 Oct 2019 13:14:11 -0500 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; Thu, 31 Oct 2019 13:14:11 -0500 From: "Lubashev, Igor" To: Ted Hardie , Martin Thomson CC: IETF QUIC WG Subject: RE: Proposed response to the 3GPP Liaison Statement Thread-Topic: Proposed response to the 3GPP Liaison Statement Thread-Index: AQHVj4f6X5GCI/p0P0GwCxlpiozmvad0RacAgADViwD//+siIA== Date: Thu, 31 Oct 2019 18:14:09 +0000 Message-ID: <614379f7e12f46c6b38b7928e999cbab@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <3218A80B-DAFD-43EF-8200-F99C660DF9C9@mnot.net> <5557f717-ae03-46a2-aa9f-54f019a07533@www.fastmail.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.34.134] Content-Type: multipart/alternative; boundary="_000_614379f7e12f46c6b38b7928e999cbabustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-31_07:, , 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-1908290000 definitions=main-1910310178 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-31_07:2019-10-30,2019-10-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 mlxscore=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 mlxlogscore=999 suspectscore=0 spamscore=0 malwarescore=0 bulkscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910310179 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, 31 Oct 2019 18:14:29 -0000 --_000_614379f7e12f46c6b38b7928e999cbabustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UkZDIDg1NTggaXMgdmVyeSByZWxldmFudC4gIEl0IHNheXMsIGluIFJlY29tbWVuZGF0aW9ucywg dGhhdCBpbXBsaWNpdCBzaWduYWxzIHNob3VsZCBiZSByZXBsYWNlZCBieSBleHBsaWNpdCBzaWdu YWxzIHdoZW4gb3JpZ2luYXRvcnMgd2lzaCB0byBwcm92aWRlIHRoZW0gdG8gbmV0d29yayBlbGVt ZW50cyBvbiB0aGUgcGF0aC4NCg0KU2luY2UgUVVJQyBpcyByZW1vdmluZyBpbXBsaWNpdCBzaWdu YWxzLCBJIHJlYWQgdGhlIHF1ZXN0aW9uIGZyb20gM0dQUCB0byBtZWFuIOKAnHdoYXQgYXJlIHlv dSByZXBsYWNpbmcgdGhlbSB3aXRoIFtmb3Igb3JpZ2luYXRvcnMgd2hvIHdpc2ggdG8gcHJvdmlk ZSB0aGVtXT/igJ0uICBRVUlDIFdHIHJlc3BvbnNlIHJlYWRzIGFzOiDigJxub3RoaW5nLCBzaG9y dCBvZiBhdHRhY2hpbmcgZW5jcnlwdGlvbiBrZXlzIHRvIHBhY2tldHPigJ0uICBFdmVuIGlmIFFV SUMgdjEgdG9kYXkgY2FuIG9mZmVyIG5vIHJlcGxhY2VtZW50IGZvciB0aGUgcmVtb3ZlZCBzaWdu YWwsIFFVSUMgV0cgc2hvdWxkIG1ha2UgYW4gZWZmb3J0IHRvIGF0IGxlYXN0IHN1Z2dlc3QgYSBw cmFjdGljYWwgd2F5IHRvIHNhdGlzZnkgUkZDIDg1NTjigJlzIHJlY29tbWVuZGF0aW9uIG9mIGFu IGV4cGxpY2l0IHNpZ25hbCDigJxmb3IgdGhvc2Ugd2hvIHdhbnQgaXTigJ0uICBNYXliZSBwb2lu dCB0byBzb21lIG90aGVyIHNwZWNpZmljIGxheWVyIHdoZXJlIHRoZSBXRyBiZWxpZXZlcyB0aGUg c2lnbmFsIGJlbG9uZ3MgKGFuZCBjYW4gYmUgZGVwbG95ZWQgcmVsYXRpdmVseSBxdWlja2x5KT8N Cg0KDQpBcyBmb3IgdGhlIGNvbnRlbnQgb2YgdGhlIHJlcGx5LCBpdCBpbmNsdWRlcyDigJxUaGUg aW1wYWN0IHVwb24gbmV0d29yayBvcGVyYXRvcnMgd2FzIGRpc2N1c3NlZCBleHRlbnNpdmVseSBh cyBwYXJ0IG9mIHRoYXQgZGVjaXNpb24u4oCdICBXZXJlIG5ldHdvcmsgb3BlcmF0b3JzIGEgcGFy dCBvZiB0aG9zZSBkaXNjdXNzaW9ucywgYW5kIHdoYXQgd2FzIHRoZWlyIGZlZWRiYWNrPw0KDQoN CiAgKiAgIElnb3INCg0KDQpGcm9tOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+DQpT ZW50OiBUaHVyc2RheSwgT2N0b2JlciAzMSwgMjAxOSA5OjU4IEFNDQoNCk9uIFdlZCwgT2N0IDMw LCAyMDE5IGF0IDY6MTQgUE0gTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0PG1haWx0 bzptdEBsb3dlbnRyb3B5Lm5ldD4+IHdyb3RlOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlhYi1wYXRoLXNpZ25hbHMtMDM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWFiLTJE cGF0aC0yRHNpZ25hbHMtMkQwMyZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1E am4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJm09YnFmd25RX1gwc1My c18tRUN1TmRsSHV3R2dHUzFFeEwwaHRqV0ZrZGNtQSZzPW4wdC00WVpqVjhOYkpFUUd1cnF0SHdU bUQxV2paYnZHWV9ycWg2ZVlHTkUmZT0+IHNlZW1zIGxpa2UgaXQgbWlnaHQgYmUgYSBoZWxwZnVs IHN1cHBvcnRpbmcgZG9jdW1lbnQuDQpJZiB5b3UgZG8gY2hvb3NlIHRvIGNpdGUgaXQsIGl0IGhh cyBiZWVuIHB1Ymxpc2hlZCBhcyBSRkMgODU1OCwgc28gaXQgd291bGQgYmUgYmVzdCB0byB1c2Ug dGhhdC4NCg0KVGVkDQoNCg0KT24gVGh1LCBPY3QgMzEsIDIwMTksIGF0IDEyOjA5LCBNYXJrIE5v dHRpbmdoYW0gd3JvdGU6DQo+IFFVSUMgV0cgcGFydGljaXBhbnRzLA0KPg0KPiBMYXJzIGFuZCBJ IGhhdmUgZGlzY3Vzc2VkIGEgcmVzcG9uc2UgdG8gdGhpcyBzdGF0ZW1lbnQgYW5kIHBsYW4gb24N Cj4gc2VuZGluZyB0aGUgbWVzc2FnZSBiZWxvdy4gSWYgeW91IGhhdmUgY29tbWVudHMsIHBsZWFz ZSByZXNwb25kIHRvIHRoaXMNCj4gZS1tYWlsIGJ5IDYgTm92ZW1iZXIuDQo+DQo+IFJlZ2FyZHMs DQo+DQo+IH5+fg0KPiBUaGFuayB5b3UgZm9yIHlvdXIgaW5wdXQgdG8gb3VyIHNwZWNpZmljYXRp b25zLg0KPg0KPiBSZWdhcmRpbmcgdGhlIGVuY3J5cHRpb24gb2YgaGVhZGVycyBpbiBhZGRpdGlv biB0byBwYXlsb2FkLCB0aGlzIHdhcyBhDQo+IGNvbnNjaW91cyBkZXNpZ24gZGVjaXNpb24gYnkg dGhlIFdvcmtpbmcgR3JvdXAuIFRyYW5zcG9ydCBoZWFkZXINCj4gZW5jcnlwdGlvbiBwcmV2ZW50 cyBtb2RpZmljYXRpb24gYnkgbWlkZGxlYm94ZXMsIHRoZXJlYnkgYXZvaWRpbmcNCj4gb3NzaWZp Y2F0aW9uIG9mIHRoZSBwcm90b2NvbCwgYW5kIGFsc28gbWFrZXMgdHJhZmZpYyBhbmFseXNpcyBt b3JlDQo+IGRpZmZpY3VsdC4gVGhlIGltcGFjdCB1cG9uIG5ldHdvcmsgb3BlcmF0b3JzIHdhcyBk aXNjdXNzZWQgZXh0ZW5zaXZlbHkNCj4gYXMgcGFydCBvZiB0aGF0IGRlY2lzaW9uLg0KPg0KPiBS ZWdhcmRpbmcgdGhlIHNwaW4gYml0LCB3ZSBiZWxpZXZlIHRoYXQgeW91ciBjaGFyYWN0ZXJpc2F0 aW9uIGlzIGNvcnJlY3QuDQo+DQo+IFJlZ2FyZGluZyBwYWNrZXQgbG9zcyBtZWFzdXJlbWVudHMs IFFVSUMgZG9lcyBzdXBwb3J0IHRoZW0sIGJ1dCBvbmx5IGJ5DQo+IHRoZSBlbmRwb2ludHMgb2Yg Y29tbXVuaWNhdGlvbiAtLSBub3QgYnkgdGhpcmQgcGFydGllcyBvYnNlcnZpbmcgaXQuDQo+IEtl eXMgbWF5IGJlIGV4cG9ydGVkIGJ5IG9uZSBvZiB0aGUgZW5kcG9pbnRzIHRvIGFsbG93IGRlY29k aW5nIG9mDQo+IHBhY2tldCB0cmFjZXMgKGUuZy4sIHdpdGggV2lyZXNoYXJrKSwgYnV0IHRoYXQg aXMgbm90IHBhcnQgb2YgdGhlIFFVSUMNCj4gc3RhbmRhcmQuDQo+DQo+IFJlZ2FyZGluZyBwZXJm b3JtYW5jZSBhbmFseXNpcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgZGVzY3JpYmVkDQo+ IHlvdXIgdXNlIGNhc2UgaW4gbW9yZSBkZXRhaWwuIEhvd2V2ZXIsIGl0J3MgaW1wb3J0YW50IHRv IGtub3cgdGhhdCB0aGUNCj4gV29ya2luZyBHcm91cCBkZWNpZGVkIGVhcmx5IG9uIHRoYXQgUVVJ Q3YxIHdvdWxkIGZvY3VzIG9uIHRoZSB1c2UgY2FzZQ0KPiBvZiBIVFRQLzMuDQo+DQo+IEluIHR1 cm4sIEhUVFAgc3RhbmRhcmRpc2F0aW9uIGZvY3VzZXMgcHJpbWFyaWx5IG9uIHRoZSBXZWIgYnJv d3NpbmcgdXNlDQo+IGNhc2U7IHdoaWxlIHdlIGFja25vd2xlZGdlIHRoYXQgdGhlcmUgYXJlIG90 aGVyIHVzZXMgb2YgdGhlIHByb3RvY29sLA0KPiBhbmQgd2UgYWNjb21tb2RhdGUgdGhlbSB3aGVy ZSBwb3NzaWJsZSwgd2UgY2Fubm90IGNoYW5nZSB0aGUgcHJvdG9jb2wNCj4gaW4gd2F5cyB0aGF0 IGhhcm1zIHRoYXQgdXNlLiBFeHBvc2luZyB0cmFuc3BvcnQgbWV0YWRhdGEgd291bGQgbGlrZWx5 DQo+IGRvIHNvLg0KPg0KPiBLaW5kIHJlZ2FyZHMsDQo+DQo+IE1hcmsgTm90dGluZ2hhbSBhbmQg TGFycyBFZ2dlcnQsIFFVSUMgV29ya2luZyBHcm91cCBjaGFpcnMNCj4gfn5+DQo= --_000_614379f7e12f46c6b38b7928e999cbabustx2exdag1mb5msgcorpak_ 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 bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MTY3MDEzNzU1OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTEwOTM3Nzk2IC05MjQ3OTk4ODYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UkZDIDg1NTgg aXMgdmVyeSByZWxldmFudC4mbmJzcDsgSXQgc2F5cywgaW4gUmVjb21tZW5kYXRpb25zLCB0aGF0 IGltcGxpY2l0IHNpZ25hbHMgc2hvdWxkIGJlIHJlcGxhY2VkIGJ5IGV4cGxpY2l0IHNpZ25hbHMg d2hlbiBvcmlnaW5hdG9ycyB3aXNoIHRvIHByb3ZpZGUgdGhlbSB0byBuZXR3b3JrIGVsZW1lbnRz IG9uIHRoZSBwYXRoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZSBRVUlDIGlzIHJlbW92 aW5nIGltcGxpY2l0IHNpZ25hbHMsIEkgcmVhZCB0aGUgcXVlc3Rpb24gZnJvbSAzR1BQIHRvIG1l YW4g4oCcd2hhdCBhcmUgeW91IHJlcGxhY2luZyB0aGVtIHdpdGggW2ZvciBvcmlnaW5hdG9ycyB3 aG8gd2lzaCB0byBwcm92aWRlIHRoZW1dP+KAnS4mbmJzcDsgUVVJQyBXRyByZXNwb25zZSByZWFk cyBhczog4oCcbm90aGluZywgc2hvcnQgb2YgYXR0YWNoaW5nIGVuY3J5cHRpb24ga2V5cyB0byBw YWNrZXRz4oCdLiZuYnNwOw0KIEV2ZW4gaWYgUVVJQyB2MSB0b2RheSBjYW4gb2ZmZXIgbm8gcmVw bGFjZW1lbnQgZm9yIHRoZSByZW1vdmVkIHNpZ25hbCwgUVVJQyBXRyBzaG91bGQgbWFrZSBhbiBl ZmZvcnQgdG8gYXQgbGVhc3Qgc3VnZ2VzdCBhIHByYWN0aWNhbCB3YXkgdG8gc2F0aXNmeSBSRkMg ODU1OOKAmXMgcmVjb21tZW5kYXRpb24gb2YgYW4gZXhwbGljaXQgc2lnbmFsIOKAnGZvciB0aG9z ZSB3aG8gd2FudCBpdOKAnS4mbmJzcDsgTWF5YmUgcG9pbnQgdG8gc29tZSBvdGhlciBzcGVjaWZp Yw0KIGxheWVyIHdoZXJlIHRoZSBXRyBiZWxpZXZlcyB0aGUgc2lnbmFsIGJlbG9uZ3MgKGFuZCBj YW4gYmUgZGVwbG95ZWQgcmVsYXRpdmVseSBxdWlja2x5KT88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBmb3IgdGhl IGNvbnRlbnQgb2YgdGhlIHJlcGx5LCBpdCBpbmNsdWRlcyDigJxUaGUgaW1wYWN0IHVwb24gbmV0 d29yayBvcGVyYXRvcnMgd2FzIGRpc2N1c3NlZCBleHRlbnNpdmVseSBhcyBwYXJ0IG9mIHRoYXQg ZGVjaXNpb24u4oCdJm5ic3A7IFdlcmUgbmV0d29yayBvcGVyYXRvcnMgYSBwYXJ0IG9mIHRob3Nl IGRpc2N1c3Npb25zLCBhbmQgd2hhdCB3YXMgdGhlaXIgZmVlZGJhY2s/PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+SWdvcjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gVGVkIEhhcmRpZSAmbHQ7dGVkLmlldGZAZ21h aWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE9jdG9iZXIgMzEsIDIwMTkg OTo1OCBBTTxicj4NCjxicj4NCjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gV2VkLCBPY3QgMzAsIDIwMTkgYXQgNjoxNCBQTSBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOm10QGxvd2VudHJvcHkubmV0Ij5tdEBsb3dlbnRyb3B5Lm5ldDwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5p ZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWFiLTJEcGF0aC0yRHNpZ25hbHMtMkQwMyZhbXA7ZD1Ed01G YVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZM M3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPWJxZnduUV9YMHNTMnNfLUVDdU5kbEh1d0dn R1MxRXhMMGh0aldGa2RjbUEmYW1wO3M9bjB0LTRZWmpWOE5iSkVRR3VycXRId1RtRDFXalpidkdZ X3JxaDZlWUdORSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWFiLXBhdGgtc2lnbmFscy0wMzwvYT4NCiBzZWVtcyBsaWtlIGl0IG1pZ2h0 IGJlIGEgaGVscGZ1bCBzdXBwb3J0aW5nIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSBkbyBjaG9vc2UgdG8g Y2l0ZSBpdCwgaXQgaGFzIGJlZW4gcHVibGlzaGVkIGFzIFJGQyA4NTU4LCBzbyBpdCB3b3VsZCBi ZSBiZXN0IHRvIHVzZSB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9u IFRodSwgT2N0IDMxLCAyMDE5LCBhdCAxMjowOSwgTWFyayBOb3R0aW5naGFtIHdyb3RlOjxicj4N CiZndDsgUVVJQyBXRyBwYXJ0aWNpcGFudHMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExhcnMgYW5k IEkgaGF2ZSBkaXNjdXNzZWQgYSByZXNwb25zZSB0byB0aGlzIHN0YXRlbWVudCBhbmQgcGxhbiBv biA8YnI+DQomZ3Q7IHNlbmRpbmcgdGhlIG1lc3NhZ2UgYmVsb3cuIElmIHlvdSBoYXZlIGNvbW1l bnRzLCBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIDxicj4NCiZndDsgZS1tYWlsIGJ5IDYgTm92ZW1i ZXIuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IH5+ fjxicj4NCiZndDsgVGhhbmsgeW91IGZvciB5b3VyIGlucHV0IHRvIG91ciBzcGVjaWZpY2F0aW9u cy48YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkaW5nIHRoZSBlbmNyeXB0aW9uIG9mIGhlYWRl cnMgaW4gYWRkaXRpb24gdG8gcGF5bG9hZCwgdGhpcyB3YXMgYSA8YnI+DQomZ3Q7IGNvbnNjaW91 cyBkZXNpZ24gZGVjaXNpb24gYnkgdGhlIFdvcmtpbmcgR3JvdXAuIFRyYW5zcG9ydCBoZWFkZXIg PGJyPg0KJmd0OyBlbmNyeXB0aW9uIHByZXZlbnRzIG1vZGlmaWNhdGlvbiBieSBtaWRkbGVib3hl cywgdGhlcmVieSBhdm9pZGluZyA8YnI+DQomZ3Q7IG9zc2lmaWNhdGlvbiBvZiB0aGUgcHJvdG9j b2wsIGFuZCBhbHNvIG1ha2VzIHRyYWZmaWMgYW5hbHlzaXMgbW9yZSA8YnI+DQomZ3Q7IGRpZmZp Y3VsdC4gVGhlIGltcGFjdCB1cG9uIG5ldHdvcmsgb3BlcmF0b3JzIHdhcyBkaXNjdXNzZWQgZXh0 ZW5zaXZlbHkgPGJyPg0KJmd0OyBhcyBwYXJ0IG9mIHRoYXQgZGVjaXNpb24uPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFJlZ2FyZGluZyB0aGUgc3BpbiBiaXQsIHdlIGJlbGlldmUgdGhhdCB5b3VyIGNo YXJhY3RlcmlzYXRpb24gaXMgY29ycmVjdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkaW5n IHBhY2tldCBsb3NzIG1lYXN1cmVtZW50cywgUVVJQyBkb2VzIHN1cHBvcnQgdGhlbSwgYnV0IG9u bHkgYnkgPGJyPg0KJmd0OyB0aGUgZW5kcG9pbnRzIG9mIGNvbW11bmljYXRpb24gLS0gbm90IGJ5 IHRoaXJkIHBhcnRpZXMgb2JzZXJ2aW5nIGl0LiA8YnI+DQomZ3Q7IEtleXMgbWF5IGJlIGV4cG9y dGVkIGJ5IG9uZSBvZiB0aGUgZW5kcG9pbnRzIHRvIGFsbG93IGRlY29kaW5nIG9mIDxicj4NCiZn dDsgcGFja2V0IHRyYWNlcyAoZS5nLiwgd2l0aCBXaXJlc2hhcmspLCBidXQgdGhhdCBpcyBub3Qg cGFydCBvZiB0aGUgUVVJQyA8YnI+DQomZ3Q7IHN0YW5kYXJkLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBSZWdhcmRpbmcgcGVyZm9ybWFuY2UgYW5hbHlzaXMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYg eW91IGRlc2NyaWJlZCA8YnI+DQomZ3Q7IHlvdXIgdXNlIGNhc2UgaW4gbW9yZSBkZXRhaWwuIEhv d2V2ZXIsIGl0J3MgaW1wb3J0YW50IHRvIGtub3cgdGhhdCB0aGUgPGJyPg0KJmd0OyBXb3JraW5n IEdyb3VwIGRlY2lkZWQgZWFybHkgb24gdGhhdCBRVUlDdjEgd291bGQgZm9jdXMgb24gdGhlIHVz ZSBjYXNlIDxicj4NCiZndDsgb2YgSFRUUC8zLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJbiB0dXJu LCBIVFRQIHN0YW5kYXJkaXNhdGlvbiBmb2N1c2VzIHByaW1hcmlseSBvbiB0aGUgV2ViIGJyb3dz aW5nIHVzZSA8YnI+DQomZ3Q7IGNhc2U7IHdoaWxlIHdlIGFja25vd2xlZGdlIHRoYXQgdGhlcmUg YXJlIG90aGVyIHVzZXMgb2YgdGhlIHByb3RvY29sLCA8YnI+DQomZ3Q7IGFuZCB3ZSBhY2NvbW1v ZGF0ZSB0aGVtIHdoZXJlIHBvc3NpYmxlLCB3ZSBjYW5ub3QgY2hhbmdlIHRoZSBwcm90b2NvbCA8 YnI+DQomZ3Q7IGluIHdheXMgdGhhdCBoYXJtcyB0aGF0IHVzZS4gRXhwb3NpbmcgdHJhbnNwb3J0 IG1ldGFkYXRhIHdvdWxkIGxpa2VseSA8YnI+DQomZ3Q7IGRvIHNvLjxicj4NCiZndDsgPGJyPg0K Jmd0OyBLaW5kIHJlZ2FyZHMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE1hcmsgTm90dGluZ2hhbSBh bmQgTGFycyBFZ2dlcnQsIFFVSUMgV29ya2luZyBHcm91cCBjaGFpcnM8YnI+DQomZ3Q7IH5+fjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_614379f7e12f46c6b38b7928e999cbabustx2exdag1mb5msgcorpak_-- From nobody Thu Oct 31 13:54:50 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E871200FF for ; Thu, 31 Oct 2019 13:54:45 -0700 (PDT) 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, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 3BZ6OAM9cDyD for ; Thu, 31 Oct 2019 13:54:43 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7395612090B for ; Thu, 31 Oct 2019 13:54:42 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id m7so8130207lji.2 for ; Thu, 31 Oct 2019 13:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NbMJkhlEE9uiShqfMdFmYJrbK905C6lnALUBKGsPx8c=; b=ZksFc+4/pWPGylgTHYaNGVjpvdSVTDdeOb5yweQgf3aYKg3nofZsi5avrh9fznPCkW JOsXvml/xit8FilLXCTACGjsX9BatAywm6rPXtXa4qVvhX42eBnSArte0Dw6atvNJZDl KDF9ut/9zAQmfUaXW7sEeigR+S32QszkY1qEQQj+tYXDYtC6PEu0ZXbGr+FoD+vHbxUh bSG/GAP/TMhLYHIgXwRGaUP9G9SJpvipyGGRue2u6Zikoehy7RDGd1I8vlCr9crPPog7 PxnLZOpdLhrBYNib/QiQKBQfLJbitJJXcvT2p0SZ7dIPEHGwOXCummDTIL2lNzRdR3JU z+Mg== 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=NbMJkhlEE9uiShqfMdFmYJrbK905C6lnALUBKGsPx8c=; b=aZwcAgvG+h7/2UeZphjs8/aMKiprm3HI9/DYgoKz8BlqZHA+yNF6Q6zm9oxFqN5saX Lw3xcJopF5NXxlm3Wl1NqWiE7p70h9H0Wul/AP1RxmlXxYxdSgfArr0OKZmCXutjC9Db /fiSm0Oab9TCTr5f/NOJRR+xcXMpAW0xjjnWAPyWcTpx2BVoss7uqYtINVKe6y+lazwD tPWX+A/CNdEOApohxN90LDlCkaKs4nRMzyxFw1f9M0HGkyfE/5HWzFoQnl1qBugP9oHz fvaUx0xMlxqVa2Ka/Acfp/bEa/LxkO1Bdxv2jFoue8/gU8fc1FN35lJWWaV8c4SiQf0F JJZA== X-Gm-Message-State: APjAAAV1gK20/h5Z5dqWZvOf2k8WyDPaziVfGenvbACUXd4P3EjgOigl 9pL2wsb2dGYw3Wig3eYo3Wo2jgsOw/saC9kFX2s= X-Google-Smtp-Source: APXvYqxP0TbxqZXBobvYWl4EBK+fQVRNODOm8kKLOtJh2M7RtL+vpRO5tgrKY2doMpc3Z+1YSK4jnIRSZSjQKNPlS0E= X-Received: by 2002:a2e:b5a2:: with SMTP id f2mr5524984ljn.108.1572555280622; Thu, 31 Oct 2019 13:54:40 -0700 (PDT) MIME-Version: 1.0 References: <3218A80B-DAFD-43EF-8200-F99C660DF9C9@mnot.net> <5557f717-ae03-46a2-aa9f-54f019a07533@www.fastmail.com> <614379f7e12f46c6b38b7928e999cbab@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <614379f7e12f46c6b38b7928e999cbab@ustx2ex-dag1mb5.msg.corp.akamai.com> From: David Schinazi Date: Thu, 31 Oct 2019 13:54:29 -0700 Message-ID: Subject: Re: Proposed response to the 3GPP Liaison Statement To: "Lubashev, Igor" Cc: Ted Hardie , Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000e429ee05963b0e62" 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, 31 Oct 2019 20:54:45 -0000 --000000000000e429ee05963b0e62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support the chair's proposed response. If 3GPP wants to use QUIC for their own use-case, that sounds great. But at this point in time the QUIC WG should be focusing on delivering HTTP/3+QUICv1, not gathering more requirements, and not documenting best practices for these other use-cases. It's possible that TCP is a better fit than QUICv1 for the 3GPP's use-case, but it's not the responsibility of the QUIC WG to figure out whether that is the case. David On Thu, Oct 31, 2019 at 11:14 AM Lubashev, Igor wrote= : > RFC 8558 is very relevant. It says, in Recommendations, that implicit > signals should be replaced by explicit signals when originators wish to > provide them to network elements on the path. > > > > Since QUIC is removing implicit signals, I read the question from 3GPP to > mean =E2=80=9Cwhat are you replacing them with [for originators who wish = to provide > them]?=E2=80=9D. QUIC WG response reads as: =E2=80=9Cnothing, short of a= ttaching > encryption keys to packets=E2=80=9D. Even if QUIC v1 today can offer no > replacement for the removed signal, QUIC WG should make an effort to at > least suggest a practical way to satisfy RFC 8558=E2=80=99s recommendatio= n of an > explicit signal =E2=80=9Cfor those who want it=E2=80=9D. Maybe point to = some other > specific layer where the WG believes the signal belongs (and can be > deployed relatively quickly)? > > > > > > As for the content of the reply, it includes =E2=80=9CThe impact upon net= work > operators was discussed extensively as part of that decision.=E2=80=9D W= ere > network operators a part of those discussions, and what was their feedbac= k? > > > > - Igor > > > > > > *From:* Ted Hardie > *Sent:* Thursday, October 31, 2019 9:58 AM > > On Wed, Oct 30, 2019 at 6:14 PM Martin Thomson wrote: > > https://tools.ietf.org/html/draft-iab-path-signals-03 > > seems like it might be a helpful supporting document. > > If you do choose to cite it, it has been published as RFC 8558, so it > would be best to use that. > > > > Ted > > > > > > On Thu, Oct 31, 2019, at 12:09, Mark Nottingham wrote: > > QUIC WG participants, > > > > Lars and I have discussed a response to this statement and plan on > > sending the message below. If you have comments, please respond to this > > e-mail by 6 November. > > > > Regards, > > > > ~~~ > > Thank you for your input to our specifications. > > > > Regarding the encryption of headers in addition to payload, this was a > > conscious design decision by the Working Group. Transport header > > encryption prevents modification by middleboxes, thereby avoiding > > ossification of the protocol, and also makes traffic analysis more > > difficult. The impact upon network operators was discussed extensively > > as part of that decision. > > > > Regarding the spin bit, we believe that your characterisation is correc= t. > > > > Regarding packet loss measurements, QUIC does support them, but only by > > the endpoints of communication -- not by third parties observing it. > > Keys may be exported by one of the endpoints to allow decoding of > > packet traces (e.g., with Wireshark), but that is not part of the QUIC > > standard. > > > > Regarding performance analysis, it would be helpful if you described > > your use case in more detail. However, it's important to know that the > > Working Group decided early on that QUICv1 would focus on the use case > > of HTTP/3. > > > > In turn, HTTP standardisation focuses primarily on the Web browsing use > > case; while we acknowledge that there are other uses of the protocol, > > and we accommodate them where possible, we cannot change the protocol > > in ways that harms that use. Exposing transport metadata would likely > > do so. > > > > Kind regards, > > > > Mark Nottingham and Lars Eggert, QUIC Working Group chairs > > ~~~ > > --000000000000e429ee05963b0e62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the chair's proposed response.

If 3GPP wants to use QUIC for their own use-case, that sounds great. = But at this point in time the QUIC WG should be focusing on delivering HTTP= /3+QUICv1, not gathering more requirements, and not documenting best practi= ces for these other use-cases. It's possible that TCP is a better fit t= han QUICv1 for the 3GPP's use-case, but it's not the responsibility= of the QUIC WG to figure out whether that is the case.

David

On Thu, Oct 31, 2019 at 11:14 AM Lubashev, Igor <ilubashe@akamai.com> wrote:

RFC 8558 is very relevant.=C2=A0 It says, in Recomme= ndations, that implicit signals should be replaced by explicit signals when= originators wish to provide them to network elements on the path.

=C2=A0

Since QUIC is removing implicit signals, I read the = question from 3GPP to mean =E2=80=9Cwhat are you replacing them with [for o= riginators who wish to provide them]?=E2=80=9D.=C2=A0 QUIC WG response read= s as: =E2=80=9Cnothing, short of attaching encryption keys to packets=E2=80= =9D.=C2=A0 Even if QUIC v1 today can offer no replacement for the removed signal, QUI= C WG should make an effort to at least suggest a practical way to satisfy R= FC 8558=E2=80=99s recommendation of an explicit signal =E2=80=9Cfor those w= ho want it=E2=80=9D.=C2=A0 Maybe point to some other specific layer where the WG believes the signal belongs (and can be deployed relati= vely quickly)?

=C2=A0

=C2=A0

As for the content of the reply, it includes =E2=80= =9CThe impact upon network operators was discussed extensively as part of t= hat decision.=E2=80=9D=C2=A0 Were network operators a part of those discuss= ions, and what was their feedback?

=C2=A0

  • Igor

=C2=A0

=C2=A0

From: Ted Hardie <ted.ietf@gmail.com>
Sent: Thursday, October 31, 2019 9:58 AM

On Wed, Oct 30, 2019 at 6:14 PM Martin Thomson <<= a href=3D"mailto:mt@lowentropy.net" target=3D"_blank">mt@lowentropy.net= > wrote:

https://tools.ietf.org/html/draft-iab-path-sig= nals-03 seems like it might be a helpful supporting document.

If you do choose to cite it, it has been published a= s RFC 8558, so it would be best to use that.

=C2=A0

Ted

=C2=A0

=C2=A0

On Thu, Oct 31, 2019, a= t 12:09, Mark Nottingham wrote:
> QUIC WG participants,
>
> Lars and I have discussed a response to this statement and plan on > sending the message below. If you have comments, please respond to thi= s
> e-mail by 6 November.
>
> Regards,
>
> ~~~
> Thank you for your input to our specifications.
>
> Regarding the encryption of headers in addition to payload, this was a=
> conscious design decision by the Working Group. Transport header
> encryption prevents modification by middleboxes, thereby avoiding
> ossification of the protocol, and also makes traffic analysis more > difficult. The impact upon network operators was discussed extensively=
> as part of that decision.
>
> Regarding the spin bit, we believe that your characterisation is corre= ct.
>
> Regarding packet loss measurements, QUIC does support them, but only b= y
> the endpoints of communication -- not by third parties observing it. <= br> > Keys may be exported by one of the endpoints to allow decoding of
> packet traces (e.g., with Wireshark), but that is not part of the QUIC=
> standard.
>
> Regarding performance analysis, it would be helpful if you described <= br> > your use case in more detail. However, it's important to know that= the
> Working Group decided early on that QUICv1 would focus on the use case=
> of HTTP/3.
>
> In turn, HTTP standardisation focuses primarily on the Web browsing us= e
> case; while we acknowledge that there are other uses of the protocol, =
> and we accommodate them where possible, we cannot change the protocol =
> in ways that harms that use. Exposing transport metadata would likely =
> do so.
>
> Kind regards,
>
> Mark Nottingham and Lars Eggert, QUIC Working Group chairs
> ~~~

--000000000000e429ee05963b0e62-- From nobody Thu Oct 31 14:13:03 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CA5120090 for ; Thu, 31 Oct 2019 14:13:01 -0700 (PDT) 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 FEtFNzQpp3Qx for ; Thu, 31 Oct 2019 14:12:59 -0700 (PDT) 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 1BFDB12081B for ; Thu, 31 Oct 2019 14:12:59 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id q64so8097417ljb.12 for ; Thu, 31 Oct 2019 14:12:59 -0700 (PDT) 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=vDDJTVyrM43qYQyvU1BiMOJbJM3rxCznBN4y3dqzSWU=; b=I6nDlrh1iBI669ojSVm+BFvW/UYtRxt5ug67ju2bwEC6mGROtIA0SuBu5CCpJ75Dj4 VdzwAMWN2r2uY6lAZ5M641gNiQxl4gEFsUjYOmfE0rAGvw/nZHK/eGsfIsEJwIsJObfL E0sxH0vs0wtVa/ZnBR9XsXTA/BDCfGg22lZuuVw4tKtPariWTfvrUfDhgI5LUrZD4WvX WA04m++BbOrs662F/+HHhIPPwfKwGWkUcmPSNw6wp8DbYfDESG0dTqtSrLiEc21xUscH 7/8mTZVgN1APr2F1PiADnDuoIrI4iyeCURelEepknd5kmkdYP566kh3x1Ga9ssbzjeXt 5JZg== 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=vDDJTVyrM43qYQyvU1BiMOJbJM3rxCznBN4y3dqzSWU=; b=g5vOl9lqMR8Frq2uZ8xsPJI2m/9wvqROWLefMjCRN5wPbxAlh50B41SpwsmdxRBxzr 7vd4fuSf9Vvqya3/wr9O3qfD03/Fi2MBd1S4QhDNTXNSa9yK5Kh5/X05PTnM2Ej1T0Wz mvNwS9qDrnszGhPgp3fJsdWKiTN9auiQQ5zXihXR86toGANKgYgELrbEEjmY+FjTv4Mg 4MzuyhHRooNiQW+x+v68gHW02rzRUCtMFCwQJcSCd7gSf/Pp5UVRCQwV9C4dafrKTMrf haJUlS+L8iqN1d9xmNxhv1NwC0iTTp3vkFmAzoKHfj7x7QnySdhinzZmAJ7wPRInBsYh Emeg== X-Gm-Message-State: APjAAAUp0n+q7dac+mpJDgUDugAc2Wr0v1sPqIWkoLE4oh1cHJiMA17s YNUVRDRr9e8/2H8Woib08/o3sd02fPAvjXbxxfZoxuvy X-Google-Smtp-Source: APXvYqwrAE3WMEBrjerln7dGAWTTLcLW4IZduju855+mC5gA8643pgFhBJtCGl/dj4T0MmGlF8aFm5asUfxcXkjOo8g= X-Received: by 2002:a2e:b0d9:: with SMTP id g25mr1666642ljl.176.1572556377111; Thu, 31 Oct 2019 14:12:57 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Thu, 31 Oct 2019 14:12:46 -0700 Message-ID: Subject: Version Ossification: Intended Scope for QUICv1 To: QUIC Content-Type: multipart/alternative; boundary="0000000000003f3fa005963b502e" 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, 31 Oct 2019 21:13:02 -0000 --0000000000003f3fa005963b502e Content-Type: text/plain; charset="UTF-8" Hi folks, The conversation around version ossification has been really interesting since Cupertino. But at least for me it's reached a level of complexity that warrants taking a step back and looking at what we're trying to solve. Here's my understanding of where we are: 1) In Cupertino there was consensus in the room to do something to mitigate ossification of QUICv1. 2) The solution that folks liked was to have a concept of alternative versions and alternative salts that act like QUICv1 but are encoded differently over the wire. 3) A concrete proposal for (2) was for servers to have their own set of (alternative_version, alternative_salt) pairs, then transmit a random pair from that set to each client (i.e. via transport parameters). The server can then reconstruct the alternative_salt just by seeing the alternative_version. 4) Kazuho proposed a solution (#3166 ) that was both more powerful and more complex: tie the (alternative_version, alternative_salt) pair to NEW_TOKEN frames, to allow servers to generate a unique alternative_salt per client and encode it in the token. 5) After some interesting back and forth on that PR, it became clear that this is a hard problem to solve: this could cause failures if servers forget their token keys, and mitigations for that problem can become downgrade attack vectors 6) While there was clear WG appetite for (1), I'm not sure we have consensus to build a more powerful solution like (4) I fear that solving (5) could take some time, which would delay QUICv1. Instead I'd like to propose the following plan: a) we take the simpler solution (3) and add that to the spec b) we take the more powerful/complex solution (5) a turn it into a QUIC extension That would allow us to ship QUICv1 with some level of ossification mitigations without delay. Thoughts? David --0000000000003f3fa005963b502e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

The conversation around versi= on ossification has been really interesting since Cupertino. But at least f= or me it's reached a level of complexity that warrants taking a step ba= ck and looking at what we're trying to solve. Here's my understandi= ng of where we are:

1) In Cupertino there was cons= ensus in the room to do something to mitigate ossification of QUICv1.
=

2) The solution that folks liked was to have a concept = of alternative versions and alternative salts that act like QUICv1 but are = encoded differently over the wire.

3) A concrete p= roposal for (2) was for servers to have their own set of (alternative_versi= on, alternative_salt) pairs, then transmit a random pair from that set to e= ach client (i.e. via transport parameters). The server can then reconstruct= the alternative_salt just by seeing the=C2=A0alternative_version.

4) Kazuho proposed a solution (#3166) that was both more powerful and= more complex: tie the=C2=A0(alternative_version, alternative_salt) pair to= NEW_TOKEN frames, to allow servers to generate a unique=C2=A0alternative_s= alt per client and encode it in the token.

5) Afte= r some interesting back and forth on that PR, it became clear that this is = a hard problem to solve: this could cause failures if servers forget their = token keys, and mitigations for that problem can become downgrade attack ve= ctors

6) While there was clear WG appetite for (1)= , I'm not sure we have consensus to build a more powerful solution like= (4)

I fear that solving (5) could take some time,= which would delay QUICv1. Instead I'd like to propose the following pl= an:
a) we take the simpler solution (3) and add that to the spec<= /div>
b) we take the more powerful/complex solution (5) a turn it into = a QUIC extension

That would allow us to ship QUICv= 1 with some level of ossification mitigations without delay.

=
Thoughts?

David


--0000000000003f3fa005963b502e-- From nobody Thu Oct 31 14:34:05 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033741201A3 for ; Thu, 31 Oct 2019 14:34:04 -0700 (PDT) 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 FVTZ47Vo4CGe for ; Thu, 31 Oct 2019 14:34:01 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A461200FF for ; Thu, 31 Oct 2019 14:34:00 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id q2so1638679ljg.7 for ; Thu, 31 Oct 2019 14:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kouyCfcUERnzavQ9xx7a9rHsslTaYZ07miw8C8xrBCE=; b=bpKJY/MBjJDjjMMpJisMvTYJXOSfvFBNDcmIMGBGC/SjQKPflKHbfwLNn4KFYWX6ec 1dsjRiq7Scqcd4bigNbqCe7vZUvZEj8JBO7k16W7w2+zBLkYMexOis54gCIataj9u4cH XEGx8lPvWTOzL6EY3UgInIEYz8O2TvDJ+mbzCbsLiAGuMKMfIch3wcS6m91Zk0534ni1 m/0SHELPMZ7VJzOhKX6DTACotSwdJWCxuxUkmIUZgR8WGpSnp0YHu2zsjZimRMLjqScI L65dwa/QMUdobkoyZ4AjBIViIKz3WEs4S7Jx8e/FnkiVnljEPhI0ejSkWWyEojPhdBox xM9w== 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=kouyCfcUERnzavQ9xx7a9rHsslTaYZ07miw8C8xrBCE=; b=Inq4rOKS1BaFE9kX/Yed6GOenPm9vvNrtyzR7UrYCkWU1h8oC5BXkCeJitayaM4BKU 6OOPJSVLQbkPKRH91nNu2i9Bb+PA6wOEh1Av9KM8UvRfNnKFPPdpp12xLxxzhr857/1G WDkH6xBW8LpBumxa9Reezo9gAfc+afBPK69c1wWboYJ8Rrw7nr3heAoivIQxx2ujAkVR 0x9SJXwbshBMrvQVauDv8IaFBScc9ZA86SO+VFDRAnLeJ/fbuCNBkTxmrREBduWSED2g RWpQAaAAnB7Kb1EvMlU7RYQWhGFSMZkrLTrrXlJZ97uQ2ksS1Z25YRKuiq5gLcm0EvjM 6r7Q== X-Gm-Message-State: APjAAAVrJTczzogc1xkK8AZc6GhjLIQEW/MY4u0zel4LFmbp9fYUvHTB 3YeJ7cH2VlN3TaMRnYyeasCwf0XKy0HPRoobaPw= X-Google-Smtp-Source: APXvYqw/tuI85BFfJLqKa5Qs7uIZHULR+WC/6kiloeSxDlbCHy2bNsesqZedvWw87b7Xy/MRQaisu7qbFxYvnYp2b3A= X-Received: by 2002:a05:651c:326:: with SMTP id b6mr5699972ljp.119.1572557639321; Thu, 31 Oct 2019 14:33:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kazuho Oku Date: Fri, 1 Nov 2019 06:33:48 +0900 Message-ID: Subject: Re: Version Ossification: Intended Scope for QUICv1 To: David Schinazi Cc: QUIC Content-Type: multipart/alternative; boundary="0000000000007b0eb305963b9b94" 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, 31 Oct 2019 21:34:04 -0000 --0000000000007b0eb305963b9b94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi David, Thank you for summarizing the high-level options. I think it's very useful to have this discussion. Please see my comments below. 2019=E5=B9=B411=E6=9C=881=E6=97=A5(=E9=87=91) 6:13 David Schinazi : > Hi folks, > > The conversation around version ossification has been really interesting > since Cupertino. But at least for me it's reached a level of complexity > that warrants taking a step back and looking at what we're trying to solv= e. > Here's my understanding of where we are: > > 1) In Cupertino there was consensus in the room to do something to > mitigate ossification of QUICv1. > > 2) The solution that folks liked was to have a concept of alternative > versions and alternative salts that act like QUICv1 but are encoded > differently over the wire. > > 3) A concrete proposal for (2) was for servers to have their own set of > (alternative_version, alternative_salt) pairs, then transmit a random pai= r > from that set to each client (i.e. via transport parameters). The server > can then reconstruct the alternative_salt just by seeing > the alternative_version. > > 4) Kazuho proposed a solution (#3166 > ) that was both more > powerful and more complex: tie the (alternative_version, alternative_salt= ) > pair to NEW_TOKEN frames, to allow servers to generate a > unique alternative_salt per client and encode it in the token. > I dispute the argument that #3166 is more complex. My view is that #3166 is more powerful and simpler than (3) (the PR being #2573). Reasons: * For a server associating one initial salt with one alternative version, #3166 and #2573 are identical with the exception being how the information is carryied (i.e. TP vs. NEW_TOKEN). * For a client, bundling the alternative seeds in a NEW_TOKEN makes things simpler, as clients are not required to have a new state that has to be retained across multiple connections. > 5) After some interesting back and forth on that PR, it became clear that > this is a hard problem to solve: this could cause failures if servers > forget their token keys, and mitigations for that problem can become > downgrade attack vectors > The proposal for 3 has this problem. It leads to a failure when a server forgets the alternative initial salts. > > 6) While there was clear WG appetite for (1), I'm not sure we have > consensus to build a more powerful solution like (4) > > I fear that solving (5) could take some time, which would delay QUICv1. > Instead I'd like to propose the following plan: > a) we take the simpler solution (3) and add that to the spec > b) we take the more powerful/complex solution (5) a turn it into a QUIC > extension > > That would allow us to ship QUICv1 with some level of ossification > mitigations without delay. > As stated, the proposed solution for (4) is simpler than (3), can be used to implement (3), and also provides a stronger protection for servers certain that they can retain the token unprotection keys. I agree that solving (5) for all parties might be hard, and that we might want to punt that to v2. But, I think we should adopt (4) than (3) due to the aforementioned reasons. > Thoughts? > > David > > > --=20 Kazuho Oku --0000000000007b0eb305963b9b94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David,

Thank you f= or summarizing the high-level options. I think it's very useful to have= this discussion.

Please see my comments below.

2019= =E5=B9=B411=E6=9C=881=E6=97=A5(=E9=87=91) 6:13 David Schinazi <dschinazi.ietf@gmail.com>:
<= /div>
Hi folks,

The con= versation around version ossification has been really interesting since Cup= ertino. But at least for me it's reached a level of complexity that war= rants taking a step back and looking at what we're trying to solve. Her= e's my understanding of where we are:

1) In Cu= pertino there was consensus in the room to do something to mitigate ossific= ation of QUICv1.

2) The solution that folks liked = was to have a concept of alternative versions and alternative salts that ac= t like QUICv1 but are encoded differently over the wire.

3) A concrete proposal for (2) was for servers to have their own set= of (alternative_version, alternative_salt) pairs, then transmit a random p= air from that set to each client (i.e. via transport parameters). The serve= r can then reconstruct the alternative_salt just by seeing the=C2=A0alterna= tive_version.

4) Kazuho proposed a solution (#3= 166) that was both more powerful and more complex: tie the=C2=A0(altern= ative_version, alternative_salt) pair to NEW_TOKEN frames, to allow servers= to generate a unique=C2=A0alternative_salt per client and encode it in the= token.

I dispute the argument = that #3166 is more complex. My view is that #3166 is more powerful and simp= ler than (3) (the PR being #2573).

Reasons:
<= div>* For a server associating one initial salt with one alternative versio= n, #3166 and #2573 are identical with the exception being how the informati= on is carryied (i.e. TP vs. NEW_TOKEN).
* For a client, bundling = the alternative seeds in a NEW_TOKEN makes things simpler, as clients are n= ot required to have a new state that has to be retained across multiple con= nections.


5) After some interesting back and forth on that PR, it became cle= ar that this is a hard problem to solve: this could cause failures if serve= rs forget their token keys, and mitigations for that problem can become dow= ngrade attack vectors

The propo= sal for 3 has this problem. It leads to a failure when a server forgets the= alternative initial salts.
=C2=A0

6) While there was clear WG appetite for (1), = I'm not sure we have consensus to build a more powerful solution like (= 4)

I fear that solving (5) could take some time, w= hich would delay QUICv1. Instead I'd like to propose the following plan= :
a) we take the simpler solution (3) and add that to the spec
b) we take the more powerful/complex solution (5) a turn it into a = QUIC extension

That would allow us to ship QUICv1 = with some level of ossification mitigations without delay.

As stated, the proposed solution for (4) is sim= pler than (3), can be used to implement (3), and also provides a stronger p= rotection for servers certain that they can retain the token unprotection k= eys.

I agree that solving (5) for all parties migh= t be hard, and that we might want to punt that to v2. But, I think we shoul= d adopt (4) than (3) due to the aforementioned reasons.


Thoughts?
=
David




--
Kazuho Oku
--0000000000007b0eb305963b9b94-- From nobody Thu Oct 31 15:08:35 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8CF12086F for ; Thu, 31 Oct 2019 15:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=lowentropy.net header.b=TXGbGPyJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Rnd4gvxs Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErUkc77suixT for ; Thu, 31 Oct 2019 15:08:32 -0700 (PDT) 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 24525120825 for ; Thu, 31 Oct 2019 15:08:32 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 28FC021B01; Thu, 31 Oct 2019 18:08:31 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 31 Oct 2019 18:08:31 -0400 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 :cc:subject:content-type; s=fm3; bh=nccQv7MzHVbqTMcAJSiudP/BqmVU Zk9acWOoTRO3bPA=; b=TXGbGPyJmWfoQaa2bc4qw37dKknkKJpuaj4Dj2q5NhXl l1OzjCF1LzHZkeq1oidc87GtRM8c0NTYI2tDWBnsnyPoM69zneAIDxcbZX1PVJ3W OC5vl3PncIjQsgqLeNe+wujUUcEJFKQLj7QoEdfGz1n7rI+AvvrfxvQ800ehH0Bb KNhW8hSdxzo9uJAHeuevs/sxqBL2hhiI5EB6ZXgs9orHvjuBOswTAlImlwcXff2F TNEzel2S0TBy5zthQv9jmZ3PiLjakypmcL3njfYJiQuw+UWqXOwJqz/sxkO+2PFV oADlI67gjHaAtJ2KzADeASZpUeubFonbLIt7aEQsrw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=nccQv7 MzHVbqTMcAJSiudP/BqmVUZk9acWOoTRO3bPA=; b=Rnd4gvxscNXE7rNH2MmdVd vP/WsCg9ffHNbNcNAurzLFwpwHf7sJ9ezhSTHzo1G6lb+vBrx1GZp0uzmA3dMnyQ 2OdYKnmzOt+m5JzfGkgYpmouXekjjSSwljZsnef7qhZdJmo3YNWqrxQrsFQtwJN2 19aUAG/yXMU+7QiCAMHWaPR/b5rxmrlN9jymu88jELBtTuM1OPXdqIqtvdOrU0QM 4Fhsy2wDHthjAa6uzpntxNii9/Ld+M8gThLHqG/shIx/VCMZC4MmtdjTMVpkuo+F 65hos9mzfuf4d74VEivqB+YaTekcVPnz3e27DEnmYEasES/yqoN4IIwXqnisgrsw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddthedgudehiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmthes lhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9A361E00A3; Thu, 31 Oct 2019 18:08:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <1bc408cb-a189-46ea-a697-b16af89d463d@www.fastmail.com> In-Reply-To: References: <3218A80B-DAFD-43EF-8200-F99C660DF9C9@mnot.net> <5557f717-ae03-46a2-aa9f-54f019a07533@www.fastmail.com> Date: Fri, 01 Nov 2019 09:08:10 +1100 From: "Martin Thomson" To: "Ted Hardie" Cc: "IETF QUIC WG" Subject: Re: Proposed response to the 3GPP Liaison Statement 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: Thu, 31 Oct 2019 22:08:33 -0000 On Fri, Nov 1, 2019, at 00:58, Ted Hardie wrote: > On Wed, Oct 30, 2019 at 6:14 PM Martin Thomson wrote: > > https://tools.ietf.org/html/draft-iab-path-signals-03 seems like it might be a helpful supporting document. > > > If you do choose to cite it, it has been published as RFC 8558, so it > would be best to use that. Oh. The tools link doesn't show that 8558 replaces the iab draft. From nobody Thu Oct 31 15:56:55 2019 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7823E12081A for ; Thu, 31 Oct 2019 15:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 eeZhDCN0X3dn for ; Thu, 31 Oct 2019 15:56:52 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 58A6012026E for ; Thu, 31 Oct 2019 15:56:52 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9VMpj8T008982; Thu, 31 Oct 2019 22:56:49 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=P3zOl3w5XR3LCYrEZdZXGTAPISiXIo/XlymV2r29UQc=; b=hhnUlsQ73HKLPbIKj9KiDgQO/hNMwbVMy/JOA0eK2QHG43IYhWQWpi3TRAA/Ec2uNfP2 QKUINXddLYrKhRWJIHLm+XB9WMtIFLGt2j6MosFtXiTeqeZ0+GfATKpjWDtp+HaqOQ2P lcF8/FGC083GlDcSJNimOIefIIG/9aWc5RV2RYpfkOk6MOYGTXelciLB4nAsGW+KsHue E3f2Qn0PskvWWO27oxCRGkfsGp3BfDxuXR/KPMPHXrIySE8/11r9SkIyvQI/w9SUKbuE QoHBr0areLV28E6RtK/S+t9pxODVeZTn2bdq5RrJWfJvA9PrnuQORmW5u74RU0BcjN0f Kg== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2w04e2h4q0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 22:56:49 +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 x9VMlH3L012375; Thu, 31 Oct 2019 18:56:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2vxwfpun7r-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 18:56:48 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 31 Oct 2019 18:56:44 -0400 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, 31 Oct 2019 18:56:43 -0400 From: "Salz, Rich" To: David Schinazi , "Lubashev, Igor" CC: Ted Hardie , IETF QUIC WG , "Martin Thomson" Subject: Re: Proposed response to the 3GPP Liaison Statement Thread-Topic: Proposed response to the 3GPP Liaison Statement Thread-Index: AQHVj4f5UuU8qDVDLkC38Xwn+LRYNKd0NOMAgADViwCAAEeKgIAALMyA///fGYA= Date: Thu, 31 Oct 2019 22:56:43 +0000 Message-ID: References: <3218A80B-DAFD-43EF-8200-F99C660DF9C9@mnot.net> <5557f717-ae03-46a2-aa9f-54f019a07533@www.fastmail.com> <614379f7e12f46c6b38b7928e999cbab@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.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.7] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-31_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=799 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910310226 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-31_08:2019-10-30,2019-10-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 phishscore=0 spamscore=0 malwarescore=0 suspectscore=0 clxscore=1011 bulkscore=0 priorityscore=1501 adultscore=0 impostorscore=0 mlxlogscore=780 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910310227 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, 31 Oct 2019 22:56:54 -0000 TWF5YmUgd2Ugc2hvdWxkIHN1Z2dlc3QgdGhhdCB0aGV5IHdyaXRlIGFuIEktRCBmb3Igd2hhdCB0 aGV5IHRoaW5rIHRoZWlyIHJlcXVpcmVtZW50cyBhcmU/DQoNCg0K