Re: [Masque] Adoption call for "Requirements for a MASQUE Protocol to Proxy IP Traffic"

Eric Kinnear <ekinnear@apple.com> Sat, 26 September 2020 23:54 UTC

Return-Path: <ekinnear@apple.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729353A0CCB for <masque@ietfa.amsl.com>; Sat, 26 Sep 2020 16:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.297
X-Spam-Level:
X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6tuo8Mm26-Se for <masque@ietfa.amsl.com>; Sat, 26 Sep 2020 16:54:40 -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 679513A0B66 for <masque@ietf.org>; Sat, 26 Sep 2020 16:54:40 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 08QNnbAX047800; Sat, 26 Sep 2020 16:54:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=4wZmwurUT17mOdlGV/iV6s2qwbYoQ0ex9PPYYSFSBtk=; b=EBC7P5DDXEFyEezQlLJ9iqX3pVvO4xd1ypWkFGfzE9rY1RZqDFR/wIS41ROvVXdMWDHl hALSqUNM6kNOtCFEun1nmLR5VyyIO9IzKbJ8lPkq9Jvjlh6IozUczCHIVFgfrKueCRHv z6857Tow417PnGrMtdRhT16GCDxSnz7Lir+zbgAdiM2RuZo2KfMPb05I6ATikaOI/Sgm 0u/Wxq5TkRSxFTqKsfbp9wAWDzBjbCWjGT59FbYv3MP7GufU53Gw9wUXJ+1dQaQxtsW1 ajVsUEgC4X1gAQyjbylaeSn+dsVewO6SnaIOju0CSRMOwUwmmzn2SwMX87xtHgqhGncP 7Q==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp03.apple.com with ESMTP id 33t261j4sf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 26 Sep 2020 16:54:37 -0700
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QHA00O28IF13Z60@rn-mailsvcp-mta-lapp04.rno.apple.com>; Sat, 26 Sep 2020 16:54:37 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QHA00500I4D6400@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sat, 26 Sep 2020 16:54:37 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 571151732831e0c9b40d8f51b88ffdc1
X-Va-E-CD: 192dfd9c331d7b45c038e02184e60345
X-Va-R-CD: bebc03283255d4dbe0e5880ab2dc04b7
X-Va-CD: 0
X-Va-ID: d53fe2a5-2be7-4116-b640-1375844d41c1
X-V-A:
X-V-T-CD: 571151732831e0c9b40d8f51b88ffdc1
X-V-E-CD: 192dfd9c331d7b45c038e02184e60345
X-V-R-CD: bebc03283255d4dbe0e5880ab2dc04b7
X-V-CD: 0
X-V-ID: e69b9c63-9f73-4e6b-b8de-83733a301e25
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-26_21:2020-09-24, 2020-09-26 signatures=0
Received: from [17.234.14.153] (unknown [17.234.14.153]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QHA0057FIEYIZ00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sat, 26 Sep 2020 16:54:36 -0700 (PDT)
From: Eric Kinnear <ekinnear@apple.com>
Message-id: <A48AB057-3578-4DFF-A6D2-C3B15D171DE9@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_FB9114F7-9753-4BC8-9044-3E263EC9C9CF"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.61\))
Date: Sat, 26 Sep 2020 16:54:34 -0700
In-reply-to: <b1ff33a91c1c2f7f57c025bfd7a3700de394b37d.camel@ericsson.com>
Cc: Chris Wood <caw@heapingbits.net>
To: "masque@ietf.org" <masque@ietf.org>
References: <4f83a742-e6c3-4aef-a26b-1801ecf19cdf@www.fastmail.com> <d360df8c2870acdc4b312ab3f5f9031610a24703.camel@ericsson.com> <CAKKJt-fbdUgpCuBZ57sU+Nv=qB8+zBRCfjqUZ7KneZrEpxu0fQ@mail.gmail.com> <CAPDSy+7QpSUdpLzQFxb0HULgQrGL-vy3JJUP0pNfu=Q-hR6Zqw@mail.gmail.com> <ac53fcc2759c86fa3d4b108b68776b4fa571fa00.camel@ericsson.com> <d60f8c28-697b-4203-bc7e-58b59d8492f9@www.fastmail.com> <b1ff33a91c1c2f7f57c025bfd7a3700de394b37d.camel@ericsson.com>
X-Mailer: Apple Mail (2.3654.0.3.2.61)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-26_21:2020-09-24, 2020-09-26 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/0kOfSoKLIbVCJ-v9Hhy-TicbxGU>
Subject: Re: [Masque] Adoption call for "Requirements for a MASQUE Protocol to Proxy IP Traffic"
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Sep 2020 23:54:42 -0000

Hi all, 

Thanks to everyone who has responded to this call for adoption as a support document. We have both positive and negative viewpoints being expressed — thanks for the valuable discussion so far. 
Ideally, we’d like to see a few more people chime in with their views and the discussion to continue towards a position from which we can move forwards.

To aid in that, we are extending the adoption call for an additional two weeks, ending October 7.
We’re especially interested in focus on what should be covered by the requirements document and if this document can be used as a starting point to get there.

Thanks, 
Eric and Chris


> On Sep 25, 2020, at 12:32 AM, Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hi Chris,
> 
> Understood. My personal view is that this adoption call was unnecessary rushing
> things and that we don't know if the document is a suitable starting point until
> we have had some more discussion. 
> 
> But lets get on discussing its content rather than the formalia. 
> 
> Cheers
> 
> Magnus
> 
> On Thu, 2020-09-24 at 05:04 -0700, Christopher Wood wrote:
>> Magnus,
>> 
>> As noted in the kickoff email, the purpose was to "start an adoption call for
>> this document in its current form as a starting point." We expect the document
>> contents may change as we work towards consensus, and that's fine! We're just
>> getting started.
>> 
>> Best,
>> Chris
>> 
>> On Mon, Sep 21, 2020, at 3:00 AM, Magnus Westerlund wrote:
>>> David,
>>> 
>>> I hope that we can agee on that if adopting this document at this stage
>>> there
>>> will be no implication on any of the content in document having WG
>>> consensus. I
>>> rather see that the WG would discuss the use cases and we have a document
>>> where
>>> the general content would have WG consensus when adopting it. 
>>> I think adopting a document just becasue we know we are going to need it is
>>> rushing thing for the wrong reasons. I rather adopt a document in 3 months
>>> time
>>> where we are agreeing more on the content. 
>>> 
>>> 
>>> Cheers
>>> 
>>> Magnus
>>> 
>>> 
>>> 
>>> On Fri, 2020-09-18 at 09:45 -0700, David Schinazi wrote:
>>>> Thank you for comments, Mirja, Spencer, and Magnus!
>>>> 
>>>> If I may summarize them in the following bullet points:
>>>> - we should reach WG consensus on use-cases
>>>> - we should clarify the last use-case
>>>> - we should clarify which requirement relates to which use-case
>>>> 
>>>> (There were also detailed comments on individual requirements that
>>>> would be better discussed on individual threads, or GitHub issues)
>>>> 
>>>> I absolutely agree with these bullet points. As per our charter, the
>>>> goal of this entire draft is for us to reach WG consensus on
>>>> use-cases and requirements for IP proxying, before the WG starts
>>>> work on a solution. However, none of those comments justify
>>>> delaying adoption of the document. The call for adoption is there
>>>> to ensure there is WG interest in the draft, and that folks are willing
>>>> to review and comment - which your messages indicate! Adopting
>>>> the draft will actually facilitate answering the three points above,
>>>> since WG consensus is better reached on parts of WG documents,
>>>> as opposed to individual submissions.
>>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>> 
>>>> On Fri, Sep 18, 2020 at 8:43 AM Spencer Dawkins at IETF <
>>>> spencerdawkins.ietf@gmail.com> wrote:
>>>>> So, just to start the discussion Magnus said we need to have (and I
>>>>> agree
>>>>> that we need to have it, whether before, or after, adoption), 
>>>>> 
>>>>> On Fri, Sep 18, 2020 at 3:27 AM Magnus Westerlund <
>>>>> magnus.westerlund=40ericsson.com@dmarc.ietf.org> wrote:
>>>>> 
>>>>> Which of these requirements (in 
>>>>> https://www.ietf.org/id/draft-cms-masque-ip-proxy-reqs-01.txt)
>>>>> 
>>>>> 3.1.  IP Session Establishment
>>>>> 3.2.  Proxying of IP packets
>>>>> 3.3.  Maximum Transmission Unit
>>>>> 3.4.  IP Assignment
>>>>> 3.5.  Route Negotiation
>>>>> 3.6.  Identity
>>>>> 3.7.  Transport Security
>>>>> 3.8.  Authentication
>>>>> 3.9.  Reliable Transmission of IP Packets
>>>>> 3.10.  Flow Control
>>>>> 3.11.  Indistinguishability
>>>>> 3.12.  Support HTTP/2 and HTTP/3
>>>>> 3.13.  Multiplexing
>>>>> 3.14.  Load balancing
>>>>> 3.15.  Extensibility
>>>>> 
>>>>> belongs to each use case?
>>>>> 
>>>>>> 2.1.  Consumer VPN
>>>>>> 2.2.  Point to Point Connectivity
>>>>>> 2.3.  Point to Network Connectivity
>>>>>> 2.4.  Network to Network Connectivity
>>>>> 
>>>>> (I'm happy to have this conversation in Github, but Magnus said we
>>>>> needed to
>>>>> have it here, so I'm following his excellent leadership)
>>>>> 
>>>>> Best,
>>>>> 
>>>>> Spencer 
>>> 
>>> -- 
>>> Cheers
>>> 
>>> Magnus Westerlund 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> Networks, Ericsson Research
>>> ----------------------------------------------------------------------
>>> Ericsson AB                 | Mobile +46 73 0949079
>>> Torshamnsgatan 23           |
>>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>>> ----------------------------------------------------------------------
>>> 
>>> 
>>> 
> -- 
> Cheers
> 
> Magnus Westerlund 
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Mobile +46 73 0949079
> Torshamnsgatan 23           |
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>
> ----------------------------------------------------------------------
> 
> 
> -- 
> Masque mailing list
> Masque@ietf.org <mailto:Masque@ietf.org>
> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>