From nobody Tue Jun 5 07:38:12 2018 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C21D8131002; Tue, 5 Jun 2018 07:38:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152820948472.19113.16691896932530885540@ietfa.amsl.com> Date: Tue, 05 Jun 2018 07:38:04 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-minset-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:38:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : A Minimal Set of Transport Services for End Systems Authors : Michael Welzl Stein Gjessing Filename : draft-ietf-taps-minset-04.txt Pages : 46 Date : 2018-06-05 Abstract: This draft recommends a minimal set of Transport Services offered by end systems, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-minset-04 https://datatracker.ietf.org/doc/html/draft-ietf-taps-minset-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 5 07:39:18 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C19F1310AB for ; Tue, 5 Jun 2018 07:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qK1FD_WPY7Xm for ; Tue, 5 Jun 2018 07:39:11 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 C64231310B0 for ; Tue, 5 Jun 2018 07:39:10 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fQD76-0001IE-Cn; Tue, 05 Jun 2018 16:39:08 +0200 Received: from [160.80.82.29] by mail-mx03.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fQD75-0005Ru-No; Tue, 05 Jun 2018 16:39:08 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: Date: Tue, 5 Jun 2018 16:39:09 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tommy Pauly X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 160.80.82.29 is neither permitted nor denied by domain of ifi.uio.no) client-ip=160.80.82.29; envelope-from=michawe@ifi.uio.no; helo=[160.80.82.29]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.050, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8C49AFC5C504C09DF1ACD62B606F41EFA8C6E38F Archived-At: Subject: Re: [Taps] Minset WGLC Review X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:39:16 -0000 Hi, Thanks a lot for your comments! > On May 31, 2018, at 6:17 PM, Tommy Pauly wrote: >=20 > Hello TAPS, >=20 > I=E2=80=99ve just done a read through of the current minset draft. = Overall, looks good! I have a few nits, but these can all be addressed = in the next revision: >=20 > - The first sentence of the abstract is a bit hard to parse for = someone who isn=E2=80=99t coming from the context of the working group: >=20 > "This draft recommends a minimal set of IETF Transport Services > offered by end systems supporting TAPS, and gives guidance on > choosing among the available mechanisms and protocols.=E2=80=9D >=20 > We use the term =E2=80=9CTAPS=E2=80=9D as a well-known term here, = which I don=E2=80=99t think it is necessarily. In our = architecture/API/implementation documents we=E2=80=99re trying to avoid = using TAPS as term, and using Transport Services more instead. That=E2=80=99= s not to say we should remove the usage of TAPS here, but perhaps do the = Transport Services (TAPS) definition somewhere up-front. Also, why is = this is minimal set of =E2=80=9CIETF" services? I assume this means =E2=80= =9Ca minimal set of Transport Services defined in IETF protocols=E2=80=9D,= but it feels heavy on the jargon. Done (given that this is an IETF document, the fact that it=E2=80=99s = based upon IETF-defined protocols is the default assumption, not an = exception; moreover, the abstract also says that it=E2=80=99s based on = RFC 8303, and so this IETF reference seems unnecessary). > - Same point of defining =E2=80=9CTAPS=E2=80=9D for the = introduction.=E2=80=99 Done (removed =E2=80=9CTAPS=E2=80=9D everywhere) > - Introduction: >=20 > "For example, it does not help an > application that talks to a middleware=E2=80=A6=E2=80=9D >=20 > Does the application talk to =E2=80=9Ca middleware=E2=80=9D? I = understand the use of =E2=80=9Cthe middleware=E2=80=9D later, but it = seems to me that middleware should have the same usage as = =E2=80=9Csoftware=E2=80=9D, and we don=E2=80=99t use =E2=80=9Ca = software=E2=80=9D generally. Changed to =E2=80=9Clibrary=E2=80=9D > - Section 3 >=20 > Personally, I=E2=80=99d add an Oxford comma here: "Based on the = categorization, reduction and discussion=E2=80=A6=E2=80=9D to "Based on = the categorization, reduction, and discussion=E2=80=A6=E2=80=9D Done > - Section 3.1 >=20 > Is there a reason we use underscore style for the parameters? = =E2=80=9CChecksum_coverage=E2=80=9D, =E2=80=9CConfig_msg_prio=E2=80=9D, = etc. While I understand that these may be the code symbols you use in a = C program, you=E2=80=99re not using this style or these symbols = elsewhere, and it would be clearer to write out =E2=80=9CConfigure = message priority=E2=80=9D, etc. It will also look more palatable to more = modern language styles =3D) Agree, done - note that these are only a handful of occurrences = (actually only the two you mention + what is now =E2=80=9CEarly message = timeout notification=E2=80=9D, as all others refer to other documents = and hence carry the name that=E2=80=99s used there. Cheers, Michael From nobody Tue Jun 5 07:41:06 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BE71310BD for ; Tue, 5 Jun 2018 07:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Jv0GIS5db8VT for ; Tue, 5 Jun 2018 07:41:01 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 70C211310BE for ; Tue, 5 Jun 2018 07:41:01 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fQD8t-000AQH-BJ for taps@ietf.org; Tue, 05 Jun 2018 16:40:59 +0200 Received: from [160.80.82.29] by mail-mx03.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fQD8r-0005pu-Qm for taps@ietf.org; Tue, 05 Jun 2018 16:40:59 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 5 Jun 2018 16:41:01 +0200 References: <152820948472.19113.16691896932530885540@ietfa.amsl.com> To: "taps@ietf.org" In-Reply-To: <152820948472.19113.16691896932530885540@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 160.80.82.29 is neither permitted nor denied by domain of ifi.uio.no) client-ip=160.80.82.29; envelope-from=michawe@ifi.uio.no; helo=[160.80.82.29]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.050, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B3519C45597738EFE4C2B54E33DC941D8CF6B5AB Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-minset-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:41:04 -0000 Hi all, This update addresses the comments by Theresa (I started answering in = detail regarding the nits, but then deleted my email when I realized = that I=E2=80=99m simply saying =E2=80=9Cok, done=E2=80=9D everywhere) = and Tommy (see my separate email to him). Thanks to both - and the = others who read the previous version! Cheers, Michael > On Jun 5, 2018, at 4:38 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Services WG of the IETF. >=20 > Title : A Minimal Set of Transport Services for End = Systems > Authors : Michael Welzl > Stein Gjessing > Filename : draft-ietf-taps-minset-04.txt > Pages : 46 > Date : 2018-06-05 >=20 > Abstract: > This draft recommends a minimal set of Transport Services offered by > end systems, and gives guidance on choosing among the available > mechanisms and protocols. It is based on the set of transport > features in RFC 8303. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-taps-minset-04 > https://datatracker.ietf.org/doc/html/draft-ietf-taps-minset-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-minset-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Jun 5 08:12:29 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CFE1310D7; Tue, 5 Jun 2018 08:12:27 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 R6eYvxxs77Lo; Tue, 5 Jun 2018 08:12:26 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13741310DA; Tue, 5 Jun 2018 08:12:25 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id h7-v6so1742103qkm.0; Tue, 05 Jun 2018 08:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:embedded-html; bh=sCH6AV0I31BbqHSVy1YnmrF9SgbhB1GBc0PpYgIApwc=; b=fOZwMmULUdcHNjtyEF7lqdsx6mhx7OVaGA6EriRGBQWyvjNRKLSsqs4o+8KhTPoVt7 wD4SvlEMnico/JEghi5+594/Xj3FGDdQmLTlOPotKyIDLbGTN72HGX1VM+M4Wv+6wYUV L4eW/yM8Pr3UEYuSXpRyeqB5Q48uORKogY7Vqdm3thBpzVjyeVeWUacGFYvEQfri1vhN L499j79VrjjP458o+VJbY+5RZVVi5cUdM4AaG3YCwoDvFk8PtMNGha8Udq15ZJgGLQUJ mduAI5PoWOG2l4JXVVLvTdOxZNpd1ii05kUQARmVwhV+hidycDeobSTv6gV0Ts7BHlC3 4gXg== 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:date:message-id:in-reply-to :references:mime-version:embedded-html; bh=sCH6AV0I31BbqHSVy1YnmrF9SgbhB1GBc0PpYgIApwc=; b=ibFdaG0PymC7bPBiBQN30IDowuq2YKEF/UoREKcrv2V2Kwe9qDBJZ5KDXEq/JJ/r0V lNUsKXSGotuEnkTqMoNkqE1OL3CpnbV0knYzFdMumSJWsAg3VbVR49ZtCJcriv0uCaAK 5B4sCmHGbWgRrR1mKal2b1GRYCMYAMg0Sx3AixhkApd7o9IVFNNlvYMSJEyrbVf5+qMS VjcQ+p08lmVI9hUEbPUdL9Z2Kjk/tpY9jZ+UDOZ0YI09+casesf5T9+JZCFeYaVdiICj aNMBZqOqmeMHPFfMkT/cN/ESedE91pqgXcZRHp/mu0vEIqybSJwL/pN31ChXxwomieH8 pdtQ== X-Gm-Message-State: APt69E2gcItuJQDcJQa3DUvBMj2jdC8/dKf2IFM0xFrz6I/CxqeiHRhl Q44Y6kcC7wZY6fAEqfDc+VBehFdq X-Google-Smtp-Source: ADUXVKLNVmzdgPjhItvn0ckB9gW7AdUDBxJ4LexKzndwr6ZAOwVtwWBQsYPcxM2nQl22Ni51y7wfJw== X-Received: by 2002:a37:c894:: with SMTP id t20-v6mr23183809qkl.372.1528211544348; Tue, 05 Jun 2018 08:12:24 -0700 (PDT) Received: from [172.19.35.174] ([2001:4878:a000:3000:8425:8efc:b975:dd54]) by smtp.gmail.com with ESMTPSA id b71-v6sm25266228qkj.89.2018.06.05.08.12.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jun 2018 08:12:22 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Cc: draft-ietf-taps-minset@ietf.org, "Theresa Enghardt" Date: Tue, 05 Jun 2018 11:12:20 -0400 X-Mailer: MailMate (1.11.2r5479) Message-ID: In-Reply-To: References: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> <3F4C0CD4-9D7A-42AD-9A1D-A19C47321E69@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B83D796D-5EE2-4A48-9220-177738F94E97_=" Embedded-HTML: [{"HTML":[606, 2169], "plain":[223, 1222], "uuid":"9C8C9BC5-0107-40CD-89E9-C9B1B3328D54"}] Archived-At: Subject: Re: [Taps] working group last call for draft-ietf-taps-minset X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 15:12:28 -0000 --=_MailMate_B83D796D-5EE2-4A48-9220-177738F94E97_= Content-Type: text/plain; format=flowed WGLC for this doc is concluded and it is clear the document should be published. Theresa Enghardt will be the document shepherd. Thanks to the authors & reviewers! --aaron On 30 May 2018, at 10:51, Aaron Falk wrote: > Reminder: working group last call concludes next Monday. Please > review > this doc and send comments &/or 'ready to publish'. > > --aaron > > On Thu, May 17, 2018 at 11:30 AM Aaron Falk > wrote: > >> I've received a request to extend the WGLC for this doc. We'll accept >> comments until June 4th. > >> --aaron > >> On 10 May 2018, at 10:52, Aaron Falk wrote: > >> Dear TAPS working group, > >> As discussed in London, it's time to last call >> draft-ietf-taps-minset-03 >> . > >> A Minimal Set of Transport Services for TAPS Systems >> draft-ietf-taps-minset-03 > >> Abstract > >> This draft recommends a minimal set of IETF Transport Services >> offered by end systems supporting TAPS, and gives guidance on >> choosing among the available mechanisms and protocols. It is >> based >> on the set of transport features in RFC 8303. > >> Please read the draft and send comments to the list. This document is >> planned to be an Informational RFC. Statements along the lines of >> 'ready to >> publish' are also welcome. > >> WGLC will conclude in two weeks on May 24, 2018. > >> --aaron (for the chairs) --=_MailMate_B83D796D-5EE2-4A48-9220-177738F94E97_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">WGLC for this doc is concluded and it is clear the documen= t should be published. Theresa Enghardt will be the document shepherd. = Thanks to the authors & reviewers!

--aaron

On 30 May 2018, at 10:51, Aaron Falk wrote:

Reminder: working group last call concludes next Monday.=C2= =A0 Please review this doc and send comments &/or 'ready to publi= sh'.

--aaron

On Thu, May 17, 2018 at 11:30 AM Aaron Falk <aaron.falk@gmail.com> wrote:<= br>

I've received a request to extend the WGLC for this d= oc. We'll accept comments until June 4th.

--aaron

On 10 May 2018, at 10:52, Aaron Falk wrote:

Dear TAPS working group,

As discussed in London, it's time to last call draft-ietf-taps-minset-03.

          A Minimal Set of=
 Transport Services for TAPS Systems
                       draft-ietf-taps-minset-03

Abstract

   This draft recommends a minimal set of IETF Transport Services
   offered by end systems supporting TAPS, and gives guidance on
   choosing among the available mechanisms and protocols.  It is based
   on the set of transport features in RFC 8303.

Please read the draft and send comments to the list. This= document is planned to be an Informational RFC. Statements along the li= nes of 'ready to publish' are also welcome.

WGLC will conclude in two weeks on May 24, 2018.

--aaron (for the chairs)

--=_MailMate_B83D796D-5EE2-4A48-9220-177738F94E97_=-- From nobody Fri Jun 8 15:29:45 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5839130EC7 for ; Fri, 8 Jun 2018 15:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 l2due-w0i9zb for ; Fri, 8 Jun 2018 15:29:42 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 6BF6C130DC2 for ; Fri, 8 Jun 2018 15:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1528496982; x=2392410582; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VmKe7MptTjjtRyynjcm0MZYnsHcfgEhJOwt+D3m/fYI=; b=0Ag5WhsaPIqxORcWqPY/ivlKIMu+3TUT0bpPlLb1GxTe4PcAO/L2Oorlg3OT5rpe LbUOdPjBZLAq0qO4B0okO80Bzg4TXbEnuwbvA2Zeoprb62bbuQjFW+ZN9SNsj6+M 0FhXftMAzVDnoUnek2l6GUeVjDeJnHzxFpw2/jgOz3cBzgd2xxwGx60eQyxohnXp GIgDhbiqWBNbZlp9iBqeTOqPqZTdVQJahmfUZPoU+EFhAlZSoJlKz+ZBNwuoB7t8 Jkv2R58VhiY8spfWlmGL1+RkaUl0l8LheSGyRm2oIWveiamfo5zV8igl7AK1QBvY KI6ifdUr7N2pzeG5Stte/g==; X-AuditID: 11973e13-62dff7000000242c-68-5b1b035511bb Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 51.48.09260.5530B1B5; Fri, 8 Jun 2018 15:29:42 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ar1112h5syT3rQSujhSZtA)" Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0PA0004U5ZTHMRC0@ma1-mtap-s02.corp.apple.com> for taps@ietf.org; Fri, 08 Jun 2018 15:29:41 -0700 (PDT) Received: from [17.234.184.168] (unknown [17.234.184.168]) by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0PA0006YCZTEIN30@ma1-mmpp-sz09.apple.com> for taps@ietf.org; Fri, 08 Jun 2018 15:29:41 -0700 (PDT) X-Va-A: X-Va-T-CD: 2ae3cb41e2a452a17e83043029b284de X-Va-E-CD: a671d8d53df5bce6bdbbc5bac83a63c3 X-Va-R-CD: b82f208929c3146e3f77363fe13b6eae X-Va-CD: 0 X-Va-ID: e147f199-0bfd-42e7-882f-6c559f83b40b X-V-A: X-V-T-CD: 5808c5f95406ec7719a15f5c3784581a X-V-E-CD: a671d8d53df5bce6bdbbc5bac83a63c3 X-V-R-CD: b82f208929c3146e3f77363fe13b6eae X-V-CD: 0 X-V-ID: 52ffc7c0-41e8-4e1f-ac4e-eb373a483080 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-08_10:,, signatures=0 Sender: tpauly@apple.com From: Tommy Pauly Message-id: <1C14F32A-3ADC-4D35-B800-091697E83AD6@apple.com> Date: Fri, 08 Jun 2018 15:29:09 -0700 To: taps WG X-Mailer: Apple Mail (2.3445.100.11) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUiqOHDphvGLB1tcHY/j8WdGAdGjyVLfjIF MEZx2aSk5mSWpRbp2yVwZfz9f5O14Lt8xc+lP5gaGJ9JdzFyckgImEgs3/2IFcQWEtjHJPHr jxeIzSsgKPFj8j0WEJtZIEziYUMjUxcjF1DNYSaJmd+XskE4S5kkfnZPYoOYxC7x59cOFghb W2LBiwvsMPbz9plsMPavRVOYIGwuiQVbT7NC2LoSR3bMgIqzSaw/sQTK1pI4tfkIC4x9rP0r UD0HmN13KAIizClx/stEqFU6EjPnb2CGsLMlZn9dxwJSLiwgIbF5TyJImE1AReL4N4gSYQFT iTc/JjND/GsjMXflLbAxLAKqEt8mPQC7QERAWuLNnNNQI1Uk9j16yjaBUWoWUhDNQgqiWUDb mAXUJaZMyYUIa0s8eXeBFcJWk1j4exETsvgCRrZVjEK5iZk5upl5pnqJBQU5qXrJ+bmbGEHR Ot1OeAfj6VVWhxgFOBiVeHgbmqSihVgTy4orcw8xSnOwKInzJnGIRwsJpCeWpGanphakFsUX leakFh9iZOLglGpgXBeW+OHZ3ul22tflExeW/buq/avz9rSe5svP/Zpr351w65FNKpVUZH4Z Usi0snWaW093gMLEi/wzpP3jXh/sEGt7OOHQLY0vx57zNtSrXNv+a0eD3koeJqFoA8sfi0Le N3Hf+arRWf8l/KD2xcsa+zbY9rmfNjZz5Puh9nZD7MfDDHGGlsdXKrEUZyQaajEXFScCAL23 CNS3AgAA Archived-At: Subject: [Taps] New Transport Networking APIs in iOS 12 beta X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 22:29:44 -0000 --Boundary_(ID_ar1112h5syT3rQSujhSZtA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hello TAPS! This week we released Network.framework, a new set of transport APIs, as = part of the beta for iOS 12 and macOS Mojave. This API provides support for connections and listeners using TCP, UDP, = TLS, and DTLS; connecting by name or service, with happy eyeballs = support for addresses, interfaces, and protocols (for proxies, etc). = This provides our basis for =E2=80=9Cpost-sockets=E2=80=9D API work. As = we define as a working group more of the full TAPS API vision for = protocol agility, we'd like on add that support to this framework.=20 Video of the presentation: https://developer.apple.com/videos/play/wwdc2018/715/ = Sample implementation of netcat: = https://developer.apple.com/documentation/network/implementing_netcat_with= _network_framework = Swift and C API: https://developer.apple.com/documentation/network = If you are an iOS or macOS developer, please try out the APIs! Either = way, we=E2=80=99d love for everyone to take a read through the API and = give feedback on how we can continue to evolve things towards a = post-sockets and fully TAPS model. Note that on iOS and tvOS, this = framework is currently using a user-space networking stack instead of = sockets when applicable. Best, Tommy= --Boundary_(ID_ar1112h5syT3rQSujhSZtA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hello= TAPS!

This week we = released Network.framework, a new set of transport APIs, as part of the = beta for iOS 12 and macOS Mojave.

This API provides support for = connections and listeners using TCP, UDP, TLS, and DTLS; connecting by = name or service, with happy eyeballs support for addresses, interfaces, = and protocols (for proxies, etc). This provides our basis for = =E2=80=9Cpost-sockets=E2=80=9D API work. As we define as a working group = more of the full TAPS API vision for protocol agility, we'd like on add = that support to this framework. 

Video of the = presentation:
https://developer.apple.com/videos/play/wwdc2018/715/
=

Sample = implementation of netcat:
https://developer.apple.com/documentation/network/implementing_= netcat_with_network_framework

Swift and C API:
https://developer.apple.com/documentation/network

If you are an iOS or = macOS developer, please try out the APIs! Either way, we=E2=80=99d love = for everyone to take a read through the API and give feedback on how we = can continue to evolve things towards a post-sockets and fully TAPS = model. Note that on iOS and tvOS, this framework is currently using a = user-space networking stack instead of sockets when = applicable.

Best,
Tommy
= --Boundary_(ID_ar1112h5syT3rQSujhSZtA)-- From nobody Sat Jun 9 11:38:15 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A0E130F3A for ; Sat, 9 Jun 2018 11:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, 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 gjrEehDfXBIY for ; Sat, 9 Jun 2018 11:38:10 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D94130F32 for ; Sat, 9 Jun 2018 11:38:10 -0700 (PDT) Received: from [172.20.6.67] (unknown [38.64.177.126]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 057FD721E2822; Sat, 9 Jun 2018 20:38:05 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Michael Tuexen In-Reply-To: <1C14F32A-3ADC-4D35-B800-091697E83AD6@apple.com> Date: Sat, 9 Jun 2018 14:38:03 -0400 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: <63A71B2E-96E4-402A-89E2-667DDF8B1D08@lurchi.franken.de> References: <1C14F32A-3ADC-4D35-B800-091697E83AD6@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Taps] New Transport Networking APIs in iOS 12 beta X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 18:38:14 -0000 > On 8. Jun 2018, at 18:29, Tommy Pauly wrote: >=20 > Hello TAPS! >=20 > This week we released Network.framework, a new set of transport APIs, = as part of the beta for iOS 12 and macOS Mojave. >=20 > This API provides support for connections and listeners using TCP, = UDP, TLS, and DTLS; connecting by name or service, with happy eyeballs = support for addresses, interfaces, and protocols (for proxies, etc). = This provides our basis for =E2=80=9Cpost-sockets=E2=80=9D API work. As = we define as a working group more of the full TAPS API vision for = protocol agility, we'd like on add that support to this framework.=20 Hi Tommy, great news! Is there also a possibility to add new transports to the framework, like SCTP or QUIC? Best regards Michael >=20 > Video of the presentation: > https://developer.apple.com/videos/play/wwdc2018/715/ >=20 > Sample implementation of netcat: > = https://developer.apple.com/documentation/network/implementing_netcat_with= _network_framework >=20 > Swift and C API: > https://developer.apple.com/documentation/network >=20 > If you are an iOS or macOS developer, please try out the APIs! Either = way, we=E2=80=99d love for everyone to take a read through the API and = give feedback on how we can continue to evolve things towards a = post-sockets and fully TAPS model. Note that on iOS and tvOS, this = framework is currently using a user-space networking stack instead of = sockets when applicable. >=20 > Best, > Tommy > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Sat Jun 9 13:54:54 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88010130F7C for ; Sat, 9 Jun 2018 13:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 4WtYSB86Rz7q for ; Sat, 9 Jun 2018 13:54:50 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 EAAEB130E4C for ; Sat, 9 Jun 2018 13:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1528577689; x=2392491289; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zMJMjbFcLCPE0P1PaLnIOFzXLAldlJusKqzLy5nFYlA=; b=qrz5EYiAoip6C1LntDQWIH1tkV4fzmF1eCyPPagximWw32hH4+7pQmg0hcaeL2pE B/bUM48toy9iIYQ3E8DI3NQ3gU0ci6hY/RG1VmVxEaBcdAkfjZJa+3BY6FmPNbqF XEzQ11HueH86ihYaX2zNrfEuYbQ/VL28ARpLxY2PUL3ssx9zC2BdUojFiKc8quOj wO/XBEb5D+1HOc4Lb8DOkYinfcFYwHZfhEJB98AEhjtLwge8on8bOWAR7KY56DAc uGuEZl58TlxmYIR1LafJYFvSOZTwDviinOV6M9E/DY4/EjFoxlSujHxopzSo2dK1 hAQ61/ZZSur+jVokfUTokw==; X-AuditID: 11973e16-6f1ff7000000740c-9e-5b1c3e98de08 Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 15.CF.29708.99E3C1B5; Sat, 9 Jun 2018 13:54:49 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 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.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0PA200F1IQ3CBI50@ma1-mtap-s01.corp.apple.com>; Sat, 09 Jun 2018 13:54:48 -0700 (PDT) Received: from [17.234.78.219] (unknown [17.234.78.219]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0PA20033RQ3B4D40@nwk-mmpp-sz09.apple.com>; Sat, 09 Jun 2018 13:54:48 -0700 (PDT) X-Va-A: X-Va-T-CD: bc857b5a723901ec4a5cc604c5f83aa4 X-Va-E-CD: 36910ef1a06ecb6cf7c143959f25f86c X-Va-R-CD: 523f5b9545ee69ad6998eb029acd3ffa X-Va-CD: 0 X-Va-ID: f65a641e-7378-4b0a-a927-07a23cf7f31b X-V-A: X-V-T-CD: d0525724cfd3263b084184409139b675 X-V-E-CD: 36910ef1a06ecb6cf7c143959f25f86c X-V-R-CD: 523f5b9545ee69ad6998eb029acd3ffa X-V-CD: 0 X-V-ID: 51fbfca9-0f7a-46a3-89d7-97330b5b3dc5 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-09_10:,, signatures=0 Sender: tpauly@apple.com From: Tommy Pauly X-Mailer: iPhone Mail (16A5288q) In-reply-to: <63A71B2E-96E4-402A-89E2-667DDF8B1D08@lurchi.franken.de> Date: Sat, 09 Jun 2018 13:54:46 -0700 Cc: taps WG Content-transfer-encoding: quoted-printable Message-id: <268D7E06-1D1D-4F70-9336-98EAF1BB5605@apple.com> References: <1C14F32A-3ADC-4D35-B800-091697E83AD6@apple.com> <63A71B2E-96E4-402A-89E2-667DDF8B1D08@lurchi.franken.de> To: Michael Tuexen X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUiqOHDqjvTTiba4PBPLYuLTUsYLe7EODB5 LFnyk8ljQ8sOpgCmKC6blNSczLLUIn27BK6MCcsXsRScFK2YtVa4gfGrYBcjJ4eEgInE8+9b mLsYuTiEBPYxSVzYMZUNJMErICjxY/I9li5GDg5mAXWJKVNyIWo2MEncmnWFBcKZyCSx88FD FohJ7BJ/fu2AsrUlnrzpZIaxT99phYsf2HWTDcLmkliw9TQrhK0r0Xr5HDuEzSax/sQSJghb S+LO8W9wdk/rH2YYu23Cc6g5nBLnv0yE6tWROHG4A2pXtsSym7eYQB4QFpCQ2LwnEcJ0kGja IQZSwSagInH82waoiQoS++8tAZvCKeAqcePjd7DpLAKqEq2Nk8AuYBaQllj6bTIjhA304bsL rCAjeQVsJDZssAEJCwmUS/RuvAf2lIiAqcTB5fNYJjDKzUIK0FmIAJ2FZNACRuZVjEK5iZk5 upl55nqJBQU5qXrJ+bmbGEFRPd1ObAfjw1VWhxgFOBiVeHgbfkpHC7EmlhVX5h5ilOZgURLn LRMECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDMD9v/Sf6pXcT7T+o7dASf1/IFpxhO2+Jc WPAi6zwXQ+MG++SP64N2bLmUuClWo2wXx0e+6edu3Vkmv/7I7zXPd29tTHkYkz51pztrMt/2 /As/502JTRJ6mlA3tTY5yljRPsdr4c0vi98vOHtvp/Zc5sovd2NXbsqRqclLLXx/4RDLjJUy 4dNslFiKMxINtZiLihMBrJUkF8sCAAA= Archived-At: Subject: Re: [Taps] New Transport Networking APIs in iOS 12 beta X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 20:54:53 -0000 Hello Michael, The architecture is designed specifically to allow loading different protoco= ls. The parameters object is centered around a =E2=80=9Cprotocol stack=E2=80= =9D configuration object, which is composed of protocol options for defined p= rotocol implementations. This only exposes a default stack now, but is desig= ned to offer the configuration of alternate stacks as well. In this first ve= rsion, we=E2=80=99re only letting developers compose stacks with pre-defined= protocols, but I want to allow custom protocol definitions and implementati= ons going forward=E2=80=94for both simple framers, as well as full blown tra= nsports like SCTP and QUIC! The model of the connection sending and receivin= g messages is sufficiently generic to support any of the TAPS protocols.=20 Best, Tommy On Jun 9, 2018, at 11:38 AM, Michael Tuexen wrote: >> On 8. Jun 2018, at 18:29, Tommy Pauly wrote: >>=20 >> Hello TAPS! >>=20 >> This week we released Network.framework, a new set of transport APIs, as p= art of the beta for iOS 12 and macOS Mojave. >>=20 >> This API provides support for connections and listeners using TCP, UDP, T= LS, and DTLS; connecting by name or service, with happy eyeballs support for= addresses, interfaces, and protocols (for proxies, etc). This provides our b= asis for =E2=80=9Cpost-sockets=E2=80=9D API work. As we define as a working g= roup more of the full TAPS API vision for protocol agility, we'd like on add= that support to this framework.=20 > Hi Tommy, >=20 > great news! > Is there also a possibility to add new transports to the framework, like > SCTP or QUIC? >=20 > Best regards > Michael >>=20 >> Video of the presentation: >> https://developer.apple.com/videos/play/wwdc2018/715/ >>=20 >> Sample implementation of netcat: >> https://developer.apple.com/documentation/network/implementing_netcat_wit= h_network_framework >>=20 >> Swift and C API: >> https://developer.apple.com/documentation/network >>=20 >> If you are an iOS or macOS developer, please try out the APIs! Either way= , we=E2=80=99d love for everyone to take a read through the API and give fee= dback on how we can continue to evolve things towards a post-sockets and ful= ly TAPS model. Note that on iOS and tvOS, this framework is currently using a= user-space networking stack instead of sockets when applicable. >>=20 >> Best, >> Tommy >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Sun Jun 10 01:02:45 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B863C130E1F for ; Sun, 10 Jun 2018 01:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Xp0ol8MG-n-3 for ; Sun, 10 Jun 2018 01:02:40 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 307FC130E1E for ; Sun, 10 Jun 2018 01:02:39 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fRvJ7-00059H-9W; Sun, 10 Jun 2018 10:02:37 +0200 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.2]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fRvJ5-0000uZ-Br; Sun, 10 Jun 2018 10:02:37 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: <268D7E06-1D1D-4F70-9336-98EAF1BB5605@apple.com> Date: Sun, 10 Jun 2018 10:02:31 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3EEFA4C8-D9D2-45E8-98FD-55BEA12706E9@ifi.uio.no> References: <1C14F32A-3ADC-4D35-B800-091697E83AD6@apple.com> <63A71B2E-96E4-402A-89E2-667DDF8B1D08@lurchi.franken.de> <268D7E06-1D1D-4F70-9336-98EAF1BB5605@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.2]; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.093, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 08E764B50A25984BE5998746B0C3BA4C7517D2B0 Archived-At: Subject: Re: [Taps] New Transport Networking APIs in iOS 12 beta X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 08:02:43 -0000 Hi, This - in particular your answer to Michael - is indeed extremely cool! = Thanks to you and your colleagues at Apple for pursuing this direction, = and thanks for sharing it with the group! About this statement in the original email: *** Either way, we=E2=80=99d love for everyone to take a read through the = API and give feedback on how we can continue to evolve things towards a = post-sockets and fully TAPS model. *** I think an obvious answer to this is: the more in line with = draft-ietf-taps-interface it is, the better - and where it=E2=80=99s = not, it would probably be interesting for the group to know the reasons. Cheers, Michael > On Jun 9, 2018, at 10:54 PM, Tommy Pauly wrote: >=20 > Hello Michael, >=20 > The architecture is designed specifically to allow loading different = protocols. The parameters object is centered around a =E2=80=9Cprotocol = stack=E2=80=9D configuration object, which is composed of protocol = options for defined protocol implementations. This only exposes a = default stack now, but is designed to offer the configuration of = alternate stacks as well. In this first version, we=E2=80=99re only = letting developers compose stacks with pre-defined protocols, but I want = to allow custom protocol definitions and implementations going = forward=E2=80=94for both simple framers, as well as full blown = transports like SCTP and QUIC! The model of the connection sending and = receiving messages is sufficiently generic to support any of the TAPS = protocols.=20 >=20 > Best, > Tommy >=20 > On Jun 9, 2018, at 11:38 AM, Michael Tuexen = wrote: >=20 >>> On 8. Jun 2018, at 18:29, Tommy Pauly wrote: >>>=20 >>> Hello TAPS! >>>=20 >>> This week we released Network.framework, a new set of transport = APIs, as part of the beta for iOS 12 and macOS Mojave. >>>=20 >>> This API provides support for connections and listeners using TCP, = UDP, TLS, and DTLS; connecting by name or service, with happy eyeballs = support for addresses, interfaces, and protocols (for proxies, etc). = This provides our basis for =E2=80=9Cpost-sockets=E2=80=9D API work. As = we define as a working group more of the full TAPS API vision for = protocol agility, we'd like on add that support to this framework.=20 >> Hi Tommy, >>=20 >> great news! >> Is there also a possibility to add new transports to the framework, = like >> SCTP or QUIC? >>=20 >> Best regards >> Michael >>>=20 >>> Video of the presentation: >>> https://developer.apple.com/videos/play/wwdc2018/715/ >>>=20 >>> Sample implementation of netcat: >>> = https://developer.apple.com/documentation/network/implementing_netcat_with= _network_framework >>>=20 >>> Swift and C API: >>> https://developer.apple.com/documentation/network >>>=20 >>> If you are an iOS or macOS developer, please try out the APIs! = Either way, we=E2=80=99d love for everyone to take a read through the = API and give feedback on how we can continue to evolve things towards a = post-sockets and fully TAPS model. Note that on iOS and tvOS, this = framework is currently using a user-space networking stack instead of = sockets when applicable. >>>=20 >>> Best, >>> Tommy >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Jun 11 09:47:19 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D53130FF1 for ; Mon, 11 Jun 2018 09:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo-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 eyvyzej6iz7M for ; Mon, 11 Jun 2018 09:47:15 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772E6130E70 for ; Mon, 11 Jun 2018 09:47:15 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id a18-v6so3633102qtj.4 for ; Mon, 11 Jun 2018 09:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JqP0aH6zv6Pex9WpZ3jSbej9GpVm11nKi9EVw7jk6M8=; b=HhpHfYFo50iFQgdNhDc9z6kTr4LLtrUu4vfx214Vhvi7DdbzKDxNytBSiDgmoKq6ri pEDk8tuedPNGm4cx4XgOd8UR13uCT1dsyjparIQFncbQ3oZPR6nhOjuAdMzBLMR8zfjy yc2GFiXVSZnQ5Gg1GGt4ZCl43gJ2OvPeNRDRfkyDKTkivhFJWIPmXR1rc+iM8+QPJlTj jBh7tDt3HYo6O85lAzFPCRUL+hulb5ype1D62R/OemmdZ01AMr6kwMQps++caVnt0Odj b7anDZCDPfbVNL8VwXb22bg/kIZmAL+ZuGWwYSm/R1QQmkx5QfN4LIa9+HdbcNRdfxPc sL4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JqP0aH6zv6Pex9WpZ3jSbej9GpVm11nKi9EVw7jk6M8=; b=B1XdNf/S31IrqTyqaPBdoQnYE3Dk5rzTNraE7mUeisb3gKUA+dvRUdx8Z8LtUN9ZoR dipyfuHRul6lD+6WpDjf3I77wsxrmGi7NkOhQINZLwmqq2m20l+dVyoGlQHdq2ORW4im xu8HkGsgqn5wBImMxFpeM2UbfO1fuOaxoBlmB7x+OV0SRIlYzHT8TpqwBqbwfXvQes6Q CRpcfYeX4cxh/3BjSI2H1SzP8hTtzhI4kOyzffisZS8a4v2AEPoGnOJmOkTXq42oJZC1 BGHM6ZrmbI5PJt1d8ragSMlzT5sJgSuZeF9YsArjomnitVEGyxmZbtyiG9Cf4CYnSA+X xyQg== X-Gm-Message-State: APt69E36qGDZ6/z4gIm0niw81e5OnlIl3ko1D2RSrc3qJ0BON38D5A6j fJUaObsOOMqxcvKazQvv7Qq9vw== X-Google-Smtp-Source: ADUXVKLObYT3tKo0jLKjvXT7E06neNziq4S3UtwFsp+W81oJZkyt5mGoNBXzF6YKe5fj9ZacJ+MSJw== X-Received: by 2002:a0c:985a:: with SMTP id e26-v6mr15857774qvd.44.1528735634496; Mon, 11 Jun 2018 09:47:14 -0700 (PDT) Received: from [172.16.2.142] ([160.79.219.114]) by smtp.gmail.com with ESMTPSA id p72-v6sm25289366qki.15.2018.06.11.09.47.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 09:47:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Lennox In-Reply-To: <3EEFA4C8-D9D2-45E8-98FD-55BEA12706E9@ifi.uio.no> Date: Mon, 11 Jun 2018 12:47:12 -0400 Cc: Tommy Pauly , "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5A1D9981-B8C1-46C3-99AD-7F6C89C8B918@vidyo.com> References: <1C14F32A-3ADC-4D35-B800-091697E83AD6@apple.com> <63A71B2E-96E4-402A-89E2-667DDF8B1D08@lurchi.franken.de> <268D7E06-1D1D-4F70-9336-98EAF1BB5605@apple.com> <3EEFA4C8-D9D2-45E8-98FD-55BEA12706E9@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Taps] New Transport Networking APIs in iOS 12 beta X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 16:47:18 -0000 I=E2=80=99ve read over Apple=E2=80=99s new API. (One note: the URL that = Tommy sent a link to doesn=E2=80=99t have the full documentation of the = API yet; many of the types and methods still say =E2=80=9CNo overview = available.=E2=80=9D If you=E2=80=99re an Apple developer, the header = files supplied with the macOS 10.14 and iOS 12 beta SDKs in the Xcode 10 = beta contain much fuller versions of the documentation.) The main difference I=E2=80=99ve found between TAPS and = Network.framework is that Network.framework doesn=E2=80=99t have a = Preconnection object. Instead, Connection objects for outgoing = connections are directly created from a constructor, and then must have = their .start method called before they act. This part is a relatively minor semantic difference, but more = significant is how incoming connections are handled. In = Network.framework, there is a Listener object with a new_connection = handler, and this object can produce unlimited numbers of Connections = until stopped. This is unlike TAPS where a Listen action consumes a = Preconnection, and to receive multiple connections on the same port, = Listen must be called on multiple cloned Preconnections. I feel like the Network.framework model is an easier programming model = for most use cases, but it has the downside that an API user has no way = to pace its handling of incoming connections. > On Jun 10, 2018, at 4:02 AM, Michael Welzl wrote: >=20 > Hi, >=20 > This - in particular your answer to Michael - is indeed extremely = cool! Thanks to you and your colleagues at Apple for pursuing this = direction, and thanks for sharing it with the group! >=20 > About this statement in the original email: > *** > Either way, we=E2=80=99d love for everyone to take a read through the = API and give feedback on how we can continue to evolve things towards a = post-sockets and fully TAPS model. > *** >=20 > I think an obvious answer to this is: the more in line with = draft-ietf-taps-interface it is, the better - and where it=E2=80=99s = not, it would probably be interesting for the group to know the reasons. >=20 > Cheers, > Michael >=20 >=20 >=20 >> On Jun 9, 2018, at 10:54 PM, Tommy Pauly wrote: >>=20 >> Hello Michael, >>=20 >> The architecture is designed specifically to allow loading different = protocols. The parameters object is centered around a =E2=80=9Cprotocol = stack=E2=80=9D configuration object, which is composed of protocol = options for defined protocol implementations. This only exposes a = default stack now, but is designed to offer the configuration of = alternate stacks as well. In this first version, we=E2=80=99re only = letting developers compose stacks with pre-defined protocols, but I want = to allow custom protocol definitions and implementations going = forward=E2=80=94for both simple framers, as well as full blown = transports like SCTP and QUIC! The model of the connection sending and = receiving messages is sufficiently generic to support any of the TAPS = protocols.=20 >>=20 >> Best, >> Tommy >>=20 >> On Jun 9, 2018, at 11:38 AM, Michael Tuexen = wrote: >>=20 >>>> On 8. Jun 2018, at 18:29, Tommy Pauly wrote: >>>>=20 >>>> Hello TAPS! >>>>=20 >>>> This week we released Network.framework, a new set of transport = APIs, as part of the beta for iOS 12 and macOS Mojave. >>>>=20 >>>> This API provides support for connections and listeners using TCP, = UDP, TLS, and DTLS; connecting by name or service, with happy eyeballs = support for addresses, interfaces, and protocols (for proxies, etc). = This provides our basis for =E2=80=9Cpost-sockets=E2=80=9D API work. As = we define as a working group more of the full TAPS API vision for = protocol agility, we'd like on add that support to this framework.=20 >>> Hi Tommy, >>>=20 >>> great news! >>> Is there also a possibility to add new transports to the framework, = like >>> SCTP or QUIC? >>>=20 >>> Best regards >>> Michael >>>>=20 >>>> Video of the presentation: >>>> https://developer.apple.com/videos/play/wwdc2018/715/ >>>>=20 >>>> Sample implementation of netcat: >>>> = https://developer.apple.com/documentation/network/implementing_netcat_with= _network_framework >>>>=20 >>>> Swift and C API: >>>> https://developer.apple.com/documentation/network >>>>=20 >>>> If you are an iOS or macOS developer, please try out the APIs! = Either way, we=E2=80=99d love for everyone to take a read through the = API and give feedback on how we can continue to evolve things towards a = post-sockets and fully TAPS model. Note that on iOS and tvOS, this = framework is currently using a user-space networking stack instead of = sockets when applicable. >>>>=20 >>>> Best, >>>> Tommy >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Jun 15 01:01:02 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00413130DC2 for ; Fri, 15 Jun 2018 01:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 1PnFMRLgapLg for ; Fri, 15 Jun 2018 01:00:51 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 1F41D130DDC for ; Fri, 15 Jun 2018 01:00:50 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fTjf3-000GUD-1t; Fri, 15 Jun 2018 10:00:45 +0200 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.2]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fTjf2-0007BR-27; Fri, 15 Jun 2018 10:00:44 +0200 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B87F5668-94E3-4424-9E6B-90B6CEE5E8A7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 15 Jun 2018 10:00:30 +0200 In-Reply-To: <5A1D9981-B8C1-46C3-99AD-7F6C89C8B918@vidyo.com> Cc: Tommy Pauly , "taps@ietf.org" To: Jonathan Lennox References: <1C14F32A-3ADC-4D35-B800-091697E83AD6@apple.com> <63A71B2E-96E4-402A-89E2-667DDF8B1D08@lurchi.franken.de> <268D7E06-1D1D-4F70-9336-98EAF1BB5605@apple.com> <3EEFA4C8-D9D2-45E8-98FD-55BEA12706E9@ifi.uio.no> <5A1D9981-B8C1-46C3-99AD-7F6C89C8B918@vidyo.com> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.2]; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.091, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AC860511FA351B8731793D9FC31F12F7198968AD Archived-At: Subject: Re: [Taps] New Transport Networking APIs in iOS 12 beta X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 08:00:55 -0000 --Apple-Mail=_B87F5668-94E3-4424-9E6B-90B6CEE5E8A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Thanks for sharing this! It=E2=80=99s quite interesting - > On Jun 11, 2018, at 6:47 PM, Jonathan Lennox = wrote: >=20 > I=E2=80=99ve read over Apple=E2=80=99s new API. (One note: the URL = that Tommy sent a link to doesn=E2=80=99t have the full documentation of = the API yet; many of the types and methods still say =E2=80=9CNo = overview available.=E2=80=9D If you=E2=80=99re an Apple developer, the = header files supplied with the macOS 10.14 and iOS 12 beta SDKs in the = Xcode 10 beta contain much fuller versions of the documentation.) I agree, things are a bit inconsistent in the online docs for now=E2=80=A6= e.g. somehow this: https://developer.apple.com/documentation/network?language=3Dobjc = seems to be more complete than https://developer.apple.com/documentation/network/nwpath = but then there are also differences that are probably not due to the = language choice only. Well, it all clearly says =E2=80=9CBeta=E2=80=9D, = so that=E2=80=99s ok, we=E2=80=99ll just have to wait until this = documentation is updated. > The main difference I=E2=80=99ve found between TAPS and = Network.framework is that Network.framework doesn=E2=80=99t have a = Preconnection object. Instead, Connection objects for outgoing = connections are directly created from a constructor, and then must have = their .start method called before they act. >=20 > This part is a relatively minor semantic difference, but more = significant is how incoming connections are handled. In = Network.framework, there is a Listener object with a new_connection = handler, and this object can produce unlimited numbers of Connections = until stopped. This is unlike TAPS where a Listen action consumes a = Preconnection, and to receive multiple connections on the same port, = Listen must be called on multiple cloned Preconnections. I agree that the first difference is minor (constructor vs. = =E2=80=9CPreconnection=E2=80=9D). I would also say that the latter = difference is interesting but not huge=E2=80=A6 (=E2=80=9Cunder the = hood=E2=80=9D it=E2=80=99s easy to imagine that these can be two ways to = essentially expose the same thing). I=E2=80=99d also agree that the = Network.framework method is more convenient though. Tommy - what would = you say about moving our API in that direction for Listening? > I feel like the Network.framework model is an easier programming model = for most use cases, but it has the downside that an API user has no way = to pace its handling of incoming connections. I haven=E2=80=99t played with the Network.framework myself, but I would = guess that, if I want to slow down the rate at which I handle incoming = connections, there isn=E2=80=99t really much difference between not = calling Listen (current TAPS) vs. ignoring a newly created incoming = Connection (Network.framework). Why wouldn=E2=80=99t that work as a way = to pace conn. handling? Cheers, Michael --Apple-Mail=_B87F5668-94E3-4424-9E6B-90B6CEE5E8A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Thanks = for sharing this! It=E2=80=99s quite interesting -


On = Jun 11, 2018, at 6:47 PM, Jonathan Lennox <jonathan@vidyo.com> = wrote:

I=E2=80=99ve read over Apple=E2=80=99s new API.  (One = note: the URL that Tommy sent a link to doesn=E2=80=99t have the full = documentation of the API yet; many of the types and methods still say = =E2=80=9CNo overview available.=E2=80=9D If you=E2=80=99re an Apple = developer, the header files supplied with the macOS 10.14 and iOS 12 = beta SDKs in the Xcode 10 beta contain much fuller versions of the = documentation.)

I agree, things are a bit inconsistent in the online = docs for now=E2=80=A6 e.g. somehow this:
seems to be more complete than
https://developer.apple.com/documentation/network/nwpath
but then there are also differences that are probably not due to = the language choice only. Well, it all clearly says =E2=80=9CBeta=E2=80=9D= , so that=E2=80=99s ok, we=E2=80=99ll just have to wait until this = documentation is updated.


The main difference I=E2=80=99ve found between TAPS and = Network.framework is that Network.framework doesn=E2=80=99t have a = Preconnection object.  Instead, Connection objects for outgoing = connections are directly created from a constructor, and then must have = their .start method called before they act.

This part is a relatively minor semantic difference, but more = significant is how incoming connections are handled.  In = Network.framework, there is a Listener object with a new_connection = handler, and this object can produce unlimited numbers of Connections = until stopped.  This is unlike TAPS where a Listen action consumes = a Preconnection, and to receive multiple connections on the same port, = Listen must be called on multiple cloned Preconnections.

I = agree that the first difference is minor (constructor vs. = =E2=80=9CPreconnection=E2=80=9D). I would also say that the latter = difference is interesting but not huge=E2=80=A6 (=E2=80=9Cunder the = hood=E2=80=9D it=E2=80=99s easy to imagine that these can be two ways to = essentially expose the same thing). I=E2=80=99d also agree that the = Network.framework method is more convenient though. Tommy - what would = you say about moving our API in that direction for = Listening?


I feel like the = Network.framework model is an easier programming model for most use = cases, but it has the downside that an API user has no way to pace its = handling of incoming connections.

I = haven=E2=80=99t played with the Network.framework myself, but I would = guess that, if I want to slow down the rate at which I handle incoming = connections, there isn=E2=80=99t really much difference between not = calling Listen (current TAPS) vs. ignoring a newly created incoming = Connection (Network.framework). Why wouldn=E2=80=99t that work as a way = to pace conn. handling?

Cheers,
Michael

= --Apple-Mail=_B87F5668-94E3-4424-9E6B-90B6CEE5E8A7-- From nobody Fri Jun 15 09:17:41 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D28130FC7 for ; Fri, 15 Jun 2018 09:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 6xUZznasgaK5 for ; Fri, 15 Jun 2018 09:17:27 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 BA68D130FDC for ; Fri, 15 Jun 2018 09:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1529079428; x=2392993028; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ei8n9FXWh30en3cz8NU/JzeqTOsurOT/ByZvO4fYLIU=; b=hJhctZls9K9LCU4dvaTQ84yc4tqOKaSPuJABeIopd+i2FFyq6e25u31NHa17Dpl0 jwT89LH1b6MWdFg8EYX2rWgHP2TAf8LixSCH12Ni2L0pLQrBFnoyANsYAWIet80t Q4a3xAsZJMKktSG8v0L0nuW4+q5BoFCafxpHkop7eTEq0cPdNGcAGwS5lbq1goiO VmhH0WJ5GhVBysXFyQs12QT+Id1HUy8VBjJcdpiFp5eonupaj0bMoPDMCCGOwfBx YexhYpd2ei9xijciqLsdZNcMxswY0cT5SKatb/XdjrM7t4zeC/ZuKwCB4M939nXT OUI6iIdv/RWxbrxbpjufzw==; X-AuditID: 11973e12-a01ff700000010b7-70-5b23e6849f34 Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 79.61.04279.486E32B5; Fri, 15 Jun 2018 09:17:08 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_d45CHxk1DxfHg1nReTGzQg)" Received: from ma1-mmpp-sz10.apple.com (ma1-mmpp-sz10.apple.com [17.171.128.150]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0PAD00JKPH8JF920@mr2-mtap-s01.rno.apple.com>; Fri, 15 Jun 2018 09:17:08 -0700 (PDT) Received: from [17.230.160.236] (unknown [17.230.160.236]) by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0PAD00G14H8IZ230@ma1-mmpp-sz10.apple.com>; Fri, 15 Jun 2018 09:17:07 -0700 (PDT) X-Va-A: X-Va-T-CD: 91949cb67ad5a17194231cf3cf1e09f7 X-Va-E-CD: 36910ef1a06ecb6cf7c143959f25f86c X-Va-R-CD: 523f5b9545ee69ad6998eb029acd3ffa X-Va-CD: 0 X-Va-ID: 922e4ca1-5269-4fed-8d78-c9685db7eeef X-V-A: X-V-T-CD: 28de45ac93053488fd5a3d3ecf6bf00e X-V-E-CD: 36910ef1a06ecb6cf7c143959f25f86c X-V-R-CD: 523f5b9545ee69ad6998eb029acd3ffa X-V-CD: 0 X-V-ID: 2c0dee1b-dfbe-43b8-a27c-e0966f27db67 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-15_09:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp24.corp.apple.com-10000_instance1 Sender: tpauly@apple.com From: Tommy Pauly Message-id: <7CBAD06E-5299-413C-BA01-9662EC9DE702@apple.com> Date: Fri, 15 Jun 2018 09:17:05 -0700 In-reply-to: Cc: Jonathan Lennox , "taps@ietf.org" To: Michael Welzl References: <1C14F32A-3ADC-4D35-B800-091697E83AD6@apple.com> <63A71B2E-96E4-402A-89E2-667DDF8B1D08@lurchi.franken.de> <268D7E06-1D1D-4F70-9336-98EAF1BB5605@apple.com> <3EEFA4C8-D9D2-45E8-98FD-55BEA12706E9@ifi.uio.no> <5A1D9981-B8C1-46C3-99AD-7F6C89C8B918@vidyo.com> X-Mailer: Apple Mail (2.3445.100.13.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRmVeSWpSXmKPExsUiuPlRq27LM+Vog2enZSz2Lz7PbPHj7E5W izsxDsweS5b8ZPJYvfohs0fbszvsAcxRXDYpqTmZZalF+nYJXBmbHnkU3E6rOHnrAFMD4/7w LkZODgkBE4l5bY2sXYxcHEICB5gkHt3bygaS4BUQlPgx+R4LiM0sECaxuWMnG0TReiaJrXce sUM4k5kkfs1YyQYxil3iz68dLBC2tsTmwyeYYOzTd1rh4gd23YSq55JYsPU0K4StK7Hq/BN2 CJtNYv2JJVC9WhJXPt5ihrF7Wv/A2W0TnkPN4ZQ4/2UiUC8HkK0j8eJqBEQ4W6LtxxaokgCJ BR2PGEFKhAUkJDbvSQQJswmoSBz/toEZ4l8bidM9u9kgShwkmnaIgYRZBFQlVm5rYQYJcwrY SZzpzIOEiKfEzbVvwW4XEVCTOLF8NTR0jjJJLJ90F2qrmsT82y9YJzDKzUIK0VlIIToLaCyz gLrElCm5EGFtiSfvLrBC2GoSC38vYkIWX8DItopRKDcxM0c3M89EL7GgICdVLzk/dxMjKGVM txPawXhqldUhRgEORiUeXoHTytFCrIllxZW5hxilOViUxHlt3itFCwmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamAsYk/52bylr/Hdn/0HRBXuCm65On3K00bFr7feMnyfpV+z5aOQmMWjr928 5TPmHJTtKC2Z8dZzmdy+dqc1fz3/37J0lv12YOr3dTpzlB8uqxcx+/HnyeIQjU1XbTP37vtr XaEkOyd7qUV0sfFXfuGYVRNOPVyyPP+D8DLNF1FHPp6ZsbSoctreEiWW4oxEQy3mouJEABrP B276AgAA Archived-At: Subject: Re: [Taps] New Transport Networking APIs in iOS 12 beta X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 16:17:39 -0000 --Boundary_(ID_d45CHxk1DxfHg1nReTGzQg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Jun 15, 2018, at 1:00 AM, Michael Welzl wrote: >=20 > Hi, >=20 > Thanks for sharing this! It=E2=80=99s quite interesting - >=20 >=20 >> On Jun 11, 2018, at 6:47 PM, Jonathan Lennox > wrote: >>=20 >> I=E2=80=99ve read over Apple=E2=80=99s new API. (One note: the URL = that Tommy sent a link to doesn=E2=80=99t have the full documentation of = the API yet; many of the types and methods still say =E2=80=9CNo = overview available.=E2=80=9D If you=E2=80=99re an Apple developer, the = header files supplied with the macOS 10.14 and iOS 12 beta SDKs in the = Xcode 10 beta contain much fuller versions of the documentation.) >=20 > I agree, things are a bit inconsistent in the online docs for now=E2=80=A6= e.g. somehow this: > https://developer.apple.com/documentation/network?language=3Dobjc = > seems to be more complete than > https://developer.apple.com/documentation/network/nwpath = > but then there are also differences that are probably not due to the = language choice only. Well, it all clearly says =E2=80=9CBeta=E2=80=9D, = so that=E2=80=99s ok, we=E2=80=99ll just have to wait until this = documentation is updated. >=20 >=20 >> The main difference I=E2=80=99ve found between TAPS and = Network.framework is that Network.framework doesn=E2=80=99t have a = Preconnection object. Instead, Connection objects for outgoing = connections are directly created from a constructor, and then must have = their .start method called before they act. >>=20 >> This part is a relatively minor semantic difference, but more = significant is how incoming connections are handled. In = Network.framework, there is a Listener object with a new_connection = handler, and this object can produce unlimited numbers of Connections = until stopped. This is unlike TAPS where a Listen action consumes a = Preconnection, and to receive multiple connections on the same port, = Listen must be called on multiple cloned Preconnections. >=20 > I agree that the first difference is minor (constructor vs. = =E2=80=9CPreconnection=E2=80=9D). I would also say that the latter = difference is interesting but not huge=E2=80=A6 (=E2=80=9Cunder the = hood=E2=80=9D it=E2=80=99s easy to imagine that these can be two ways to = essentially expose the same thing). I=E2=80=99d also agree that the = Network.framework method is more convenient though. Tommy - what would = you say about moving our API in that direction for Listening? >=20 >=20 >> I feel like the Network.framework model is an easier programming = model for most use cases, but it has the downside that an API user has = no way to pace its handling of incoming connections. >=20 > I haven=E2=80=99t played with the Network.framework myself, but I = would guess that, if I want to slow down the rate at which I handle = incoming connections, there isn=E2=80=99t really much difference between = not calling Listen (current TAPS) vs. ignoring a newly created incoming = Connection (Network.framework). Why wouldn=E2=80=99t that work as a way = to pace conn. handling? One first note: a lot of the =E2=80=98preconnection=E2=80=99 properties = are encapsulated in our NWParameters object. The main difference, = conceptually, is that the parameters object is just a container (which = may be reused) but doesn=E2=80=99t imply that any work can happen just = by creating a parameters object. Regarding calling listen multiple times vs providing a single completion = handler to be called multiple times: I find the Listen model appropriate = to have a single completion that gets invoked multiple times because the = code in response to a Listen is generally going to be the same=E2=80=94eac= h new connection cannot be assumed to have any relationship or ordering = with regards to prior connections, so the logic you need to write to = process an inbound connection will be the same. Thus, providing a single = completion is cleaner. Contrast this to a Receive completion, in which = receiving on a connection is assumed to have order=E2=80=94I may expect = to read a =E2=80=9Cheader=E2=80=9D message, followed by a =E2=80=9Cbody=E2= =80=9D message, etc, thus using multiple Receive calls not only provides = back pressure, but allows different handling upon completion. Adding back pressure to inbound connections is something that we do need = to add. The approach Michael suggests, of just ignoring an inbound = connection until we=E2=80=99re ready to process it, certainly would = work. The downside is that this requires the caller of the API to manage = their own array of pending inbound connections. One option we=E2=80=99ve = considered is allowing the application to specify a =E2=80=9Creceive = connection window size=E2=80=9D on a listener, thus defining how many = more inbound connections they=E2=80=99re ready to handle at a given = time. What do people think about this approach? Thanks, Tommy >=20 > Cheers, > Michael >=20 --Boundary_(ID_d45CHxk1DxfHg1nReTGzQg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On Jun 15, 2018, at 1:00 AM, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

Thanks for sharing this! = It=E2=80=99s quite interesting -


On Jun = 11, 2018, at 6:47 PM, Jonathan Lennox <jonathan@vidyo.com> = wrote:

I=E2=80=99ve read over Apple=E2=80=99s new API.  (One = note: the URL that Tommy sent a link to doesn=E2=80=99t have the full = documentation of the API yet; many of the types and methods still say = =E2=80=9CNo overview available.=E2=80=9D If you=E2=80=99re an Apple = developer, the header files supplied with the macOS 10.14 and iOS 12 = beta SDKs in the Xcode 10 beta contain much fuller versions of the = documentation.)
I agree, things are a bit inconsistent in the online = docs for now=E2=80=A6 e.g. somehow this:
https://developer.apple.com/documentation/network?language=3Dob= jc
seems to be more complete than
https://developer.apple.com/documentation/network/nwpath
but then there are also differences that are probably = not due to the language choice only. Well, it all clearly says = =E2=80=9CBeta=E2=80=9D, so that=E2=80=99s ok, we=E2=80=99ll just have to = wait until this documentation is updated.


The main difference I=E2=80=99v= e found between TAPS and Network.framework is that Network.framework = doesn=E2=80=99t have a Preconnection object.  Instead, Connection = objects for outgoing connections are directly created from a = constructor, and then must have their .start method called before they = act.

This part is a relatively minor = semantic difference, but more significant is how incoming connections = are handled.  In Network.framework, there is a Listener object with = a new_connection handler, and this object can produce unlimited numbers = of Connections until stopped.  This is unlike TAPS where a Listen = action consumes a Preconnection, and to receive multiple connections on = the same port, Listen must be called on multiple cloned = Preconnections.
I agree that the first difference is = minor (constructor vs. =E2=80=9CPreconnection=E2=80=9D). I would also = say that the latter difference is interesting but not huge=E2=80=A6 = (=E2=80=9Cunder the hood=E2=80=9D it=E2=80=99s easy to imagine that = these can be two ways to essentially expose the same thing). I=E2=80=99d = also agree that the Network.framework method is more convenient though. = Tommy - what would you say about moving our API in that direction for = Listening?


I feel like the = Network.framework model is an easier programming model for most use = cases, but it has the downside that an API user has no way to pace its = handling of incoming connections.

I haven=E2=80=99t played with the = Network.framework myself, but I would guess that, if I want to slow down = the rate at which I handle incoming connections, there isn=E2=80=99t = really much difference between not calling Listen (current TAPS) vs. = ignoring a newly created incoming Connection (Network.framework). Why = wouldn=E2=80=99t that work as a way to pace conn. = handling?

One first note: a lot of the =E2=80=98preconnection=E2= =80=99 properties are encapsulated in our NWParameters object. The main = difference, conceptually, is that the parameters object is just a = container (which may be reused) but doesn=E2=80=99t imply that any work = can happen just by creating a parameters object.

Regarding calling listen multiple times vs = providing a single completion handler to be called multiple times: I = find the Listen model appropriate to have a single completion that gets = invoked multiple times because the code in response to a Listen is = generally going to be the same=E2=80=94each new connection cannot be = assumed to have any relationship or ordering with regards to prior = connections, so the logic you need to write to process an inbound = connection will be the same. Thus, providing a single completion is = cleaner. Contrast this to a Receive completion, in which receiving on a = connection is assumed to have order=E2=80=94I may expect to read a = =E2=80=9Cheader=E2=80=9D message, followed by a =E2=80=9Cbody=E2=80=9D = message, etc, thus using multiple Receive calls not only provides back = pressure, but allows different handling upon completion.

Adding back pressure to inbound connections is = something that we do need to add. The approach Michael suggests, of just = ignoring an inbound connection until we=E2=80=99re ready to process it, = certainly would work. The downside is that this requires the caller of = the API to manage their own array of pending inbound connections. One = option we=E2=80=99ve considered is allowing the application to specify a = =E2=80=9Creceive connection window size=E2=80=9D on a listener, thus = defining how many more inbound connections they=E2=80=99re ready to = handle at a given time. What do people think about this = approach?

Thanks,
Tommy


Cheers,
Michael


= --Boundary_(ID_d45CHxk1DxfHg1nReTGzQg)-- From nobody Fri Jun 15 09:37:57 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6E5130E22 for ; Fri, 15 Jun 2018 09:37:55 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 4mWacvX4jbNn for ; Fri, 15 Jun 2018 09:37:52 -0700 (PDT) Received: from know-smtprelay-omc-4.server.virginmedia.net (know-smtprelay-omc-4.server.virginmedia.net [80.0.253.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 78261130DC0 for ; Fri, 15 Jun 2018 09:37:52 -0700 (PDT) Received: from [192.168.1.35] ([79.64.221.5]) by cmsmtp with ESMTPA id TrjRfvyaEplZRTrjRf5kIN; Fri, 15 Jun 2018 17:37:50 +0100 X-Originating-IP: [79.64.221.5] X-Authenticated-User: john.s.grant@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=Vf/Zwmh9 c=1 sm=1 tr=0 a=BsjXqBXXfngcj6x1w0OkBQ==:117 a=BsjXqBXXfngcj6x1w0OkBQ==:17 a=IkcTkHD0fZMA:10 a=le6d79QuAAAA:8 a=671qOJ725CEc_yltWOIA:9 a=QEXdDO2ut3YA:10 a=QbAMNLWdp4a7deKPGBBn:22 To: taps@ietf.org References: <1C14F32A-3ADC-4D35-B800-091697E83AD6@apple.com> <63A71B2E-96E4-402A-89E2-667DDF8B1D08@lurchi.franken.de> <268D7E06-1D1D-4F70-9336-98EAF1BB5605@apple.com> <3EEFA4C8-D9D2-45E8-98FD-55BEA12706E9@ifi.uio.no> <5A1D9981-B8C1-46C3-99AD-7F6C89C8B918@vidyo.com> <7CBAD06E-5299-413C-BA01-9662EC9DE702@apple.com> From: John Grant Message-ID: <4f82aa36-3196-1cae-d14d-b2970943dc9b@ninetiles.com> Date: Fri, 15 Jun 2018 17:37:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7CBAD06E-5299-413C-BA01-9662EC9DE702@apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-CMAE-Envelope: MS4wfIe1KFejVPdTjjpdBatDqatrpQosotJa6/E50yBbhFYGNSCQHfc8LNG5fn1BOtudOrd02/23MBjo0uspafXa+ItsxO1Au0UzbPCd5K4fCCY6Wefh2zNB SLY55TR1IJeRbdwxnt/IVmAZwrHEIsqrBH0= Archived-At: Subject: Re: [Taps] New Transport Networking APIs in iOS 12 beta X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 16:37:55 -0000 On 15/06/2018 17:17, Tommy Pauly wrote: [snip] > > Adding back pressure to inbound connections is something that we do > need to add. The approach Michael suggests, of just ignoring an > inbound connection until we’re ready to process it, certainly would > work. The downside is that this requires the caller of the API to > manage their own array of pending inbound connections. One option > we’ve considered is allowing the application to specify a “receive > connection window size” on a listener, thus defining how many more > inbound connections they’re ready to handle at a given time. What do > people think about this approach? Yes, that should be effective. One thing that needs to be avoided is the possibility of an attacker (or software error) causing huge numbers of Connection objects to be created. -- John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com From nobody Fri Jun 15 11:27:40 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9002130DBE for ; Fri, 15 Jun 2018 11:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mvKE24_e9rRJ for ; Fri, 15 Jun 2018 11:27:36 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 585A012F18C for ; Fri, 15 Jun 2018 11:27:36 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fTtRe-0003xC-0f; Fri, 15 Jun 2018 20:27:34 +0200 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.2]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fTtRd-000Dj4-9l; Fri, 15 Jun 2018 20:27:33 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: <4f82aa36-3196-1cae-d14d-b2970943dc9b@ninetiles.com> Date: Fri, 15 Jun 2018 20:27:26 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <73DDC7E8-5AD2-4AE2-AB9A-C8385FB1E32B@ifi.uio.no> References: <1C14F32A-3ADC-4D35-B800-091697E83AD6@apple.com> <63A71B2E-96E4-402A-89E2-667DDF8B1D08@lurchi.franken.de> <268D7E06-1D1D-4F70-9336-98EAF1BB5605@apple.com> <3EEFA4C8-D9D2-45E8-98FD-55BEA12706E9@ifi.uio.no> <5A1D9981-B8C1-46C3-99AD-7F6C89C8B918@vidyo.com> <7CBAD06E-5299-413C-BA01-9662EC9DE702@apple.com> <4f82aa36-3196-1cae-d14d-b2970943dc9b@ninetiles.com> To: John Grant X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.2]; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.091, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 208EDB8F0F7731F4A98CE3A031EB687B0F06FC82 Archived-At: Subject: Re: [Taps] New Transport Networking APIs in iOS 12 beta X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 18:27:39 -0000 > On Jun 15, 2018, at 6:37 PM, John Grant wrote: >=20 > On 15/06/2018 17:17, Tommy Pauly wrote: >=20 > [snip] >>=20 >> Adding back pressure to inbound connections is something that we do = need to add. The approach Michael suggests, of just ignoring an inbound = connection until we=E2=80=99re ready to process it, certainly would = work. The downside is that this requires the caller of the API to manage = their own array of pending inbound connections. One option we=E2=80=99ve = considered is allowing the application to specify a =E2=80=9Creceive = connection window size=E2=80=9D on a listener, thus defining how many = more inbound connections they=E2=80=99re ready to handle at a given = time. What do people think about this approach? > Yes, that should be effective. One thing that needs to be avoided is = the possibility of an attacker (or software error) causing huge numbers = of Connection objects to be created. I believe that this could be dealt with in any case, by just allowing a = max connection limit to be specified (and having a reasonable upper = bound by default). But I still prefer Tommy=E2=80=99s proposal over what I described, = because it seems to me to be simpler to handle for the application = developer. Cheers, Michael From nobody Thu Jun 28 04:53:33 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917A6130F69 for ; Thu, 28 Jun 2018 04:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=YiDYJ4jP; dkim=pass (1024-bit key) header.d=ericsson.com header.b=PBQFWOuc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKUy7_noKjLa for ; Thu, 28 Jun 2018 04:53:28 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 38CA112777C for ; Thu, 28 Jun 2018 04:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530186806; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3nA2wweR5A4cMSVEVwdz3tCUHmtSpMLrz/9kBSg/vp4=; b=YiDYJ4jPl94f+B4EgDbD0CxnY4xpVIMmyqDD72yRlJR65HrAGv+MUQ9/7eDg9Rub jQtBDbogNOOb4b5IZlsllRr6xSDm3EMvbneW4S9psm6uuQdFSz0Q67DMKSSeY6JB A2mqlw9Aon2GwukWN8wzQX9cRJPdmlMgJYBCcn63jm4=; X-AuditID: c1b4fb25-e3bff70000006310-9b-5b34cc363e6f Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F3.C1.25360.63CC43B5; Thu, 28 Jun 2018 13:53:26 +0200 (CEST) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 28 Jun 2018 13:53:26 +0200 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 28 Jun 2018 13:53:26 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3nA2wweR5A4cMSVEVwdz3tCUHmtSpMLrz/9kBSg/vp4=; b=PBQFWOucaRjV6zkMhG7jjb18Cb5nMtcCdN+JmUG307N4RUs/xc6obGKQe4oFFzbw3ZaBX7YLCOK212hDCeg8yMwSmDHLS9rjOvuc1KWKw3R/f1buP6Te1H8CsIuxCe+58TNPxFSzSYA1d90RDECOfENqD/EtJh1DizDgFxAL7Qw= Received: from VI1PR0701MB2255.eurprd07.prod.outlook.com (10.169.137.146) by VI1PR0701MB2957.eurprd07.prod.outlook.com (10.173.72.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.11; Thu, 28 Jun 2018 11:53:25 +0000 Received: from VI1PR0701MB2255.eurprd07.prod.outlook.com ([fe80::d80e:8948:9cc4:fba5]) by VI1PR0701MB2255.eurprd07.prod.outlook.com ([fe80::d80e:8948:9cc4:fba5%10]) with mapi id 15.20.0930.005; Thu, 28 Jun 2018 11:53:25 +0000 From: Zaheduzzaman Sarker To: "taps@ietf.org" Thread-Topic: Call for agenda item for IETF 102 Thread-Index: AQHUDtaeiYwt43hG/U62g+pE+BtOhQ== Date: Thu, 28 Jun 2018 11:53:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2957; 7:SFHK/Rc6fyNysGOO9lLNdZD+NLRnzjSraOn6sslP02Bqf73hOFJN89DojX/SNiJ0sadgfQO+1DkrgtS6Fa6A7CxEL33yrY8rStTHyj89YJkiNVH4dkQg5bPoL1NpW3634ux2uKWyrh9EfbjwuCrOC928HXUC55Eaq+vYXNf2zY5unjP6GPoyc56dUosrtL/7Fmy8Armdb58A6GJEQQwAPueWwWwS4bEjyeXq7Xqs/RISAIDFi9Ust7ppKCxwsu8A x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 76d9dea9-94e9-4ed2-2656-08d5dcedc169 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2957; x-ms-traffictypediagnostic: VI1PR0701MB2957: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0701MB2957; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2957; x-forefront-prvs: 0717E25089 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(39860400002)(376002)(366004)(189003)(199004)(97736004)(36756003)(2906002)(561944003)(14454004)(82746002)(33656002)(478600001)(66066001)(5640700003)(68736007)(6436002)(2501003)(5250100002)(6512007)(54896002)(6486002)(6306002)(44832011)(2900100001)(256004)(2351001)(7736002)(83716003)(486006)(6916009)(6116002)(3846002)(106356001)(25786009)(186003)(26005)(6506007)(102836004)(476003)(2616005)(105586002)(58126008)(8936002)(316002)(1730700003)(81156014)(5660300001)(81166006)(8676002)(99286004)(86362001)(558084003)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2957; H:VI1PR0701MB2255.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-microsoft-antispam-message-info: XBIbfTfOVlM7wcWdWqIXYHY5HCAceTIlYmJC+PAT1GSjmn9j/jmJaj5UrLDPV8ecpmLlbyvvSQ7nFLgQiKIOkMPbyP0eTWg8pIkt7h9OjEJojiu5Hqc+YowXBI0d7uiR2JwTWghCLoNbBRecg48BxBe2puMXVo5mg3pbyFOd1CBXuhtG41kCZq8oJvRScUNQjDURYlTjj/UltmdePx2RFZysjLZ1jehJM4vBm7cs3lHqFkvcZ2J5L0Qa02Kt/SPdyYs1eg/52X7apmDeKVU03XXpqiCuRRbcfCItzGbofuwf3iAYGy+DUBhnmaKBrAEhajKqi+hs5Q0SrAtAscXyjSyW3wPjnnORc/HPS0Pz2RE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AB77C0CF24D24592BBBB63AC5073746Cericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 76d9dea9-94e9-4ed2-2656-08d5dcedc169 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2018 11:53:25.2206 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2957 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsUyM2J7ma7ZGZNogzdNihZ3YhwYPZYs+ckU wBjFZZOSmpNZllqkb5fAlXGyazp7wQrHiq7NO1gaGHfbdzFyckgImEhMndPJ1sXIxSEkcJRR 4vKTzVDON0aJmxda2CGcJUwSv2f9ZgVxWAQmMEt8nTuNFSIznUni1/LlzBDOc0aJ3nnPmLoY OTjYBGwkHi/2A1kiIqAscXn/RjYQW1hAS2LX4TtsEHF9ib5Ji5lBykUE9CRmzakACbMIqEr8 e7KVCcTmFbCX6Greyw5iMwqISXw/tQYsziwgLnHryXwmiB8EJJbsOc8MYYtKvHz8jxXEFgUa uW1TIxtEb7LE1K+tbBA1ChJ/Lj2CsmUlLs3vZoSwtzFJ3NigD2HrSnyYOhXsNAkBX4nL+wpB PpQQuMQocfDVOjaIuI5EwzUXiPJ8iXunL0GN8ZL4f6Yf6hw5iVW9D1kgeg8xS5w42AKVkJHY dec8+wRGvVlI3oGwkyU2z97GOAvsfUGJkzOfsMwCWscsoCmxfpc+RImixJTuh+wQtoZE65y5 7BAlHhJT92ggK1nAyLGKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzDxHNzyW3UH4+U3jocY BTgYlXh4v500iRZiTSwrrsw9xCjBwawkwvtpL1CINyWxsiq1KD++qDQntfgQozQHi5I470Pz zVFCAumJJanZqakFqUUwWSYOTqkGRjf7ruMFLsdsTl0MF7WUuW4clRH3SahaZDffty9iR8Qm qy6XuHBo45GtNqkL9t14Mfv2/06b0NOBzR1OU0617lzp+KXyaQmTVviV0HknKjU3+ElPiXzk VVr44EpY8dXyqZln/M1cctTU6sUZ65Lnym9c/Kl57yyNLxzuMf1vpLy480Ntlx++psRSnJFo qMVcVJwIAFLHcbw4AwAA Archived-At: Subject: [Taps] Call for agenda item for IETF 102 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 11:53:31 -0000 --_000_AB77C0CF24D24592BBBB63AC5073746Cericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVEFQUywNCg0KV2UgYXJlIHBsYW5uaW5nIGZvciB0aGUgSUVURiAxMDIgU2Vzc2lvbi4gUGxl YXNlIHNlbmQgeW91ciBwcm9wb3NhbChzKSBmb3IgYWdlbmRhIGl0ZW0gYW5kIGFsc28gbWVudGlv biDigJMNCg0KDQogICogICBUaGUgZHVyYXRpb24gb2YgdGltZXNsb3QgeW91IHByZWZlci4NCiAg KiAgIFRoZSBwb2ludHMgeW91IHdvdWxkIGxpa2UgdG8gZGlzY3VzcyBkdXJpbmcgdGhlIElFVEYx MDIgbWVldGluZyBkdXJpbmcgeW91ciB0aW1lc2xvdC4NCg0KQlINCg0KWmFoZWQgJiBBYXJvbg0K DQo= --_000_AB77C0CF24D24592BBBB63AC5073746Cericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <3B9C3AB56E2F9E4F8588188933C341CE@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxl ZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1z cGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTI1Mzg1MzQ0NzsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTk5MjA1OTU1MCAtMTk1NjIyNjUxOCA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2Fs aWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+ SGkgVEFQUyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOmJsYWNrIj5XZSBhcmUgcGxhbm5pbmcgZm9yIHRoZSBJRVRGIDEwMiBT ZXNzaW9uLiBQbGVhc2Ugc2VuZCB5b3VyIHByb3Bvc2FsKHMpIGZvciZuYnNwO2FnZW5kYSZuYnNw O2l0ZW0mbmJzcDthbmQgYWxzbyBtZW50aW9uIOKAkzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxl PSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJjb2xvcjpibGFjazttYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUg ZHVyYXRpb24gb2YgdGltZXNsb3QgeW91IHByZWZlci48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOmJsYWNrO21hcmdpbi1sZWZ0 OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBwb2ludHMgeW91IHdvdWxkIGxpa2UgdG8gZGlzY3VzcyBk dXJpbmcgdGhlIElFVEYxMDIgbWVldGluZyBkdXJpbmcgeW91ciB0aW1lc2xvdC48bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjpibGFjayI+QlI8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlphaGVkICZhbXA7IEFhcm9uPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AB77C0CF24D24592BBBB63AC5073746Cericssoncom_-- From nobody Thu Jun 28 06:41:11 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AB5130FEE for ; Thu, 28 Jun 2018 06:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 L0bf8XxVxHMo for ; Thu, 28 Jun 2018 06:41:07 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 80A23130FED for ; Thu, 28 Jun 2018 06:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530193266; x=2394106866; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xeRa4qNsJM84Dhw0XW+BTaPjv34/dJD2BmQNLnwN7u8=; b=eQb8ZikhSSlpZNDI3uPKAoCSwzSuwTpj5Ic7sslAkjWiWD7bdgIcpbJF3HSzu34y HX66Sci4tiI28iG0NLYBsGlfZc08kTCUGncLPnov/iwhxGKi5ZRSjAVwPxvDsYqI MJ1qcTHvHTGhQSP1HLJJ2yCBJqc3EPAPL8MkvcUMp0KOAXOFELqjWO4FGdwe/AQx mjUPWpP6qtgsBFAsonv9Vyj1E/6su/cOpJcyXdm2ZeOuLVC/xEonZV5wGJdZY5kj SFZsF8SVKlOhe4BYe71y74e81V28IroHFIaJNVArMnuJuh9c54lXlX8rTvc0189o uKVyMXE3ynKVnM4lR1peFw==; X-AuditID: 11973e11-9fbff70000003aca-80-5b34e5710bcb Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 62.34.15050.275E43B5; Thu, 28 Jun 2018 06:41:06 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_WuGVUsBXJWg6S0GqiF2KcQ)" Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PB1008SPCOGPD00@ma1-mtap-s03.corp.apple.com>; Thu, 28 Jun 2018 06:41:05 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB100500C2UUA00@nwk-mmpp-sz09.apple.com>; Thu, 28 Jun 2018 06:41:04 -0700 (PDT) X-Va-A: X-Va-T-CD: ec7cf7d5a842a42e6c107a95447fe5ef X-Va-E-CD: 1ec01e960ed10389a4e9db4f6ea860e7 X-Va-R-CD: 3a6bedfda87e541b96f0e68d214b1426 X-Va-CD: 0 X-Va-ID: 19a01f72-25e6-4b91-b963-e4f740b47c12 X-V-A: X-V-T-CD: 50cb5511327fe04beb66105532254f45 X-V-E-CD: 1ec01e960ed10389a4e9db4f6ea860e7 X-V-R-CD: 3a6bedfda87e541b96f0e68d214b1426 X-V-CD: 0 X-V-ID: 15a6d70a-ebb5-402d-8127-4c6e4e679220 Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB100A00CEJRU00@nwk-mmpp-sz09.apple.com>; Thu, 28 Jun 2018 06:41:04 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-28_07:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1 Received: from [17.234.74.77] (unknown [17.234.74.77]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PB100LKJCOGOE10@nwk-mmpp-sz09.apple.com>; Thu, 28 Jun 2018 06:41:04 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Date: Thu, 28 Jun 2018 06:41:04 -0700 Message-id: <83441BF4-BAB3-48AF-BFBD-E64FB3A3BEB3@apple.com> References: In-reply-to: To: Zaheduzzaman Sarker , "taps@ietf.org" X-Mailer: iPhone Mail (16A5308c) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUiqOHDrlv01CTaoOeznMWdGIsjp94xOzB5 /Pp6lc1jyZKfTAFMUVw2Kak5mWWpRfp2CVwZS3/eYimY51FxbwdnA+M8+y5GTg4JAROJvR2N zF2MXBxCAvuYJCZ/bWAHSfAKCEr8mHyPBcRmFgiT2LT+LyNE0QYmiU+TmhhBEkICXUwSV5eU QUxil/jzawcLhK0t8Wr7cmYYe/msC+ww9tu/y5ggbC6JBVtPs0LYuhJPF56FirNJrD+xBMrW kni4dxFQLweY/fZxJUz42uotUCM5Jc5/mQhVoiOx9VAJxJmdTBLdm09CjcmWaL64HsoOlng4 oQ3ql34miYPzvjCDNAsLSEhs3pMIUsMmoCJx/NsGsPNZBFQl3n/6AHamsICpxPaDzSyQ8LGR OHzyBzMkGOwldly5BmZzCjhITL/cwAoyUkQgVuLMPTOItQoSs088YprAKD8LKXRnIYXuLKAO ZgF1iSlTciHC2hJP3l1ghbDVJBb+XsSELL6AkW0Vo1BuYmaObmaekV5iQUFOql5yfu4mRlDa mG4nuIPx+CqrQ4wCHIxKPLwK102ihVgTy4orcw8xSnOwKInzdogBhQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTBe6k9leLVmrsLZ62zF/HP4b7xNMNhgksh1d2N/iJbFkuyya/7cG8XnKfFM kjtyOHlqgtmyI8tPmP9/uLPIlNHQ5UhCctSRj6IylnbzDn2/lulZrhyZFX+Hy6ev9/wEb58p dkVKl/59/ex5md9+V8+05Q62eze1Tc7hOvklvGnXp9WsbVzdvqlKLMUZiYZazEXFiQA9G8dn /AIAAA== Archived-At: Subject: Re: [Taps] Call for agenda item for IETF 102 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 13:41:10 -0000 --Boundary_(ID_WuGVUsBXJWg6S0GqiF2KcQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable It looks like TAPS has a 2.5 hour slot, which is good! We=E2=80=99ll be publishing some -01 versions of the architecture, interface= , and implementation drafts before the submission deadline, so I think we sh= ould have slots for those documents. We haven=E2=80=99t worked out the detai= ls yet, but I imagine having 15 minutes architecture, 20 minutes interface, a= nd 10 minutes implementation would make sense based on the diffs.=20 There should also be a rev of the transport security survey and some initial= feedback from the security area, so an update from Chris or Kyle on that (1= 5?) would be good.=20 One other agenda proposal I=E2=80=99d like to make is a section highlighting= some implementation experiences that can influence our drafts. I think NEAT= has some details they=E2=80=99d like to share, and now that Apple has relea= sed its Network.framework new transport API, I=E2=80=99d like to give a 10 m= inute talk sharing how it looks and some decisions we made while implementin= g.=20 Best, Tommy > On Jun 28, 2018, at 4:53 AM, Zaheduzzaman Sarker wrote: >=20 > Hi TAPS, > =20 > We are planning for the IETF 102 Session. Please send your proposal(s) for= agenda item and also mention =E2=80=93 > =20 > The duration of timeslot you prefer. > The points you would like to discuss during the IETF102 meeting during you= r timeslot. > =20 > BR > =20 > Zahed & Aaron > =20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_WuGVUsBXJWg6S0GqiF2KcQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
It looks like TAPS has a 2.5 hour slot= , which is good!

We=E2=80=99ll be publishing some -= 01 versions of the architecture, interface, and implementation drafts before= the submission deadline, so I think we should have slots for those document= s. We haven=E2=80=99t worked out the details yet, but I imagine having 15 mi= nutes architecture, 20 minutes interface, and 10 minutes implementation woul= d make sense based on the diffs. 

There should= also be a rev of the transport security survey and some initial feedback fr= om the security area, so an update from Chris or Kyle on that (15?) would be= good. 

One other agenda proposal I=E2=80=99d l= ike to make is a section highlighting some implementation experiences that c= an influence our drafts. I think NEAT has some details they=E2=80=99d like t= o share, and now that Apple has released its Network.framework new transport= API, I=E2=80=99d like to give a 10 minute talk sharing how it looks and som= e decisions we made while implementing. 

Best,=
Tommy

On Jun 28, 2018, at 4:53 AM, Zaheduzzaman Sar= ker <zaheduzzaman.sar= ker@ericsson.com> wrote:

=

Hi TAPS,=

 

We are planning for the IETF 102 Session. Please send your proposal(s= ) for agenda item and also mention =E2=80=93

 

  • The duration of timeslot you= prefer.
  • The points you would like to= discuss during the IETF102 meeting during your timeslot.<= /li>

 

BR

 

Zahed &a= mp; Aaron

=  

____________________= ___________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman= /listinfo/taps
= --Boundary_(ID_WuGVUsBXJWg6S0GqiF2KcQ)-- From nobody Thu Jun 28 08:07:53 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9985130DC8 for ; Thu, 28 Jun 2018 08:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 vOAGnXnaiLyW for ; Thu, 28 Jun 2018 08:07:48 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 BD90B130DC7 for ; Thu, 28 Jun 2018 08:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530198466; x=2394112066; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3mWWvGJy06gl0Alx2A8zLX6r8gc2+HLJMhtBA/vgDN0=; b=SXtgfYM+6ZHSLgEL73c0rZ5fG8T2269slP1Gkd97bC812o7uJ9A1mhIY/h8lgs/R BwNIEhio5cw6o7RvO4b6NGIcVQeTpQHPphODxLFerj1hKPUC43HUM68HMyr1KOtj 5Hm/ynZnTgxMGgc/4+MCXHgn6mcH0kGh9W4MnAcSv2erh20qJK2I816wZb9bknm6 ZJXmZQFFxUmGZPgK5SSfvxu+AjIlVmgnoREnRWlBrsUpxt2T7Paa7idMn/fIA6lI 2EollUE9IZvZ9w8/6A72wjY3JL+951OEWCTmeT5h0Hz8cDALT5YNuDD7kKUtaLa0 tTWSzOQJzsTY03LZ3geQEA==; X-AuditID: 11973e12-ef58c9e0000010b7-df-5b34f9c27854 Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id BA.7F.04279.2C9F43B5; Thu, 28 Jun 2018 08:07:46 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PB100JQEGOVJR80@ma1-mtap-s01.corp.apple.com>; Thu, 28 Jun 2018 08:07:45 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB100000GJ13T00@nwk-mmpp-sz13.apple.com>; Thu, 28 Jun 2018 08:07:44 -0700 (PDT) X-Va-A: X-Va-T-CD: f2a6fdaac1dbe71e4c3e5da188dce086 X-Va-E-CD: 1ec01e960ed10389a4e9db4f6ea860e7 X-Va-R-CD: 3a6bedfda87e541b96f0e68d214b1426 X-Va-CD: 0 X-Va-ID: 5ea41757-41a9-4d51-8c5c-e4c7992ff8dd X-V-A: X-V-T-CD: 942931952f08c814e8503761584bbb9a X-V-E-CD: 1ec01e960ed10389a4e9db4f6ea860e7 X-V-R-CD: 3a6bedfda87e541b96f0e68d214b1426 X-V-CD: 0 X-V-ID: c66360ec-e462-44a3-a421-977ca2be760f Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB100000GLXPX00@nwk-mmpp-sz13.apple.com>; Thu, 28 Jun 2018 08:07:44 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-28_07:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp15.corp.apple.com-10000_instance1 Received: from [17.234.4.103] (unknown [17.234.4.103]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PB100N5JGOV5A00@nwk-mmpp-sz13.apple.com>; Thu, 28 Jun 2018 08:07:43 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly X-Mailer: iPhone Mail (16A5308c) In-reply-to: <20180628144005.GA55656@tom-desk.erg.abdn.ac.uk> Date: Thu, 28 Jun 2018 08:07:43 -0700 Cc: Zaheduzzaman Sarker , "taps@ietf.org" Content-transfer-encoding: quoted-printable Message-id: <1BF96BA4-DA0D-4470-941A-4891A0884B69@apple.com> References: <83441BF4-BAB3-48AF-BFBD-E64FB3A3BEB3@apple.com> <20180628144005.GA55656@tom-desk.erg.abdn.ac.uk> To: Tom Jones X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLIsWRmVeSWpSXmKPExsUiqOHDqnvop0m0wYQPehZ3YiwmzljEZHHk 1DtmB2aPpwu62Dx+fb3K5rFkyU+mAOYoLpuU1JzMstQifbsEroxd27pYCx5wVWzc2MHewHiS o4uRk0NCwETi08cVjF2MXBxCAvuYJK4+OscOkuAVEJT4MfkeSxcjBwezgLrElCm5EDUbmSQ+ rWtng3C6mCRu3FzGBjGJXeLPrx0sELa2xJdpc+Ds5bMusMPYb/8uY4KwuSQWbD3NCmHrSnSv fc8IYbNJrD+xBKpGS2LK/IdsIEeA2G8fV8KEr63eAjWSU+L8l4nsECU6EhuWJ0Gc1skkcWbS A6jx2RLNF9dDjQyW+HOohxnEFhLoZ5KYPdERpFdYQEJi855EkLCwgKnE9oPNYNezCahIHP+2 gRmiVUFi9olHYGM4BWwlem51gH3OIqAqsfTwJLBzmAViJSZ3PGGCsLUlnry7wAoJThuJWx9+ sEPctpRRYufxJUwTGBVnIQX1LERQz0LSvoCReRWjUG5iZo5uZp6JXmJBQU6qXnJ+7iZGUHqY bie0g/HUKqtDjAIcjEo8vArXTaKFWBPLiitzDzFKc7AoifN2iAGFBNITS1KzU1MLUovii0pz UosPMTJxcEo1MBrPncu5RcI3QHtTKl9w+NmcbVvVPxbsDuedwnzHxjnm2qtgoQ9qf3hmPmcU Sstyb2WcNqmBa+XZjZpuCVMyZzLlT56wYMufk3J3jk9WLLfm3Oi6+rFMVuXTT9Vv3j15y+MU fSBs/6//WoEmq2MneDRvqy3r/nyAYXJgwe1pYo1p3as59nPx/FFiKc5INNRiLipOBAAVQr0M 8AIAAA== Archived-At: Subject: Re: [Taps] Call for agenda item for IETF 102 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 15:07:52 -0000 > On Jun 28, 2018, at 7:40 AM, Tom Jones wrote: >=20 >> On Thu, Jun 28, 2018 at 06:41:04AM -0700, Tommy Pauly wrote: >> One other agenda proposal I=E2=80=99d like to make is a section highlight= ing >> some implementation experiences that can influence our drafts. I think >> NEAT has some details they=E2=80=99d like to share, and now that Apple ha= s >> released its Network.framework new transport API, I=E2=80=99d like to giv= e a >> 10 minute talk sharing how it looks and some decisions we made while >> implementing.=20 >>=20 >=20 > Hi taps, >=20 > I understood from the interim that we would talk about policy system > implementations from implementers perspective (apple, neat, socket > intents...). I would like to talk about the policy work we did in NEAT > so we can feed this background into the drafts, ideally the other > systems would present so we could compare. >=20 > For that I would like 10 minutes to cover the NEAT Policy System. >=20 > Tommy, do you plan to cover policy and Network.framework or would you > just give an overview of the system?=20 >=20 > If both, is 10 minutes enough? Good point. If we want a section on policy implementations in general as the= focus, then I=E2=80=99d probably want 15 minutes to cover both the API surf= ace and how policy selection works.=20 Tommy >=20 > - Tom From tj@enoti.me Thu Jun 28 07:40:43 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05843130FF0 for ; Thu, 28 Jun 2018 07:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 Ba9jCiL9Ulpo for ; Thu, 28 Jun 2018 07:40:39 -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 BD0B6130E8F for ; Thu, 28 Jun 2018 07:40:39 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EB33121CFC; Thu, 28 Jun 2018 10:40:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 28 Jun 2018 10:40:38 -0400 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=PEV/FE /VaFieDBWvxtLbFcWCXARl5DRjeARa5YObq4M=; b=TDb9ThhMKyAH/sh6d0bAyb fHG7MxVkgJBHuk7/j2PnDmM+6yv1vTnjkyA+ZcVy6poaaHdWx05XRjRE0/JrTibu CsNYo554gvt4/jUZFR5iezUN+lAFl8fLngzdMomipkdk+maIuRGtDgAkOs3MYfOi xyKQmc1wQyTKAUsXfUAhsf3ENMIhxoSgpYzmIf0HyIke2nMJ6ex2kEVBP/CXydP/ /rCMYRV++98VQMcTpdfwj5m25F+dy+5oLxwPmv0CC17MZOZgDPf1/dh65YDRipYa ZhlhE0Z3kn1GOpPgoF6GR+X3UzbmbTd+th89sMAtLG/Wq5j1+b57cOpWI11aKXNA == X-ME-Proxy: X-ME-Sender: Received: from tom-desk.erg.abdn.ac.uk (unknown [137.50.17.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 26D99102EC; Thu, 28 Jun 2018 10:40:38 -0400 (EDT) Date: Thu, 28 Jun 2018 15:40:05 +0100 From: Tom Jones To: Tommy Pauly Cc: Zaheduzzaman Sarker , "taps@ietf.org" Message-ID: <20180628144005.GA55656@tom-desk.erg.abdn.ac.uk> References: <83441BF4-BAB3-48AF-BFBD-E64FB3A3BEB3@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83441BF4-BAB3-48AF-BFBD-E64FB3A3BEB3@apple.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: X-Mailman-Approved-At: Thu, 28 Jun 2018 08:17:22 -0700 Subject: Re: [Taps] Call for agenda item for IETF 102 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 14:51:27 -0000 On Thu, Jun 28, 2018 at 06:41:04AM -0700, Tommy Pauly wrote: > One other agenda proposal I’d like to make is a section highlighting > some implementation experiences that can influence our drafts. I think > NEAT has some details they’d like to share, and now that Apple has > released its Network.framework new transport API, I’d like to give a > 10 minute talk sharing how it looks and some decisions we made while > implementing. > Hi taps, I understood from the interim that we would talk about policy system implementations from implementers perspective (apple, neat, socket intents...). I would like to talk about the policy work we did in NEAT so we can feed this background into the drafts, ideally the other systems would present so we could compare. For that I would like 10 minutes to cover the NEAT Policy System. Tommy, do you plan to cover policy and Network.framework or would you just give an overview of the system? If both, is 10 minutes enough? - Tom From nobody Sat Jun 30 14:18:48 2018 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB8E124C04; Sat, 30 Jun 2018 14:18:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153039351958.26497.17463413221279349905@ietfa.amsl.com> Date: Sat, 30 Jun 2018 14:18:39 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transport-security-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.26 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 21:18:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : A Survey of Transport Security Protocols Authors : Tommy Pauly Colin Perkins Kyle Rose Christopher A. Wood Filename : draft-ietf-taps-transport-security-02.txt Pages : 33 Date : 2018-06-30 Abstract: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols. It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and WireGuard. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a TAPS system may need to support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transport-security-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/