From nobody Sun Jul 1 12:33:11 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 18A48130DDB; Sun, 1 Jul 2018 12:33:09 -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: <153047358899.27517.3613465326699729137@ietfa.amsl.com> Date: Sun, 01 Jul 2018 12:33:09 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-arch-01.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: Sun, 01 Jul 2018 19:33:10 -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 : An Architecture for Transport Services Authors : Tommy Pauly Brian Trammell Anna Brunstrom Godred Fairhurst Colin Perkins Philipp S. Tiesel Chris Wood Filename : draft-ietf-taps-arch-01.txt Pages : 21 Date : 2018-07-01 Abstract: This document provides an overview of the architecture of Transport Services, a system for exposing the features of transport protocols to applications. This architecture serves as a basis for Application Programming Interfaces (APIs) and implementations that provide flexible transport networking services. It defines the common set of terminology and concepts to be used in more detailed discussion of Transport Services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-arch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-arch-01 https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-arch-01 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 Sun Jul 1 12:34:25 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 2A6BC130E87; Sun, 1 Jul 2018 12:34:07 -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: <153047364711.27305.5912192625234238472@ietfa.amsl.com> Date: Sun, 01 Jul 2018 12:34:07 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-impl-01.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: Sun, 01 Jul 2018 19:34:17 -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 : Implementing Interfaces to Transport Services Authors : Anna Brunstrom Tommy Pauly Theresa Enghardt Karl-Johan Grinnemo Tom Jones Philipp S. Tiesel Colin Perkins Michael Welzl Filename : draft-ietf-taps-impl-01.txt Pages : 37 Date : 2018-07-01 Abstract: The Transport Services architecture [I-D.ietf-taps-arch] defines a system that allows applications to use transport networking protocols flexibly. This document serves as a guide to implementation on how to build such a system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-impl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-impl-01 https://datatracker.ietf.org/doc/html/draft-ietf-taps-impl-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-impl-01 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 Mon Jul 2 00:59:01 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 6FE80130DC4; Mon, 2 Jul 2018 00:58:42 -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: <153051832242.28046.5253562612405005835@ietfa.amsl.com> Date: Mon, 02 Jul 2018 00:58:42 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-interface-01.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: Mon, 02 Jul 2018 07:58:43 -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 : An Abstract Application Layer Interface to Transport Services Authors : Brian Trammell Michael Welzl Theresa Enghardt Godred Fairhurst Mirja Kuehlewind Colin Perkins Philipp S. Tiesel Chris Wood Filename : draft-ietf-taps-interface-01.txt Pages : 53 Date : 2018-07-02 Abstract: This document describes an abstract programming interface to the transport layer, following the Transport Services Architecture. It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime. It is intended to replace the traditional BSD sockets API as the lowest common denominator interface to the transport layer, in an environment where endpoints have multiple interfaces and potential transport protocols to select from. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-interface-01 https://datatracker.ietf.org/doc/html/draft-ietf-taps-interface-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-interface-01 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 Mon Jul 2 01:08:16 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 148DC130E46 for ; Mon, 2 Jul 2018 01:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zN1HqSsKznMn for ; Mon, 2 Jul 2018 01:08:12 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EE4130E41 for ; Mon, 2 Jul 2018 01:08:11 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9198C340F0F for ; Mon, 2 Jul 2018 10:08:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.14941); Mon, 2 Jul 2018 10:08:09 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Mon, 2 Jul 2018 10:08:09 +0200 (CEST) Received: from [195.176.111.9] (account ietf@trammell.ch HELO public-docking-cx-0330.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 60026574 for taps@ietf.org; Mon, 02 Jul 2018 10:08:08 +0200 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_DCF7350D-0E9C-4E08-A8E8-9088D635A375"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: References: <153051832260.28046.16139695011632973026.idtracker@ietfa.amsl.com> To: taps WG Date: Mon, 2 Jul 2018 10:08:08 +0200 X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Taps] new (arch, interface, impl)-01 drafts 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, 02 Jul 2018 08:08:15 -0000 --Apple-Mail=_DCF7350D-0E9C-4E08-A8E8-9088D635A375 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've submitted -01 versions of the -arch, -interface, and -impl = documents. To some extent, these are basically pre-Montreal snapshots of the state = of the documents as they continue being developed; the open issues we = know about are at https://github.com/taps-api/drafts/issues. Of note: - arch-01 has some editorial changes, and a new section explicitly = defining a method to determine whether two stacks are equivalent and can = therefore be safely raced. - interface-01 has been largely reorganized to try and keep relevant = properties together; indeed, due to this reorganization the diffs are = largely useless, and we apologize for that. We (the authors and editors) = are pretty sure the new macro-organization of the document is better, = but we are also not yet sure the specific micro-organization of each = property is correct. We should probably discuss this in person at the WG = meeting in Montreal. Cheers, Brian > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ietf-taps-interface-01.txt > Date: 2 July 2018 at 09:58:42 CEST > To: "Michael Welzl" , "Theresa Enghardt" = , "Christopher Wood" , = "Philipp S. Tiesel" , "Colin Perkins" = , "Brian Trammell" , "Gorry = Fairhurst" , "Mirja Kuehlewind" = , "Philipp Tiesel" = , "Godred Fairhurst" , = "Chris Wood" >=20 >=20 > A new version of I-D, draft-ietf-taps-interface-01.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Name: draft-ietf-taps-interface > Revision: 01 > Title: An Abstract Application Layer Interface to = Transport Services > Document date: 2018-07-02 > Group: taps > Pages: 53 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-taps-interface-01.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-taps-interface-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-taps-interface > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-interface-01 >=20 > Abstract: > This document describes an abstract programming interface to the > transport layer, following the Transport Services Architecture. It > supports the asynchronous, atomic transmission of messages over > transport protocols and network paths dynamically selected at > runtime. It is intended to replace the traditional BSD sockets API > as the lowest common denominator interface to the transport layer, = in > an environment where endpoints have multiple interfaces and = potential > transport protocols to select from. >=20 >=20 >=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 > The IETF Secretariat >=20 --Apple-Mail=_DCF7350D-0E9C-4E08-A8E8-9088D635A375 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAls53WgACgkQihK3vwvq RqNkAg/+IGoev5YClP4Fs4wYQoLxra2nDEp5E0xmaRCSxd7AeuvTCKnw8EiRvCb6 VdkV1HXaglbB9uYBhZW2Qs0rkh+SRgfQgdFoVa1X43bI95NSurEEGmcoxdoOFvr9 MuBH8Gr9Pun5VV77pBJ/kgfRA2L/mdDC6l3OWCTxiBHz7N6WJDhyzg9WaFVRwZcZ V+XHP8/yGNuPYsVYYSijk4gh4Ygac076X77cD9r9DFrrTyeENLr+4wiR1uwdYmaM nqP4cwjeTnbCSTBcy1uauEudUf6Zy5FTvKFTwD3QIGVP9cg6pczfrMz/5tG5mzjc TCIdLI14vWvjDNLwfb3Q14hFujXeIjax82MVfyxyNHZgKrXschlKAr1k1pVpO3ak cHAhKUkYeEP7OAQX+ym2FGiS1QYqX8ErXR/a+1rMKeZkAXb5tkTtDSHylEjGyC9x MHum8CBAutyFq3kBfYF3XyvfWw+31VagVMAu81/9RDSiUx6GRtCtM5fWScK8gk+V ekvoJwgWcxNZwrjK0T1FsCiyZh86H9vmlRktcGw5vhAd35lrefJpxh3tT8PBDo2Q tlnukQGryVAnFzqbTe5Jy0UHmFJbSyiW8xhuQMQAsVMlAr4DD8SvOxgwgzZvjaQb 2nqXmvSJ4YLrIc8Esiw91CAzFY9paO+5IcRt9hzu11TuU59f6o8= =GFr4 -----END PGP SIGNATURE----- --Apple-Mail=_DCF7350D-0E9C-4E08-A8E8-9088D635A375-- From nobody Mon Jul 2 02:04: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 6012A130E55 for ; Mon, 2 Jul 2018 02:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eRdcfxEKUgr4 for ; Mon, 2 Jul 2018 02:04:24 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:638:809:ff11:130:149:220:242]) by ietfa.amsl.com (Postfix) with ESMTP id E72CE1277BB for ; Mon, 2 Jul 2018 02:04:22 -0700 (PDT) Received: from [IPv6:2001:638:809:ff1f::8295:dc6d] (unknown [IPv6:2001:638:809:ff1f::8295:dc6d]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id F156B24E for ; Mon, 2 Jul 2018 11:04:20 +0200 (CEST) To: taps@ietf.org References: <83441BF4-BAB3-48AF-BFBD-E64FB3A3BEB3@apple.com> <20180628144005.GA55656@tom-desk.erg.abdn.ac.uk> From: Theresa Enghardt Openpgp: preference=signencrypt Autocrypt: addr=theresa@inet.tu-berlin.de; prefer-encrypt=mutual; keydata= xsBNBE2ktqYBCAC+3mnQMUTPJEPjKD0EaURx171qWkp4M60Zk97aeG6hSDU2GJAKG/IZ9/w7 NXLZxlfmfK9+y4Fia3aHfdhtdh+hZ/nkzhNHEahpt+coChrcaM/xyLmw7QOfYw6pLEe/snPY bdeiNdg3dsM8SFbLPvzs0REiAS9aVsux7fyDFmmJ4BGqJtjSzAv+l3X508wGeKgbUxT1Ceb5 /6DT5U1cPeSSCsXghHi5pcIfwW0KU00Ug56k3gSIRZ3YlahtBXVyIGOfPMLcvxpVypNejCt3 haLfbK6zI1GFHW39ietsk12DEODM0GiOhlCEx0qL+JxmR+A/IHKkINe5aj8Tl/Ie9TfZABEB AAHNKFRoZXJlc2EgRW5naGFyZHQgPHRoZXJlc2FAc29tZXNlcnZlci5kZT7CwJgEEwEKAEIC GyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAhkBFiEE7xG3phZ0Plgk2BDpgz007xx2oPcF AlqgJ4EFCRC919sACgkQgz007xx2oPf5lAf/VKgireR+/7Pg+sNigE+25bYRjezB5CPz0rPk YQndvFNbegCPKIXlIUbCwAuj1BW4qgBvNzq3X6lsGQ+wE30bKxnRLfjNW4PDGqbT2SsdJPOH b4KOnwaZjLGkDXaqABmkejHEg2hyi1on5JHEWFKz24qsFGosSCH3ZrOrKo9boZS5Md6+J0P/ y8gSCgS2ABYuo9VhyoDWD9hDRF1d7mvRUzACVieSxTOgwFsTCfsNmRnlZjTKjrEWhgpG1W0v 2J6xthOaE9J4TA2uWIi4t6+gvbiseXclzu2KxKrxy+xXEDD7hUb+JvvVLKkhjXwqbyx3lQoS Vy/MEw80YybnHyYFYM7ATQRNpLamAQgAz5qAZBAFqJoFLTYeKHqy149JBtI8Oh4Ywktc1ExL uZDP7KPjLKGJv5ebMHblU579BiSMgj35Bw4H7V5zzgB2DzklLG61ZAjNd6uFEdFNLtf+2/Qq jVqqZjlXfCIlNeq+2U002q1SPzLniX9xm4uHUfL3dZqgOkAWa4fB/X1WmMcXMQX+Npwv9plE JOLdd1J6/XtwsUmnJnkicDiuyb7G8v4fPDJtc0m2sQIdXSL71VIHbme5w8p8OYN41q0vqefB aMp0PnppG/K32Xa9/zW5fTKMcXxcCFZH7Ww2tpnFqZe0zhrL9UjAfQsgXurujk0OvEFhhkQo nVRXUYmLTM0EXQARAQABwsBlBBgBAgAPAhsMBQJW+lhqBQkNGAjEAAoJEIM9NO8cdqD3fK4H /2Jk05xp6eL8jTQO4kpdZtngbP4dxZ9vwgbdmKsN5Rln88Xm5HH8GXHzxU0hY2pLU0QoPzE5 B//tEbM34tYLNXSQScc8UVvfsh3Qup4OmagkAGHPs3lSLnvX17IUaDuhjJcHeDNE0h3ZmhLc XaHijcuxn2OvCVT3qpE5C6voC/IwNQSQGyPogDxfD1IpL7u3aqAmGnuIkLLCnm8DFl3wcGur w3wbVLuMV/WHXvIVgvvjf0fWCKBiyDMimVr2tPEMv/MgRU7BcuMvJx8I4fnC03Wm0BD6Wti+ 01JN0gcYBRNUHnEl/IzOo8A0lHSV5V9Hd/X5G7kkslTSK1xLZMabOCTCwHwEGAEKACYCGwwW IQTvEbemFnQ+WCTYEOmDPTTvHHag9wUCWqAnjQUJEL3X5wAKCRCDPTTvHHag99GLB/0f0E0h NezbAsWOt6PvBXxegI7nPeI3hNN4rP/ZcDQJCvs6OSpsSSWWeUa/LAk6wKyt+JwcYv55eTu1 Zd/wsybRA4DWkSADug3Kcans7rlYbiQ33eP08UD/ST6eSpa3O27DcoEClKrK0QFpqrB144bm YJZhrACOlIgjYGj6v0iCEf2aIyACxPTjg4+PdAwpJkDNMTMd6QS5hr8Bmp8XEsUTbtZ0NmkS rO9De5ogNtjHkdtP7G0sklzOkQ12JPDK8c3g/A1J9ZpzK/VMDtYzZC6yCzk5VHBokhDKm+gZ GXRhrBoceDGkuCz/HevYiqadNdOF5r5bH+JhKs8UW/isRtL/ Message-ID: <145f72a2-7802-82ad-b1d7-2baeb5503a5b@inet.tu-berlin.de> Date: Mon, 2 Jul 2018 11:04:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180628144005.GA55656@tom-desk.erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US 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: Mon, 02 Jul 2018 09:04:27 -0000 Hi TAPS, On 28.06.2018 16:40, Tom Jones wrote: > 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. I would also like 10 minutest to introduce the policy system of the Socket Intents prototype and to compare it to the other implementations. Best, Theresa From nobody Tue Jul 3 09:08:07 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 4129D13103B; Tue, 3 Jul 2018 09:00:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: spencerdawkins.ietf@gmail.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063362825.4893.642956457194293134.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:28 -0700 Archived-At: Subject: [Taps] taps - Requested session has been scheduled for IETF 102 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, 03 Jul 2018 16:00:40 -0000 Dear Aaron Falk, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. taps Session 1 (2:30 requested) Tuesday, 17 July 2018, Afternoon Session II 1550-1820 Room Name: Duluth size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/taps.ics Request Information: --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic panrg tls capport avtcore rtcweb ipsecme Second Priority: tcpinc mptcp saag mmusic tram irtfopen People who must be present: Aaron Falk Spencer Dawkins Zaheduzzaman Sarker Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jul 5 10:19:10 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 93669130E05 for ; Thu, 5 Jul 2018 10:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=FSU7h+c4; dkim=pass (1024-bit key) header.d=ericsson.com header.b=IN2DZNIT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep1NV0DTkwHz for ; Thu, 5 Jul 2018 10:19:01 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 8B297130DE1 for ; Thu, 5 Jul 2018 10:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530811139; 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=b0/Iz+g+HuH2NMF8q3ImPuiIsVdMQakgU/WO+28blE0=; b=FSU7h+c4HAkxfysmsLYzVLQ3RDLRJcNdooj+jHojoOZ9Yu93CdGsDZvs/jRsed3e u1QuBuVX4KkFSucczV3ugOZ6OrEY7AcCnVahAbVe7pAny8m7WTAk3ELJuFQQHKXq LHqgGwPWMd76p/G0ggyGv3S6cTZBzMeZ4WaU7HHtjQI=; X-AuditID: c1b4fb30-93dff70000000a77-a5-5b3e5303faa2 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.7A.02679.3035E3B5; Thu, 5 Jul 2018 19:18:59 +0200 (CEST) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 5 Jul 2018 19:18:59 +0200 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) 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, 5 Jul 2018 19:18:59 +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=b0/Iz+g+HuH2NMF8q3ImPuiIsVdMQakgU/WO+28blE0=; b=IN2DZNITuqbiwx2XNdpHQWpmt7wEq+Q9rb/JwpxTkW0g/j9KWKZWFf7WIfFF/jF7TqNdQTEb5q9Ck2nmI1Ku2hFz32d2R+6X8k+ixI2Prky0JraPnDKuROuuyZrPkb7uDJSeF6Jc3fVMzF3zcuYgN6j2fCFsghAvZ7Z6wmJZ6dc= Received: from VI1PR0701MB2255.eurprd07.prod.outlook.com (10.169.137.146) by VI1PR0701MB2288.eurprd07.prod.outlook.com (10.169.137.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.7; Thu, 5 Jul 2018 17:18:58 +0000 Received: from VI1PR0701MB2255.eurprd07.prod.outlook.com ([fe80::6455:da34:212d:f541]) by VI1PR0701MB2255.eurprd07.prod.outlook.com ([fe80::6455:da34:212d:f541%5]) with mapi id 15.20.0952.008; Thu, 5 Jul 2018 17:18:58 +0000 From: Zaheduzzaman Sarker To: "Brian Trammell (IETF)" , taps WG , "Anna Brunstrom" , Tommy Pauly Thread-Topic: [Taps] new (arch, interface, impl)-01 drafts Thread-Index: AQHUEdvsCp/Xkgxt4UWG9+Om9G4g7qSBBlKA Date: Thu, 5 Jul 2018 17:18:58 +0000 Message-ID: <125AAACD-7DCD-48B0-AD8B-5E8064FD1A09@ericsson.com> References: <153051832260.28046.16139695011632973026.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-originating-ip: [85.238.211.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2288; 7:MMVmiUaCk2bAhzzVHkef6ToShKNNXNmswYQtMvtO9V7US7a2zyoBWwJI1Wa0nnVE8nJGc3kzmjMimi+GJnTHGLQJsNSz+8CnH7ZUPB8mLR1jaNCJzTIAp4t1+OYdClQetsfOtwH0ZlFgM1pmInYsQXf/XmoAoaKtJ6J5DbD/8IGpj1I/TkF7t4Jn9EX3+bQYNBh43cPSdlHqlzk08+QoTIhZ0h3W1R6z3FFcJEWUpebtzePmumVQihVEq3ml7p21 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 71dcca83-6929-4463-e743-08d5e29b64de x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2288; x-ms-traffictypediagnostic: VI1PR0701MB2288: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(80524489315369)(33945880838080)(120809045254105)(166708455590820)(788757137089)(130329453890623)(31960201722614); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231280)(944501410)(52105095)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0701MB2288; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2288; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(396003)(346002)(136003)(366004)(189003)(199004)(22804003)(51914003)(316002)(6506007)(26005)(102836004)(186003)(2906002)(110136005)(58126008)(14454004)(66066001)(966005)(76176011)(478600001)(106356001)(105586002)(83716003)(2900100001)(97736004)(82746002)(68736007)(36756003)(86362001)(33656002)(5660300001)(7736002)(5250100002)(25786009)(2616005)(476003)(446003)(6246003)(6116002)(3846002)(305945005)(256004)(44832011)(6306002)(6486002)(14444005)(11346002)(229853002)(8676002)(81166006)(486006)(8936002)(6512007)(53936002)(81156014)(99286004)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2288; 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: xTg/pilbVOx4AbAj4drJoKVTIdTkx2AMuGCI/NXLZzpKnsgPavfhD9RK15QDcGEGSrXMJjxDdy6pULMCp8tnImKvk/8QluaXPn4Ixv+eZpBzj0x+amX8pQPeJnUfR8+nZsO7VJFxgpV7SliEnQvELu7aYiCaET2oAU8R6v7Lc5oISXauqOsBw6YxMaoh70jl8PhHp2q/sUMGeiX5quqdlhLKm1SIgYCJYPdtPdvj4kCG7g+nwuxjc5RQhfRlUqgXC5UzgStS19+GfkU5kxE2aeUcaKRJlEVGtfpp/48vU9yD0V+DvvJsazko5Tkqz7bsvQpyhuOrOBouLM3N2XhUZMUirwsim3GRL35tFwX6wuo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1BE73CCEE00E8440BF1D8BFF0BA3C8D0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 71dcca83-6929-4463-e743-08d5e29b64de X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2018 17:18:58.2306 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2288 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Se0hTYRzlu/fu7k4cfJnmL6PQ9SLNR2K0Qi0hcBKaZZBpYEsvKs0Hu1NS KJQ0TBeY+UitNLfSVNJ8ZaGEMtMpqfiIHlbolBIlTXSaPWzbXdB/5/c753DO7+NjSDuNwImJ T1SxykS5QkLbUKXhz9LcyTD/SK/FBam0b22UlD7N+kZLJ85Lb/V1CY5Rslb9Gi3Tan8Qst/D 2bRs+mUpFUpF2PjGsIr4VFbp6X/BJm6lLkeY3LT38i/NlQzUuCcXiRjAPlCmbxXmIhvGDvcg uNdzV8APKwhydU0UP2gIWDROWmQUzidh+eug1VNMwOpsNc0PMwhyPhlNHoahsS8YNCHmEHt8 G8HUnUAz3owPQ/NaEc3vj0DnTAvBY2/4PDFlwRTeBXPvNiwaMT4KI8ZX1hrXEFSN60gzITIR xr56iwHhLbDaz2MSO8L76QqCvw6DtmOI5LEDzBr+CMzYAXtAW1Mmze9doDpTZ9Vvh5GKPGQO A9xGQFWDnuIJd1gsKiLNhwEOhiFjCq8xIHid/VjIa/ZD1kKpgC8UDUUr2daAJMheeULzhnIE D9ZLrI12QO3NSSofeZf9V7zMlEHifdDwwpNfy6C3YJTgsQsU5k0KyywPswn0pdNUJRLUIgeO 5S4mxHp7e7DK+GiOS0r0SGRVTcj0dbpafnq1o9kvAd0IM0hiK3b184+0E8hTubSEbgQMKbEX d54yrcQx8rR0VpkUpUxRsFw32sZQEkexNKQ5wg7HylXsJZZNZpX/WIIROWWgh6K2XjWOu04O dqnn6/IdyIP9zidKtIO21e3hZ68Ktxa/VY+pTqrdvpePDOy+XxdUudPD4FMw1vAoaj7gnP5D 0NJAYMPxwvr14nafG9OOw6fFPpqU56E6g6foTPjq7PKcrjxsok69NB/q3PHGLUDRGJzsl1WT ssGpxz+mEemHaiQUFyc/4EoqOflflG2ZmTYDAAA= Archived-At: Subject: Re: [Taps] new (arch, interface, impl)-01 drafts 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, 05 Jul 2018 17:19:07 -0000 SGkgQnJpYW4gYW5kIHJlc3Qgb2YgdGhlIGF1dGhvcnMsDQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0 ZXMuIA0KDQpGb3IgdGhlIG1lZXRpbmcgYWdlbmRhLCBjb3VsZCB5b3UgcGxlYXNlIG1lbnRpb24g d2hvIHdpbGwgYmUgcHJlc2VudGluZyB0aGUgdXBkYXRlcyBwZXIgZHJhZnRzPw0KDQpCUg0KWmFo ZWQNCg0K77u/T24gMjAxOC0wNy0wMiwgMTA6MDgsICJUYXBzIG9uIGJlaGFsZiBvZiBCcmlhbiBU cmFtbWVsbCAoSUVURikiIDx0YXBzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGlldGZA dHJhbW1lbGwuY2g+IHdyb3RlOg0KDQogICAgR3JlZXRpbmdzLCBhbGwsDQogICAgDQogICAgV2Un dmUgc3VibWl0dGVkIC0wMSB2ZXJzaW9ucyBvZiB0aGUgLWFyY2gsIC1pbnRlcmZhY2UsIGFuZCAt aW1wbCBkb2N1bWVudHMuDQogICAgDQogICAgVG8gc29tZSBleHRlbnQsIHRoZXNlIGFyZSBiYXNp Y2FsbHkgcHJlLU1vbnRyZWFsIHNuYXBzaG90cyBvZiB0aGUgc3RhdGUgb2YgdGhlIGRvY3VtZW50 cyBhcyB0aGV5IGNvbnRpbnVlIGJlaW5nIGRldmVsb3BlZDsgdGhlIG9wZW4gaXNzdWVzIHdlIGtu b3cgYWJvdXQgYXJlIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS90YXBzLWFwaS9kcmFmdHMvaXNzdWVz Lg0KICAgIA0KICAgIE9mIG5vdGU6DQogICAgDQogICAgLSBhcmNoLTAxIGhhcyBzb21lIGVkaXRv cmlhbCBjaGFuZ2VzLCBhbmQgYSBuZXcgc2VjdGlvbiBleHBsaWNpdGx5IGRlZmluaW5nIGEgbWV0 aG9kIHRvIGRldGVybWluZSB3aGV0aGVyIHR3byBzdGFja3MgYXJlIGVxdWl2YWxlbnQgYW5kIGNh biB0aGVyZWZvcmUgYmUgc2FmZWx5IHJhY2VkLg0KICAgIA0KICAgIC0gaW50ZXJmYWNlLTAxIGhh cyBiZWVuIGxhcmdlbHkgcmVvcmdhbml6ZWQgdG8gdHJ5IGFuZCBrZWVwIHJlbGV2YW50IHByb3Bl cnRpZXMgdG9nZXRoZXI7IGluZGVlZCwgZHVlIHRvIHRoaXMgcmVvcmdhbml6YXRpb24gdGhlIGRp ZmZzIGFyZSBsYXJnZWx5IHVzZWxlc3MsIGFuZCB3ZSBhcG9sb2dpemUgZm9yIHRoYXQuIFdlICh0 aGUgYXV0aG9ycyBhbmQgZWRpdG9ycykgYXJlIHByZXR0eSBzdXJlIHRoZSBuZXcgbWFjcm8tb3Jn YW5pemF0aW9uIG9mIHRoZSBkb2N1bWVudCBpcyBiZXR0ZXIsIGJ1dCB3ZSBhcmUgYWxzbyBub3Qg eWV0IHN1cmUgdGhlIHNwZWNpZmljIG1pY3JvLW9yZ2FuaXphdGlvbiBvZiBlYWNoIHByb3BlcnR5 IGlzIGNvcnJlY3QuIFdlIHNob3VsZCBwcm9iYWJseSBkaXNjdXNzIHRoaXMgaW4gcGVyc29uIGF0 IHRoZSBXRyBtZWV0aW5nIGluIE1vbnRyZWFsLg0KICAgIA0KICAgIENoZWVycywNCiAgICANCiAg ICBCcmlhbg0KICAgIA0KICAgIA0KICAgIA0KICAgID4gQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6 DQogICAgPiANCiAgICA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KICAgID4gU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXRhcHMtaW50ZXJm YWNlLTAxLnR4dA0KICAgID4gRGF0ZTogMiBKdWx5IDIwMTggYXQgMDk6NTg6NDIgQ0VTVA0KICAg ID4gVG86ICJNaWNoYWVsIFdlbHpsIiA8bWljaGF3ZUBpZmkudWlvLm5vPiwgIlRoZXJlc2EgRW5n aGFyZHQiIDx0aGVyZXNhQGluZXQudHUtYmVybGluLmRlPiwgIkNocmlzdG9waGVyIFdvb2QiIDxj YXdvb2RAYXBwbGUuY29tPiwgIlBoaWxpcHAgUy4gVGllc2VsIiA8cGhpbGlwcEBpbmV0LnR1LWJl cmxpbi5kZT4sICJDb2xpbiBQZXJraW5zIiA8Y3NwQGNzcGVya2lucy5vcmc+LCAiQnJpYW4gVHJh bW1lbGwiIDxpZXRmQHRyYW1tZWxsLmNoPiwgIkdvcnJ5IEZhaXJodXJzdCIgPGdvcnJ5QGVyZy5h YmRuLmFjLnVrPiwgIk1pcmphIEt1ZWhsZXdpbmQiIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5l dGh6LmNoPiwgIlBoaWxpcHAgVGllc2VsIiA8cGhpbGlwcEBpbmV0LnR1LWJlcmxpbi5kZT4sICJH b2RyZWQgRmFpcmh1cnN0IiA8Z29ycnlAZXJnLmFiZG4uYWMudWs+LCAiQ2hyaXMgV29vZCIgPGNh d29vZEBhcHBsZS5jb20+DQogICAgPiANCiAgICA+IA0KICAgID4gQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWlldGYtdGFwcy1pbnRlcmZhY2UtMDEudHh0DQogICAgPiBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJyaWFuIFRyYW1tZWxsIGFuZCBwb3N0ZWQgdG8gdGhlDQog ICAgPiBJRVRGIHJlcG9zaXRvcnkuDQogICAgPiANCiAgICA+IE5hbWU6CQlkcmFmdC1pZXRmLXRh cHMtaW50ZXJmYWNlDQogICAgPiBSZXZpc2lvbjoJMDENCiAgICA+IFRpdGxlOgkJQW4gQWJzdHJh Y3QgQXBwbGljYXRpb24gTGF5ZXIgSW50ZXJmYWNlIHRvIFRyYW5zcG9ydCBTZXJ2aWNlcw0KICAg ID4gRG9jdW1lbnQgZGF0ZToJMjAxOC0wNy0wMg0KICAgID4gR3JvdXA6CQl0YXBzDQogICAgPiBQ YWdlczoJCTUzDQogICAgPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtdGFwcy1pbnRlcmZhY2UtMDEudHh0DQogICAgPiBTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10 YXBzLWludGVyZmFjZS8NCiAgICA+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi10YXBzLWludGVyZmFjZS0wMQ0KICAgID4gSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10YXBz LWludGVyZmFjZQ0KICAgID4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRhcHMtaW50ZXJmYWNlLTAxDQogICAgPiANCiAgICA+IEFi c3RyYWN0Og0KICAgID4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBhYnN0cmFjdCBwcm9n cmFtbWluZyBpbnRlcmZhY2UgdG8gdGhlDQogICAgPiAgIHRyYW5zcG9ydCBsYXllciwgZm9sbG93 aW5nIHRoZSBUcmFuc3BvcnQgU2VydmljZXMgQXJjaGl0ZWN0dXJlLiAgSXQNCiAgICA+ICAgc3Vw cG9ydHMgdGhlIGFzeW5jaHJvbm91cywgYXRvbWljIHRyYW5zbWlzc2lvbiBvZiBtZXNzYWdlcyBv dmVyDQogICAgPiAgIHRyYW5zcG9ydCBwcm90b2NvbHMgYW5kIG5ldHdvcmsgcGF0aHMgZHluYW1p Y2FsbHkgc2VsZWN0ZWQgYXQNCiAgICA+ICAgcnVudGltZS4gIEl0IGlzIGludGVuZGVkIHRvIHJl cGxhY2UgdGhlIHRyYWRpdGlvbmFsIEJTRCBzb2NrZXRzIEFQSQ0KICAgID4gICBhcyB0aGUgbG93 ZXN0IGNvbW1vbiBkZW5vbWluYXRvciBpbnRlcmZhY2UgdG8gdGhlIHRyYW5zcG9ydCBsYXllciwg aW4NCiAgICA+ICAgYW4gZW52aXJvbm1lbnQgd2hlcmUgZW5kcG9pbnRzIGhhdmUgbXVsdGlwbGUg aW50ZXJmYWNlcyBhbmQgcG90ZW50aWFsDQogICAgPiAgIHRyYW5zcG9ydCBwcm90b2NvbHMgdG8g c2VsZWN0IGZyb20uDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24NCiAgICA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgPiANCiAgICA+IFRoZSBJRVRG IFNlY3JldGFyaWF0DQogICAgPiANCiAgICANCiAgICANCg0K From nobody Thu Jul 5 14:29:22 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 A223212F295 for ; Thu, 5 Jul 2018 14:29:20 -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=CMgNPPfO; dkim=pass (1024-bit key) header.d=ericsson.com header.b=PgoWltw4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCI3xRnDOEDi for ; Thu, 5 Jul 2018 14:29:18 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 75355124D68 for ; Thu, 5 Jul 2018 14:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530826156; 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=6IfweIW+ml7EOoMPr88txu9s51dp38kGWR6570cr4tc=; b=CMgNPPfOA4hGeJhPuBtKGCDE8yGODFTFZ6tkpvW+tCANMoGCj7uVyQXyQfpZZ5HJ vnZime5OgDQSHlzvLfwTSj+AxvrtJf5ZC8qlN6B53i0kAr9SKHq0pyL7veRbu8em HfL4rTBm5Qv2jF0MZ79KFsEOwjNPn0Gu9BSnnpHUM1w=; X-AuditID: c1b4fb2d-20bff700000055ff-3f-5b3e8dac3d81 Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 73.F9.22015.CAD8E3B5; Thu, 5 Jul 2018 23:29:16 +0200 (CEST) Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 5 Jul 2018 23:29:16 +0200 Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 5 Jul 2018 23:29:16 +0200 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) 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, 5 Jul 2018 23:29:16 +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=6IfweIW+ml7EOoMPr88txu9s51dp38kGWR6570cr4tc=; b=PgoWltw4UGceHoS2w/mr+dZiXDflLaYiEiPCZJqIiUR3eqApq/j1FXOiCZPcuMXAMhkf9DaYTbdA+ImAiDkX7qyBSQrxIW9sdg8oGYrQ7JQvJonsOLd0C3SIzTxSefIn1dX43j1BvPbQZYDZef3XSKj0yOwhA+r5yAx/c9FeBx8= Received: from VI1PR0701MB2255.eurprd07.prod.outlook.com (10.169.137.146) by VI1PR0701MB2864.eurprd07.prod.outlook.com (10.173.71.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.16; Thu, 5 Jul 2018 21:29:15 +0000 Received: from VI1PR0701MB2255.eurprd07.prod.outlook.com ([fe80::6455:da34:212d:f541]) by VI1PR0701MB2255.eurprd07.prod.outlook.com ([fe80::6455:da34:212d:f541%5]) with mapi id 15.20.0952.008; Thu, 5 Jul 2018 21:29:15 +0000 From: Zaheduzzaman Sarker To: taps WG CC: Aaron Falk Thread-Topic: Agenda for IETF 102 Thread-Index: AQHUFKc5Q0BM3IWVQkynOHuSk51Wdg== Date: Thu, 5 Jul 2018 21:29:15 +0000 Message-ID: <1D792BAD-1CC2-42A3-A12A-E1DF23059438@ericsson.com> 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: [83.209.246.57] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2864; 7:oUswWWrFfwaUOZCQSN9HKFBaReSeRRsQrq0PRewo68ekvlAu8SN6l0+WPlUDAPCm6WI/CLeEsSbd3Vn9oDJkbpvLTv3S3YabSe3wcj6hbN/uIHFPMgmyklxnJjMZANThzg5bvREk3SSMrO21DJAHm96TWKhw2zu3ia1UW52gGoxYBwm9k0YZn05boUMwQ39lQSPAsjxcrQl3ixUAIt3snK1veiNgAOLYmDgpm6QWQfVz/YDPp4r+NR3J8aDt3lup x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ff1357a9-d37d-461c-1e26-08d5e2be5be1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2864; x-ms-traffictypediagnostic: VI1PR0701MB2864: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0701MB2864; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2864; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(136003)(376002)(346002)(189003)(199004)(82746002)(606006)(5660300001)(6506007)(8936002)(486006)(558084003)(36756003)(44832011)(86362001)(256004)(316002)(186003)(476003)(99286004)(7116003)(2616005)(478600001)(83716003)(58126008)(2900100001)(14454004)(97736004)(39060400002)(53936002)(25786009)(4326008)(6306002)(5250100002)(6512007)(7736002)(6916009)(6486002)(68736007)(236005)(6436002)(66066001)(102836004)(81166006)(8676002)(26005)(81156014)(6116002)(33656002)(105586002)(54896002)(2906002)(3846002)(106356001)(561944003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2864; 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: CgiQtToMlyu6Q2vi8gS6FceL1hJyM0tBhb5IZFN1vY6MaXft7uCkOwIhRQ7wUnuQpd5DLbbhiRW9A6SDwfAHXLTVmIVgFLJjGr9JdIbS/VRz3S0i/Ugb3dnPeP6h3oqBgZPK1SNwbDvZqv6cihVr7KE8bmBgKMH5oP3qVLYHpG1PivzxSlLE3pb0Z9iKUiOUzGrlX2bqYNYn/av3sISV0uyPIJn6VJSWTjs4UIA/9xqr0MdN4fl9GAhhj58f9C7iq2wTnnQP6q7SDp79J9aXhh8AuQfhRtm0GsYc5BWKoPzeA/PdEdfAz4MIZNrkrcUxR82I81J7YCNagDElbi8jEiI70LL1xE2o5FQMqeCKHvU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_1D792BAD1CC242A3A12AE1DF23059438ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ff1357a9-d37d-461c-1e26-08d5e2be5be1 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2018 21:29:15.4999 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2864 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe885m0dpcjZdPmhJLouKNrWLmomZUawPlUWgqFDLHVTSKTsm aRKOsnReELygwzRxla1ZNG8p84OjC2aQmGlFpmMq2cWy0hIx8/iu8Nvv/3/uLy9NSswCbzpF k8lqNapUmdCNqontuCg3l0TEB1pGA0OvLlQJQt8lRBLKTsOIi9JonCeiiTi3cDWbmpLFagMi zrgld82WExlmvwtzrTNUHrq9UY9caWB2Q1tHi0CP3GgJ8xjB0Nc6EotZBD90esF/UfGz2gWL RgIK+h4JeUExZSTYFu5QOFJFwL3RP86aCQTG5n6kRzQtZMLB0XiMn+jJ+MDn2j6St0lmM3wZ 0/LowayH2kY5j56MH9x0JOBkBTy1dxK8TTH+sFQcydsiZj/YC4YInhGzDn49M68wyXjB2/F6 Al/GgNH6gsQshSkHv5crLV1u2W7RCXFtIlTO5gtxjh8MFlY7eQMM1BchzO0E2Mr3YpbDt8pK Z8+jsFjR4pw1gMDSE8CvCcwOWHp/CNvpUN1sIbAdD82m49j2BVOJnSpDgYZVS2NOhLqGAtKw cqQYemvGKcPKQ22D+10BOMUPKorsLpi3Qn7tdScrwfT6lmB1zg1Em5CUYzkuLWnnLgWrTUnk uHSNQsNmWtDyH+ppXZA/RHc/HbAhhkaytaIoXUS8RKDK4rLTbAhoUuYp6j6xbInUquwcVpt+ Wns+leVsyIemZF4ihckaJ2GSVJnsOZbNYLX/ogTt6p2Hjuhs/Y6JXrXCnY0oH5gKiZ2bCxG8 oXLcXYtzL6ljSyVC/+lTUUti8YMrwzWoSekRPKhSvlSPvJr0fx79MQwdzGqYjDm8ida3nazZ Nzacu0fc3qSw1gb/viasN4RNE2tKm+e3FHp1T0q7rJH51qgPU0FnM56Uf/dNCJpZrL4cI6O4 ZFXQdlLLqf4C6JIzlT8DAAA= Archived-At: Subject: [Taps] Agenda 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, 05 Jul 2018 21:29:21 -0000 --_000_1D792BAD1CC242A3A12AE1DF23059438ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkhlcmUgaXMgdGhlIGFnZW5kYSBwcm9wb3NhbCAoaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9tZWV0aW5nLzEwMi9tYXRlcmlhbHMvYWdlbmRhLTEwMi10YXBzLTAwLnR4dCkgZm9y IElFVEYgMTAyLg0KDQpOb3RlOiBmb3Igc29tZSBwcmVzZW50YXRpb25zLCB3ZSBhcmUgd2FpdGlu ZyBmb3IgcHJlc2VudGVy4oCZcyBuYW1lLg0KDQpQbGVhc2UgY29tbWVudHMuDQoNCkJSDQpaYWhl ZA0K --_000_1D792BAD1CC242A3A12AE1DF23059438ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <7DF5611F608CA545BCE6300F1DDFD1D5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IlNWIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGVyZSBpcyB0 aGUgYWdlbmRhIHByb3Bvc2FsICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L21lZXRpbmcvMTAyL21hdGVyaWFscy9hZ2VuZGEtMTAyLXRhcHMtMDAudHh0Ij5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAyL21hdGVyaWFscy9hZ2VuZGEtMTAyLXRhcHMt MDAudHh0PC9hPikNCiBmb3IgSUVURiAxMDIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk5vdGU6IGZvciBzb21lIHBy ZXNlbnRhdGlvbnMsIHdlIGFyZSB3YWl0aW5nIGZvciBwcmVzZW50ZXLigJlzIG5hbWUuICZuYnNw OyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QbGVhc2UgY29tbWVudHMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkJS PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5aYWhlZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1D792BAD1CC242A3A12AE1DF23059438ericssoncom_-- From nobody Thu Jul 5 23:15: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 B874D130DE2 for ; Thu, 5 Jul 2018 23:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 6D4JpnlLmNSw for ; Thu, 5 Jul 2018 23:15:53 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F33130934 for ; Thu, 5 Jul 2018 23:15:51 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7A396340ED3; Fri, 6 Jul 2018 08:15:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.12520); Fri, 6 Jul 2018 08:15:49 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 6 Jul 2018 08:15:49 +0200 (CEST) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.78]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 60537143; Fri, 06 Jul 2018 08:15:43 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-F1C3E36E-CA60-4E8D-BC10-3449AE30A25C Mime-Version: 1.0 (1.0) From: "Brian Trammell (IETF)" X-Mailer: iPhone Mail (15F79) In-Reply-To: <1D792BAD-1CC2-42A3-A12A-E1DF23059438@ericsson.com> Date: Fri, 6 Jul 2018 08:15:43 +0200 Cc: taps WG , Aaron Falk Content-Transfer-Encoding: 7bit Message-Id: References: <1D792BAD-1CC2-42A3-A12A-E1DF23059438@ericsson.com> To: Zaheduzzaman Sarker Archived-At: Subject: Re: [Taps] Agenda 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: Fri, 06 Jul 2018 06:15:56 -0000 --Apple-Mail-F1C3E36E-CA60-4E8D-BC10-3449AE30A25C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable hi Zahed, Sign me up to present -interface. Thanks, cheers, B Sent from my iPhone > On 5 Jul 2018, at 23:29, Zaheduzzaman Sarker wrote: >=20 > Hi, > =20 > Here is the agenda proposal (https://datatracker.ietf.org/meeting/102/mate= rials/agenda-102-taps-00.txt) for IETF 102. > =20 > Note: for some presentations, we are waiting for presenter=E2=80=99s name.= =20 > =20 > Please comments. > =20 > BR > Zahed > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail-F1C3E36E-CA60-4E8D-BC10-3449AE30A25C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable hi Zahed,

Sign me up to p= resent -interface.

Thanks, cheers, B

Sent from my iPhone

On 5 Jul 2018, at 2= 3:29, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

Hi,

=  

Here i= s the agenda proposal (https://datatracker.ietf.org/meeting/102/ma= terials/agenda-102-taps-00.txt) for IETF 102.

=  

Note:= for some presentations, we are waiting for presenter=E2=80=99s name.  =   

=  

Pleas= e comments.

=  

BR

Zahed=

____________________= ___________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman= /listinfo/taps
= --Apple-Mail-F1C3E36E-CA60-4E8D-BC10-3449AE30A25C-- From nobody Fri Jul 6 04:04: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 3D9A4130E42 for ; Fri, 6 Jul 2018 04:04:29 -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 qHGmPwkhdG-a for ; Fri, 6 Jul 2018 04:04:25 -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 E9618124C04 for ; Fri, 6 Jul 2018 04:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530875065; x=2394788665; 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=GIHTUT+pyHIbl4u49RXdU5+aftzqk5GynG2myCc0FAk=; b=gGErO6FKzBIDKl09/pA1goXfsIZjvr4JvwlCCmGmdOnZbEm3xVYOtm5G7KqvwaLO 3D5XdndSshoCuVtBA/ZGYAgn/T9aa/3ggqxdC12Pd+qA0wYkqI+0dlkJQ9CIgx7P RpxWZ/PKdcK5btX1c1GC3ZC1eLUIdcjKJI9Ypv/aK6el+hKJvB30eeS/57VkuoCA +Czz4Hi7v0Bupr4/s1n5GkhXazhvLPsqvsCowzktny03n+KiQmhnlO0eVjlUq2bY TZobU3KRXoT3axw4NRx69r90T+zkNsSd0W2hruyqL84LqQkPOOffxEgkfX4NitmZ AnEKlS7ysnEGDffDbMsBDQ==; X-AuditID: 11973e16-6d9ff7000000740c-56-5b3f4cb993e0 Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) (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 26.08.29708.9BC4F3B5; Fri, 6 Jul 2018 04:04:25 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/7kQH+hjxuL58Jak2wAZsQ)" Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PBF00J1VYRDJ780@mr2-mtap-s02.rno.apple.com>; Fri, 06 Jul 2018 04:04:25 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBF00800YFGOC00@ma1-mmpp-sz09.apple.com>; Fri, 06 Jul 2018 04:04:24 -0700 (PDT) X-Va-A: X-Va-T-CD: 8f9ff3a9b19c7910a5ca80061ab485ca X-Va-E-CD: c81b8af19f4f436a808e9e8fd3d2b16a X-Va-R-CD: ce2bfdfd88d4396fc927bc49621ab24d X-Va-CD: 0 X-Va-ID: 416a3b0a-905a-401e-b174-38ed47ae5b77 X-V-A: X-V-T-CD: 8f9ff3a9b19c7910a5ca80061ab485ca X-V-E-CD: c81b8af19f4f436a808e9e8fd3d2b16a X-V-R-CD: ce2bfdfd88d4396fc927bc49621ab24d X-V-CD: 0 X-V-ID: 285a197e-3683-4ecb-a513-19ce37bec9e8 Received: from process_milters-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBF00M00XLWBX00@ma1-mmpp-sz09.apple.com>; Fri, 06 Jul 2018 04:04:24 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-06_02:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp21.corp.apple.com-10000_instance1 Received: from [17.234.192.215] (unknown [17.234.192.215]) by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PBF00MICYRCTV20@ma1-mmpp-sz09.apple.com>; Fri, 06 Jul 2018 04:04:24 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly X-Mailer: iPhone Mail (16A5308c) In-reply-to: Date: Fri, 06 Jul 2018 07:04:23 -0400 Cc: Zaheduzzaman Sarker , Aaron Falk , taps WG Message-id: References: <1D792BAD-1CC2-42A3-A12A-E1DF23059438@ericsson.com> To: "Brian Trammell (IETF)" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IR3PyoTXenj320wbwTOhZtv6exWmxsecdm cSfG4sipd8wOLB6/vl5l89g56y67x5IlP5k8nuyfyRLAEsVlk5Kak1mWWqRvl8CVceLFHfaC lZoVOz+dY2tg7FDtYuTkkBAwkTjct4u1i5GLQ0jgAJPEp+8rGEESvAKCEj8m32MBsZkFwiQm T/7KAlG0nkni7frFUE4Xk8S8mX/ZIEaxS/z5tYMFwtaWWPNvJZy98vsvRhi7pWE7E4TNJbFg 62lWCFtX4t78Z8wQNpvE+hNLoGq0JL7OfMsGY79Y380IY8/9vpwdwuaUOP9lIpDNAWTrSPSv doS4rZNJYvnjxVDzsyX6O05D1QdIPHp0lA2iaDKTxK5nX1hBmoUFJCQ270kEqREWUJf4t3Mu WC+bgIrE8W8boG5TkJh94hETSDmngL3Epct6IGEWAVWJQy8fQAOrQmLHxJdgJbwCNhLLT8SA hIUESiSe7/0Cdr2IgJ7Eyj//WCYwKsxCCupZSEE9C6ibGeiIKVNyIcLaEk/eXWCFsNUkFv5e xIQsvoCRbRWjUG5iZo5uZp65XmJBQU6qXnJ+7iZGUOqZbie2g/HhKqtDjAIcjEo8vAzSdtFC rIllxZW5hxilOViUxHkZZgCFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MJ5z6piWIXxxsr79 G2nefq3ylymcLgI+2nfNtsfG31695MYt/2s/puefi1hy6Mhn3ux/jXZPX3skpL5XL/j93OjS rtrgG7yO0y7sWXpK5khiSFHByZWCHzs2npn9p0THs1+haUXFRWmNfbkZlkurDDacdPj6///K tSmx5fm3mKfKyEf0CjZena/EUpyRaKjFXFScCAB0fcu9HgMAAA== Archived-At: Subject: Re: [Taps] Agenda 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: Fri, 06 Jul 2018 11:04:30 -0000 --Boundary_(ID_/7kQH+hjxuL58Jak2wAZsQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable I can do the architecture update presentation. Best, Tommy > On Jul 6, 2018, at 2:15 AM, Brian Trammell (IETF) wrote= : >=20 > hi Zahed, >=20 > Sign me up to present -interface. >=20 > Thanks, cheers, B >=20 > Sent from my iPhone >=20 >> On 5 Jul 2018, at 23:29, Zaheduzzaman Sarker wrote: >>=20 >> Hi, >> =20 >> Here is the agenda proposal (https://datatracker.ietf.org/meeting/102/mat= erials/agenda-102-taps-00.txt) for IETF 102. >> =20 >> Note: for some presentations, we are waiting for presenter=E2=80=99s name= . =20 >> =20 >> Please comments. >> =20 >> BR >> Zahed >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_/7kQH+hjxuL58Jak2wAZsQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable I can do the architecture update presentati= on.

Best,
Tommy

On Jul 6, 2018, at 2= :15 AM, Brian Trammell (IETF) <ietf@t= rammell.ch> wrote:

hi Zahed,<= div>
Sign me up to present -interface.

Thanks, cheers, B

Sent from my iPhon= e

On 5 Jul 2018, at 23:29, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

Hi,

=  

Here i= s the agenda proposal (https://datatracker.ietf.org/meeting/102/ma= terials/agenda-102-taps-00.txt) for IETF 102.

=  

Note:= for some presentations, we are waiting for presenter=E2=80=99s name.  =   

=  

Pleas= e comments.

=  

BR

Zahed=

____________________= ___________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman= /listinfo/taps
__________________________________________= _____
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
= --Boundary_(ID_/7kQH+hjxuL58Jak2wAZsQ)-- From nobody Fri Jul 6 04:14:24 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 3A90E13102C for ; Fri, 6 Jul 2018 04:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 cBLgqaTqvxOJ for ; Fri, 6 Jul 2018 04:14:11 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (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 51777130F11 for ; Fri, 6 Jul 2018 04:14:11 -0700 (PDT) To: Zaheduzzaman Sarker References: <1D792BAD-1CC2-42A3-A12A-E1DF23059438@ericsson.com> CC: , "aaron.falk@gmail.com" From: Anna Brunstrom Message-ID: <9760be0c-9bc6-c4e9-cbf5-9112c7bf4f9a@kau.se> Date: Fri, 6 Jul 2018 13:14:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------538442CF6521D464C1040180" Content-Language: en-US X-ClientProxiedBy: Exch-A2.personal.kau (130.243.19.83) To Exch-A2.personal.kau (130.243.19.83) Archived-At: Subject: Re: [Taps] Agenda 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: Fri, 06 Jul 2018 11:14:21 -0000 --------------538442CF6521D464C1040180 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Zahed, I will present the implementation draft. BR, Anna On 2018-07-06 13:04, Tommy Pauly wrote: > I can do the architecture update presentation. > > Best, > Tommy > > On Jul 6, 2018, at 2:15 AM, Brian Trammell (IETF) > wrote: > >> hi Zahed, >> >> Sign me up to present -interface. >> >> Thanks, cheers, B >> >> Sent from my iPhone >> >> On 5 Jul 2018, at 23:29, Zaheduzzaman Sarker >> > > wrote: >> >>> Hi, >>> >>> Here is the agenda proposal >>> (https://datatracker.ietf.org/meeting/102/materials/agenda-102-taps-00.txt) >>> for IETF 102. >>> >>> Note: for some presentations, we are waiting for presenter’s name. >>> >>> Please comments. >>> >>> BR >>> >>> Zahed >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --------------538442CF6521D464C1040180 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi Zahed,

I will present the implementation draft.

BR,
Anna


On 2018-07-06 13:04, Tommy Pauly wrote:
I can do the architecture update presentation.

Best,
Tommy

On Jul 6, 2018, at 2:15 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:

hi Zahed,

Sign me up to present -interface.

Thanks, cheers, B

Sent from my iPhone

On 5 Jul 2018, at 23:29, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:

Hi,

 

Here is the agenda proposal (https://datatracker.ietf.org/meeting/102/materials/agenda-102-taps-00.txt) for IETF 102.

 

Note: for some presentations, we are waiting for presenter’s name.    

 

Please comments.

 

BR

Zahed

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps


_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--------------538442CF6521D464C1040180-- From nobody Fri Jul 6 07:05:39 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 A594D13104A for ; Fri, 6 Jul 2018 07:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 3lM1ztSbsFWQ for ; Fri, 6 Jul 2018 07:05:27 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F329D13102B for ; Fri, 6 Jul 2018 07:05:26 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id a132-v6so6346508qkg.3 for ; Fri, 06 Jul 2018 07:05:26 -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:content-transfer-encoding:embedded-html; bh=riAdyTF7kYFuQ4xkSvrvz33do2qRfmYhd4tGAjGTRr8=; b=R8At1q4pHbVF2rbIhBELgxtKoJ/7zG22ROI4+Uc/dAMFgR78KkuBa1ZjnYXFlFjLMK ABNCi6LGQEhAwarOGOEV6kKLEGYymvBHl0Q1YQrsUCASIz7frzrtJIuSN21Dbg8++jst AHBtn3Mc1YkKcOkjnTBaZcZoz4VdrYgMpnt/pn4JmRRucstXKkcQDC86FHDRDGBXptC6 C5ALRP4luueoEN7kzcBduuzm+v9rhMirfRHnTgD3vYq2mhTomK1Xdro9P+cpZZ6/+FPu VPY29nK7558w1lfq7/FveCe0fZ18bjEg5ZLdVcYKojBChwpl3SBWv9bIR6ht7F7qHNjp VsPA== 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:content-transfer-encoding:embedded-html; bh=riAdyTF7kYFuQ4xkSvrvz33do2qRfmYhd4tGAjGTRr8=; b=VcY82HtuX6FRC02e3SUHGwbNLaGqnU8l8QAhot91R2rQcNJtm/HmO2JBuEMdjJEhQW PXHVCsyi4CLjryHfiFA1epl9/QTr5HRdKDJzDuDCt251hgq/rqygLpre1BNv0LH+/PAE Ibc6s3p/iv9lqdjMPyrVzl3xnDA7QvjzevBGt87diRt+C4TxLUCbwlPX8YXZBAvxHEo1 t4FL8/1hg7k4KFZU6QWD9dkKQORardNNObPZoz4Vbl1G20KvamZnqlxkevNqf2/gFrAV blEQllzniW7l0p/KCJ8vq80NLhDo53MgNmzEnyNj0fN9TmXcw99YlRtUfmy/ve5e1Puu hWcg== X-Gm-Message-State: APt69E0tKFZcdsu3LJQAkN0dNgeslUwmrY7baRVB46Yppqyg3HQIM7db TPCy9CNQSYY/Iir+c9/VtFs= X-Google-Smtp-Source: AAOMgpdt77cOUDLgaCQFvIj8iyu3wDnxABIRNIHEWpiuu9S/675bhf2Y83bgSiPHp5+z8dzvYBhaxg== X-Received: by 2002:a37:dd4:: with SMTP id 203-v6mr9023456qkn.14.1530885925995; Fri, 06 Jul 2018 07:05:25 -0700 (PDT) Received: from [172.19.34.35] ([2001:4878:a000:3000:394a:9e6:578f:e155]) by smtp.gmail.com with ESMTPSA id g84-v6sm5459182qkb.91.2018.07.06.07.05.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 07:05:25 -0700 (PDT) From: "Aaron Falk" To: "Anna Brunstrom" Cc: "Zaheduzzaman Sarker" , taps@ietf.org Date: Fri, 06 Jul 2018 10:05:22 -0400 X-Mailer: MailMate (1.11.2r5507) Message-ID: In-Reply-To: <9760be0c-9bc6-c4e9-cbf5-9112c7bf4f9a@kau.se> References: <1D792BAD-1CC2-42A3-A12A-E1DF23059438@ericsson.com> <9760be0c-9bc6-c4e9-cbf5-9112c7bf4f9a@kau.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_1EF4F88F-16F0-48F5-8B33-917F5D728153_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[489, 5885], "plain":[110, 1296], "uuid":"876B9F6F-9EFE-4BD2-A798-F1E3892BD22A"}] Archived-At: Subject: Re: [Taps] Agenda 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: Fri, 06 Jul 2018 14:05:38 -0000 --=_MailMate_1EF4F88F-16F0-48F5-8B33-917F5D728153_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks, all. I've added your names to the agenda. --aaron On 6 Jul 2018, at 7:14, Anna Brunstrom wrote: > Hi Zahed, > > I will present the implementation draft. > > BR, > Anna > > > On 2018-07-06 13:04, Tommy Pauly wrote: >> I can do the architecture update presentation. >> >> Best, >> Tommy >> >> On Jul 6, 2018, at 2:15 AM, Brian Trammell (IETF) > > wrote: >> >>> hi Zahed, >>> >>> Sign me up to present -interface. >>> >>> Thanks, cheers, B >>> >>> Sent from my iPhone >>> >>> On 5 Jul 2018, at 23:29, Zaheduzzaman Sarker >>> >> > wrote: >>> >>>> Hi, >>>> >>>> Here is the agenda proposal >>>> (https://datatracker.ietf.org/meeting/102/materials/agenda-102-taps-00.txt) >>>> for IETF 102. >>>> >>>> Note: for some presentations, we are waiting for presenter’s >>>> name. >>>> >>>> Please comments. >>>> >>>> BR >>>> >>>> Zahed >>>> >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps --=_MailMate_1EF4F88F-16F0-48F5-8B33-917F5D728153_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Thanks, all. I've added your names to the agenda.

--aaron

On 6 Jul 2018, at 7:14, Anna Brunstrom wrote:

Hi Zahed,

I will present the implementation draft.

BR,
Anna


On 2018-07-06 13:04, Tommy Pauly wrote= :
I can do the architecture update presentation.

Best,
Tommy

On Jul 6, 2018, at 2:15 AM, Brian Trammell (IETF) <iet= f@trammell.ch> wrote:

hi Zahed,

Sign me up to present -interface.

Thanks, cheers, B

Sent from my iPhone

On 5 Jul 2018, at 23:29, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.c= om> wrote:

Hi,

=C2=A0

Here is the agenda proposal (https://datatracker.ie= tf.org/meeting/102/materials/agenda-102-taps-00.txt) for IETF 102.

=C2=A0

Note: for some presentations, we are waiting for presenter=E2=80=99s name. =C2=A0=C2= =A0=C2=A0

=C2=A0

Please comments.=

=C2=A0

BR

Zahed

______________________________________________= _
Taps mailing list
Taps@ietf.org https://www.ietf.org/mailm= an/listinfo/taps
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/lis= tinfo/taps


_______________________________________________
Taps mailing list
Taps@=
ietf.org
https://www.ietf.org/mailman/listinfo/taps

--=_MailMate_1EF4F88F-16F0-48F5-8B33-917F5D728153_=-- From nobody Tue Jul 10 10:28:46 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 254D513117E for ; Tue, 10 Jul 2018 10:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-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=mjmontpetit-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 xsA7lk3RjcPD for ; Tue, 10 Jul 2018 10:28:37 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E35B1311A6 for ; Tue, 10 Jul 2018 10:28:33 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id l10-v6so19028466qtj.0 for ; Tue, 10 Jul 2018 10:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:to; bh=zNbKio1sApWaJSRyugiR/0AygIXfkxKHPu5cslhjWlM=; b=DvNSN1ARquv9EqYn1Ahgpbk8Ux8P6iqMQ+/UqpPveZtD6KHp3o+R8zh+wQE3/sS7bO 12AvkYz3noX0WWOHnpMV6bso0Nb1hrZHYXGvP3sy1qacf2H/IMOQo9msYocExdZWuJ6n nxWDR6crYIHslUMYDd8fJJs5L/Hw73gGdZBC57DG+kxpf7o1j3CbA2mQ+LeukvmWurlE DvLP0wwHqCOGVZpBlUCQtK55YQIeIXccV4Po6GVphCgY5kdn43UpKkFMrnByb1HNbnbT 2qafuob7/MqTUTd2qIusX9egoVwRh9YZw+ueIpLc1jLzC9vnkAkv4uTYrU7y4NW/aWGZ S/bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:to; bh=zNbKio1sApWaJSRyugiR/0AygIXfkxKHPu5cslhjWlM=; b=QAGtyCGEQz+3adsoKNlwZqXE8JKuuIL27jhBhV/aeOaXiS8lDA9ED02sVD0dIkDBqn wNu6kWYpPCnQs+FSpTQC1N0gNuBrtF2GmxHNo5OqeZ0dMb1FVbMwSnyM2VbI7KljV6w4 nBeDGtWEnb8zrwNIum2VF4sUOij3PEF2GLhnTh/6jdXjROmhshZPWC9fzwzb1AEMmz5e BQDUMSp0V8WhF4Tu+4xchpDkDCXhj/K+S7ZW/fLl5hhzd1o3xzH50lfVa3/bcpTPPJBe maXukXz5OyVQ+Wmm/zpbChGtTRkPCdQVf/WIDfntadkvhCvlJ3MzqWAEqJwBIzI/9CMZ c6jw== X-Gm-Message-State: APt69E0lGtu36yJXmb6swdbK+GzmhLsO2SVN9n1RNTzQ/9SoXOFPVtal Izp3g73kqQzbfJBb32W67TjT4PSpNhY= X-Google-Smtp-Source: AAOMgpfxDQ4H8BL+g0235tWh7eDvOmYLxicnprziUpg85tIlmYDbUPKZPB8u9BjpBjyKs/1VQ5GOkQ== X-Received: by 2002:ac8:65c5:: with SMTP id t5-v6mr23440352qto.314.1531243712259; Tue, 10 Jul 2018 10:28:32 -0700 (PDT) Received: from [10.10.26.254] ([38.97.127.241]) by smtp.gmail.com with ESMTPSA id p128-v6sm3341872qkb.29.2018.07.10.10.28.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 10:28:31 -0700 (PDT) From: Marie-Jose Montpetit Content-Type: multipart/alternative; boundary=Apple-Mail-4A8D44DA-CB72-4352-B464-BF07DAD2569A Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Tue, 10 Jul 2018 13:28:25 -0400 Message-Id: References: To: taps@ietf.org X-Mailer: iPhone Mail (15F79) Archived-At: Subject: [Taps] Fwd: [Idnet] IRTF Special Meeting on AI/ML in Networking - Thursday, August 18th - 18:10-19:10 (NMRG session) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 10 Jul 2018 17:28:44 -0000 --Apple-Mail-4A8D44DA-CB72-4352-B464-BF07DAD2569A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable For those of you interested in AI. And it=E2=80=99s Thursday July 19th. Marie-Jos=C3=A9 Montpetit marie@mjmontpetit.com mariejo@mit.edu Begin forwarded message: > From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" > Date: July 10, 2018 at 12:36:08 PM EDT > To: "idnet@ietf.org" > Subject: [Idnet] IRTF Special Meeting on AI/ML in Networking - Thursday, A= ugust 18th - 18:10-19:10 (NMRG session) >=20 > Dear IDNET community, > =20 > This meeting might be of interest. > Your inputs and participation will be appreciated. > =20 > Best regards, Marie-Jos=C3=A9 and Laurent. > =20 > From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Ciavaglia, Laurent (= Nokia - FR/Paris-Saclay) > Sent: Tuesday, July 10, 2018 5:54 PM > To: nmrg@irtf.org > Subject: [nmrg] IRTF Special Meeting on AI/ML in Networking - Thursday, Au= gust 18th - 18:10-19:10 (NMRG session) > =20 > IRTF Special Meeting on AI/ML in Networking > IETF 102, Montreal, Canada > Thursday, August 18th - 18:10-19:10 Afternoon session III > Duluth Meeting Room (NMRG session) > =20 > In the last few years and especially in the last few months, the use of Ar= tificial Intelligence and Machine Learning in networking went from a nice fu= ture application to an almost must have. Diverse networking operations from t= rend detection in traffic monitoring, beam assignment in 5G, congestion cont= rol and intent-based networking have identified AI as a means to improve the= ir overall performance under more and more dynamic conditions. One may also i= magine how AI can impact the very design of networks and protocols, or else h= ow to solve networking problems in original ways using novel and network-spe= cific artificial intelligence techniques. A number of special issues and con= ferences have already been organized under these themes and the community wa= nting to use these new tools is rapidly expanding. In addition to these, net= work architects and designers are also considering the impact of the use of A= I/ML on the network themselves. For example: AI in vehicles generates very l= arge data sets that need to be sent to the cloud for analysis or to rely on f= og/edge computing. Traffic engineering also requires to analyze very large a= mounts of real-time information that then needs to be sent back to the netwo= rk nodes for updates and new features. And the application landscape is rapi= dly expanding each with its own requirements on the network. > =20 > The meeting wants to bring together the IETF and IRTF community that has i= nterests and stakes in the development of both AI/ML based tools and on the n= etworks that will support them. While we are targeting an open discussion we= already have some presentations planned and you are all welcome to submit a= request before Friday, July 13th so we can finalize the agenda. > =20 > Hoping to see you in Montreal! > =20 > Marie-Jos=C3=A9 & Laurent > --- > _______________________________________________ > nmrg mailing list > nmrg@irtf.org > https://www.irtf.org/mailman/listinfo/nmrg > _______________________________________________ > IDNET mailing list > IDNET@ietf.org > https://www.ietf.org/mailman/listinfo/idnet --Apple-Mail-4A8D44DA-CB72-4352-B464-BF07DAD2569A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable For those of you interested in AI.

A= nd it=E2=80=99s Thursday July 19th.

Ma= rie-Jos=C3=A9 Montpetit

Begin forwarded message:

From: "Ciavaglia, Laurent (Nokia - FR/Paris-Sacl= ay)" <laurent.ciavaglia@no= kia.com>
Date: July 10, 2018 at 12:36:08 PM EDT
To: "idnet@ietf.org" <idnet@ietf.org>
Subject: [Idnet] IRT= F Special Meeting on AI/ML in Networking - Thursday, August 18th - 18:10-19:= 10 (NMRG session)

Dear IDNET community,

 

This meeting might be of interest.<= /span>

Your inputs and participation will be apprecia= ted.

 

Best regards, Marie-Jos=C3=A9 and Laurent.

 

=

From: nmrg [mailto:nmrg-bounces@irtf.org] On Behalf Of Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)
Sent: Tuesday, July 10, 2018 5:54 PM
To: nmrg@irtf.org
Subject: [nmrg] IRTF Special Meeting on AI/ML in Networking - Thursda= y, August 18th - 18:10-19:10 (NMRG session)

 

IRTF Special Meeting on AI/ML in Networking=

IETF 102, Montreal, Canada

Thursday, August 18th - 18:10-19:10 Afternoon session III=

Duluth Meeting Room (NMRG session)<= /p>

 

In the last few years and especially in the last few months,= the use of Artificial Intelligence and Machine Learning in networking went f= rom a nice future application to an almost must have. Diverse networking operations from trend detection in traffic mo= nitoring, beam assignment in 5G, congestion control and intent-based network= ing have identified AI as a means to improve their overall performance under= more and more dynamic conditions. One may also imagine how AI can impact the very design of networks and prot= ocols, or else how to solve networking problems in original ways using novel= and network-specific artificial intelligence techniques. A number of specia= l issues and conferences have already been organized under these themes and the community wanting to use t= hese new tools is rapidly expanding. In addition to these, network architect= s and designers are also considering the impact of the use of AI/ML on the n= etwork themselves. For example: AI in vehicles generates very large data sets that need to be sent to the c= loud for analysis or to rely on fog/edge computing. Traffic engineering also= requires to analyze very large amounts of real-time information that then n= eeds to be sent back to the network nodes for updates and new features. And the application landscape is rapidl= y expanding each with its own requirements on the network.=

 

The meeting wants to bring together the IETF and IRTF commun= ity that has interests and stakes in the development of both AI/ML based too= ls and on the networks that will support them. While we are targeting an open discussion we already have some presentation= s planned and you are all welcome to submit a request before Friday, July 13= th so we can finalize the agenda.

 

Hoping to see you in Montreal!

 

Marie-Jos=C3=A9 & Laurent

---

____________________= ___________________________
nmrg mailing list
nmrg@irtf.org
https://www.irtf.org/mailman= /listinfo/nmrg
_______________________________________________
IDN= ET mailing list
IDNET@ietf= .org
https://www.ietf.org/mailman/listinfo/idnet
= --Apple-Mail-4A8D44DA-CB72-4352-B464-BF07DAD2569A-- From nobody Mon Jul 16 09:00:00 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 92434131132 for ; Mon, 16 Jul 2018 08:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nm_-FfOM_vq7 for ; Mon, 16 Jul 2018 08:59:21 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5798131133 for ; Mon, 16 Jul 2018 08:59:20 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0F98C340DCC for ; Mon, 16 Jul 2018 17:59:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.17010); Mon, 16 Jul 2018 17:59:18 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Mon, 16 Jul 2018 17:59:17 +0200 (CEST) Received: from dhcp-853f.meeting.ietf.org (account ietf@trammell.ch [31.133.133.63] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 61509147 for taps@ietf.org; Mon, 16 Jul 2018 17:59:17 +0200 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_326095EB-2A58-4E7F-893C-F68F527047E8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <3CEEC76F-B560-4AB2-919C-25CF49D31A29@trammell.ch> Date: Mon, 16 Jul 2018 11:59:14 -0400 To: taps WG X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Taps] open issues on -interface X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 16 Jul 2018 15:59:39 -0000 --Apple-Mail=_326095EB-2A58-4E7F-893C-F68F527047E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all, In advance of tomorrow's meeting, here are a few changes and issues we'd = like to discuss: Reorganization of Properties ---------------------------- See [the PR][1]. We've reorganized the properties (selection, protocol, send, etc) into a = single section. We (the authors) are sure this is a better editorial = direction than what we had before, but we're not sure that the = organization we have is correct. We'll spend a little time during our = slot on this point Partial Sends and Receives -------------------------- See [the PR][2]. We've reworked how partial messages work, introducing a message context = by which sends on partial messages can be grouped. Idempotent Send --------------- See discussion on [the stale PR][3] and on the [issue][4]. This is bit = of a bikeshed (see also API designs for TCP Fast Open); the main problem = is in trading off API complexity versus control about when sends happen. = There are a few possibilities enumerated on the slides tomorrow: - Option 1: as in #124, hold any data sent until an explicit = Connection.Start() call. - Send() before Start() is 0RTT if idempotent. - Start() is always required, even if you don't know what 0RTT is. - Option 3: 0RTT behavior is implied by 0RTT selection properties. When Initiate() is called and selects a 0RTT-capable stack, the actual = initiation is delayed slightly to wait for the first Send(), which is = 0RTT if idempotent. - Note this makes racing 0RTT-capable and 0RTT-incapable stacks = impossible. - Option 3.5: as 3, but with a Preconnection.InitiateNow() to override = the wait-for-Send() behavior (e.g. for application protocols where the = server sends first) - Option 5: Add Preconnection.Send(), which initiates with 0RTT data. Other Open Issues ----------------- The following issues are still open, which we don't cover in the = -interface talk tomorrow. Please discuss these either on the = taps@ietf.org list, or in the GitHub issue tracker itself: - Explicit state storage in architecture and API? [#45][5] - Be explicit about when name resolution occurs [#102][6] - Evaluate the applicability of =C2=A76.3 to ICE-like protocols = [#103][7] - Multicast sources and sinks [#150][8] - Add delivered event? [#151][9] - Privacy considerations [#177][10] - What is the point of the closing state? [#182][11] - Clones and Entanglement [#202][12] - Max message and transmission size [#203][13] Cheers, Brian [1]: https://github.com/taps-api/drafts/pull/201 [2]: https://github.com/taps-api/drafts/pull/200 [3]: https://github.com/taps-api/drafts/pull/124 [4]: https://github.com/taps-api/drafts/issues/112 [5]: https://github.com/taps-api/drafts/issues/45 [6]: https://github.com/taps-api/drafts/issues/102 [7]: https://github.com/taps-api/drafts/issues/103 [8]: https://github.com/taps-api/drafts/issues/150 [9]: https://github.com/taps-api/drafts/issues/151 [10]: https://github.com/taps-api/drafts/issues/177 [11]: https://github.com/taps-api/drafts/issues/151 [12]: https://github.com/taps-api/drafts/issues/202 [13]: https://github.com/taps-api/drafts/issues/203 --Apple-Mail=_326095EB-2A58-4E7F-893C-F68F527047E8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAltMwNIACgkQihK3vwvq RqNyQA//bp8II/dXkkLOawyt0eZT/sFVeTIjrovqn/zM1rcUharTTiKqdFQ8IrR8 oDaWUn8sPXbTKXoN+nQzsNl0zo1I4woeuPacpmNgYFnZczkYW6sYXoG84lhmUN8a 5XeVI6K2+zntE8JZn0isMjpSM3aDN65bOH0JPFP6WM30CA7vpNeCbq0vtW3pJceH spTRtrlQpif3sVQsjAIb0I9pugVabKjHF8UizpC5XHwMuqWbIzY4xSi+evOdJbO9 nmKKRK7dop94Uioo1aLT20FxDZvdvKsLn6D3m56MIozTcL5MpFzCJOCiPAfqtLfl 17CrZjjkVB0zJi2x6StEY8ksfLWeuSSYNe7Un5AXrDlBOL0qL0tPhsEGas+Hm1kc 350DrS7cssrzH7wwdsJXp2tJzmYjD7NfYJOdsuEDasN40HBzN1mgKVQoqG0HDjUM aRqEEvmynO8uP6XSkHgtKhlKpx9CTwrWK99BrGJE/d6p/Pvk0yVuQK45r4ptA0b1 H/TWd0+YV9p4/OIeid51npHTC2os6NHdM377oJQPn3WPxreTeSBwb8IKsRkIW0tw 9k9WXcg9FHWh5QBS8TurNzZR54iOdnjv+oqe2Tr2r9Hi2dvKAY7bCJeJcruPklKc 54PxfUa2xtyHDjlqIqSeDPbwcNOW/Pe3OF6LWFHE9SjBCqnxf6k= =c0fx -----END PGP SIGNATURE----- --Apple-Mail=_326095EB-2A58-4E7F-893C-F68F527047E8-- From nobody Tue Jul 17 08:39:46 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 A8A17130FB2 for ; Tue, 17 Jul 2018 08:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIEH4XyKem8k for ; Tue, 17 Jul 2018 08:39:29 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEE9130ED4 for ; Tue, 17 Jul 2018 08:39:29 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id j185-v6so2525296ite.1 for ; Tue, 17 Jul 2018 08:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=ZNktsvtt2d/zBJ0VMJxScd0/+orPAFm8DuyOU4+0WDY=; b=mVXGCY9WyUlHdnMFOYfv82/q+xSkTiR7E1KKSW1MHYNGqlkZLSdUw9V4xP/aoxZM38 IHqokLLxlMGyZwLANGvPPhVmUW1VaQDZVXXcq4hY7hhv2qYV4ZVbQeq5gA2DWW/nKW/P srBL4K+B8pCOJBwS4YFDkY9E8aPoAyKD8QSds0FaHfzkBm+D6DZaqVdWdanZIgAz8oDn zgXCzx46Sptn7rAuTz0pNjEesSg9ZV8c+OzOF6xO2VR6R7clWwjH/IoPJzJWadxm3bLc F5meAAYm0nUfC6mueyNKj+2+4c6iCFwLw6fJEKrgCTxohZCMBm1vU510N+fmYjdwkV4m CBvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=ZNktsvtt2d/zBJ0VMJxScd0/+orPAFm8DuyOU4+0WDY=; b=sjknoISRLiqQj0glFkb57TwSOHjMFGryYQDf5COnlHFMA+TK5BaN2xSTSPXkvLrHKd 9rtLiOMwPvqWju+v11nZV1LMeJl9QxTknfz+EYyaFTbxg8S0Y3mm7802PhlYvrSGZQrI khvIsmFtcSw+EyRhUEteEtuabzgwoaYMZB43+fBVHR3ah9Zkp1EbRAGhOUj6ERxpMbpR jG4Fvl5kDH9GyoBSS8x3lbkV08Y/cFJbp1hFSI9PNc5c9ZSi0d+MKHH+h307MLf5eZjq c2bz9O69uGUU3eGbOkQpV40ML+HA1UYCtMp2xlDefIWtVc/XssE2/Nls/7BD7LhiPC5o qVqw== X-Gm-Message-State: AOUpUlHn4w5o2f5ZaPToksi7qkuS/nsPLLcULLE08idMdeXpGENIcPcf POxvhk4glZM2LBOc3bMQkvLW4/ASUmg= X-Google-Smtp-Source: AAOMgpfabDcTaXPsghWsIrDLU5ut9LMWzzyFZ+tik3m52ESyKfvK4wUqTMkBEXjREDF82upyPjxHzA== X-Received: by 2002:a24:f6c5:: with SMTP id u188-v6mr2199064ith.150.1531841968543; Tue, 17 Jul 2018 08:39:28 -0700 (PDT) Received: from [31.133.143.57] ([2001:67c:370:128:19c3:59b4:10d4:bae3]) by smtp.gmail.com with ESMTPSA id x94-v6sm810032ita.18.2018.07.17.08.39.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 08:39:27 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Tue, 17 Jul 2018 11:39:26 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_98A3BE18-8656-4240-AD05-B4F6D7BA99F0_=" Archived-At: Subject: [Taps] slides uploaded X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 17 Jul 2018 15:39:43 -0000 --=_MailMate_98A3BE18-8656-4240-AD05-B4F6D7BA99F0_= Content-Type: text/plain; format=flowed; markup=markdown All the slides to today's wg meeting have been uploaded to the meeting materials page. Grab them [here](https://datatracker.ietf.org/meeting/102/session/taps). --aaron & zahed --=_MailMate_98A3BE18-8656-4240-AD05-B4F6D7BA99F0_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

All the slides to today's wg meeting have been uploaded t= o the meeting materials page. Grab them here.

--aaron & zahed

--=_MailMate_98A3BE18-8656-4240-AD05-B4F6D7BA99F0_=-- From nobody Thu Jul 19 07:01:25 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 C0CB8130E92 for ; Thu, 19 Jul 2018 07:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 K0BLeXLNflOW for ; Thu, 19 Jul 2018 07:01:21 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id BD16C130EC4 for ; Thu, 19 Jul 2018 07:01:13 -0700 (PDT) Received: from dhcp-9c5e.meeting.ietf.org (unknown [31.133.156.94]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id C2DD81B00126 for ; Thu, 19 Jul 2018 15:01:12 +0100 (BST) Message-ID: <5B5099A0.1000801@erg.abdn.ac.uk> Date: Thu, 19 Jul 2018 10:01:04 -0400 From: G Fairhurst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "taps@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Taps] PvD with NEAT (influence the racing selection). X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 14:01:24 -0000 Some people asked Tom about using PvD with TAPS. I made this short video of a talk I gave a few weeks ago. If people are interested it's ~10 mininutes, and may give some ideas of how TAPS could let network information influence the racing selection. http://www.erg.abdn.ac.uk/video/PVD.mp4 Gorry From nobody Thu Jul 19 11:39: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 574B1131064; Thu, 19 Jul 2018 11:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOnFWk3B-4ql; Thu, 19 Jul 2018 11:39:30 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD52131118; Thu, 19 Jul 2018 11:39:30 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id o22-v6so6841573ioh.6; Thu, 19 Jul 2018 11:39:30 -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=bjpSGtPYffqwkSkzTCR9h1N9tEPzA1lmIt3j+/c/twI=; b=MiWLXdfUXqKeMzLPfQKJjP+/oEJ1cWHB6G0Qq0g4Y29BeV0sdhE04JyJzCd7/j/4hB +hwxADeCbHkZ0ItAjYDEzkFdKskwKLP1QgKH0hhcPx79M6Y4dUvtZZhdejMRvH850wL5 VFXqr+ngPRtHbz0116e+B7eTh/eGorKHtvn/PwjI9B5RrWlGNbROqxw0Sw7UK6IXJFdk SPkHdCo405mQBUbrydvzahZjbNgMg6jB7f0j08ykq+kPJ66AijOouVu2jwxMqbx0dXDQ mDNWwF1LKfknSAPbEhkdNXmBwapIA5sm74xtRI6lXWKqm7zKntll1SkEzyAKuO1zlRlL yaYA== 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=bjpSGtPYffqwkSkzTCR9h1N9tEPzA1lmIt3j+/c/twI=; b=iQ59unT1z3XlqQmSiGJPK65xOrQMmKz/r2gslbdegyB2Ss6o+7bckni/Xoa/Y//KA+ kwvNsy4kn65/Q7eIfsiCaqE00QuSJpvcXrusDIp0PP9Rcf0dFkhY3ivGgW5vBkzJrSSz TMPhbQVB+4NSBpZQDKNumqpYZO6gkld3qu7FqFmPxN7VsA3iPKHQ665RUICEJPSS2JYx R6uRs0lm+0g7hpIpQo+JQrz1oCvM0si1nrzUvfudlhHnhLm0H70ms6QaUv6m3EYERXhL mEfrrrry4svWuO4nWczBV8eSvYCQvRb/Nm1jLLzCuablk9VwCxCEvKHx5B0rtFYYSi23 j3og== X-Gm-Message-State: AOUpUlGxt7V1KKu3UYqS4sQH/UoV9ybraV7hh/qPWrNLQR413J+KFEmw FKJ21yVFTCIzi3gV/Vb+oXCsRDXnAHU= X-Google-Smtp-Source: AA+uWPx+73oGOzE0wL7UXNu8gUL/w4zrc9TxG+xf+e+N3eJDqZneVYIvtnVTqxwBeZReu/k3DM2EPQ== X-Received: by 2002:a6b:2353:: with SMTP id j80-v6mr8694929ioj.99.1532025569418; Thu, 19 Jul 2018 11:39:29 -0700 (PDT) Received: from [31.133.143.57] (dhcp-8f39.meeting.ietf.org. [31.133.143.57]) by smtp.gmail.com with ESMTPSA id 125-v6sm124993itm.29.2018.07.19.11.39.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 11:39:28 -0700 (PDT) From: "Aaron Falk" To: draft-ietf-taps-minset@ietf.org Cc: "taps WG" , "Theresa Enghardt" Date: Thu, 19 Jul 2018 14:39:20 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <170CA22B-1AE1-4999-8453-5E3D3FD4B2E7@gmail.com> 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_5EB42473-14A7-4E65-9606-D8B26780C59C_=" Embedded-HTML: [{"HTML":[574, 2834], "plain":[178, 1488], "uuid":"C203A466-6218-4DCB-9B52-B1F2465ECFB9"}] Archived-At: Subject: Re: [Taps] working group last call for draft-ietf-taps-minset X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 18:39:42 -0000 --=_MailMate_5EB42473-14A7-4E65-9606-D8B26780C59C_= Content-Type: text/plain; format=flowed Authors- I think I dropped the ball on this draft. Is it ready to go to Spencer for AD review or is there a rev needed? --aaron On 5 Jun 2018, at 11:12, Aaron Falk wrote: > 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_5EB42473-14A7-4E65-9606-D8B26780C59C_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Authors-

I think I dropped the ball on this draft. Is it ready to= go to Spencer for AD review or is there a rev needed?

--aaron

On 5 Jun 2018, at 11:12, Aaron Falk wrote:

<= 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_5EB42473-14A7-4E65-9606-D8B26780C59C_=-- From nobody Thu Jul 19 12:49:48 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 05C5C130DC6; Thu, 19 Jul 2018 12:49:47 -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 2OlydgTpUFHt; Thu, 19 Jul 2018 12:49:43 -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 7DCDE130DC9; Thu, 19 Jul 2018 12:49:43 -0700 (PDT) Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fgEvk-000769-CG; Thu, 19 Jul 2018 21:49:40 +0200 Received: from 114-65-11.connect.netcom.no ([176.11.65.114] helo=[100.68.65.113]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fgEvi-000CYX-HV; Thu, 19 Jul 2018 21:49:40 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-17A358E0-BE41-4720-8F54-CF48D0ABAAB0 Mime-Version: 1.0 (1.0) From: Michael Welzl X-Mailer: iPhone Mail (15D100) In-Reply-To: <170CA22B-1AE1-4999-8453-5E3D3FD4B2E7@gmail.com> Date: Thu, 19 Jul 2018 21:49:36 +0200 Cc: draft-ietf-taps-minset@ietf.org, taps WG , Theresa Enghardt Content-Transfer-Encoding: 7bit Message-Id: <1C687F96-D0AA-46FC-823A-3625C4B76AD4@ifi.uio.no> References: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> <3F4C0CD4-9D7A-42AD-9A1D-A19C47321E69@gmail.com> <170CA22B-1AE1-4999-8453-5E3D3FD4B2E7@gmail.com> To: Aaron Falk X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 176.11.65.114 is neither permitted nor denied by domain of ifi.uio.no) client-ip=176.11.65.114; envelope-from=michawe@ifi.uio.no; helo=[100.68.65.113]; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.108, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F5A0CFBB59881B03C07B3E90FAE380555E2142BB Archived-At: Subject: Re: [Taps] working group last call for draft-ietf-taps-minset X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 19:49:47 -0000 --Apple-Mail-17A358E0-BE41-4720-8F54-CF48D0ABAAB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable yes, ready! :) Sent from my iPhone > On 19 Jul 2018, at 20:39, Aaron Falk wrote: >=20 > Authors- >=20 > I think I dropped the ball on this draft. Is it ready to go to Spencer for= AD review or is there a rev needed? >=20 > --aaron >=20 > On 5 Jun 2018, at 11:12, Aaron Falk wrote: >=20 > WGLC for this doc is concluded and it is clear the document should be publ= ished. Theresa Enghardt will be the document shepherd. Thanks to the authors= & reviewers! >=20 > --aaron >=20 > On 30 May 2018, at 10:51, Aaron Falk wrote: >=20 > Reminder: working group last call concludes next Monday. Please review th= is doc and send comments &/or 'ready to publish'. >=20 > --aaron >=20 >> 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 com= ments until June 4th. >>=20 >> --aaron >>=20 >> On 10 May 2018, at 10:52, Aaron Falk wrote: >>=20 >> Dear TAPS working group, >>=20 >> As discussed in London, it's time to last call draft-ietf-taps-minset-03.= >>=20 >> A Minimal Set of Transport Services for TAPS Systems >> draft-ietf-taps-minset-03 >>=20 >> Abstract >>=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. 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 pla= nned to be an Informational RFC. Statements along the lines of 'ready to pub= lish' are also welcome. >>=20 >> WGLC will conclude in two weeks on May 24, 2018. >>=20 >> --aaron (for the chairs) >>=20 >=20 --Apple-Mail-17A358E0-BE41-4720-8F54-CF48D0ABAAB0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit yes, ready!   :)

Sent from my iPhone

On 19 Jul 2018, at 20:39, Aaron Falk <aaron.falk@gmail.com> wrote:

Authors-

I think I dropped the ball on this draft. Is it ready to go to Spencer for AD review or is there a rev needed?

--aaron

On 5 Jun 2018, at 11:12, Aaron Falk wrote:

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 <aaron.falk@gmail.com> 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)

--Apple-Mail-17A358E0-BE41-4720-8F54-CF48D0ABAAB0-- From nobody Thu Jul 19 12:51:33 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 0C765130DC6; Thu, 19 Jul 2018 12:51:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Aaron Falk To: X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, taps-chairs@ietf.org, Theresa Enghardt , theresa@inet.tu-berlin.de, taps@ietf.org Message-ID: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> Date: Thu, 19 Jul 2018 12:51:29 -0700 Archived-At: Subject: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 19:51:29 -0000 Aaron Falk has requested publication of draft-ietf-taps-minset-04 as Informational on behalf of the TAPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ From nobody Mon Jul 23 13:16:03 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 21E0A130F21 for ; Mon, 23 Jul 2018 13:16:01 -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 jov7Wziee4k8 for ; Mon, 23 Jul 2018 13:15:59 -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 137E212F1A6 for ; Mon, 23 Jul 2018 13:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1532376957; x=2396290557; 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=23iCcfHkKOB0I8yw7UtTD3+we6IltNmRLDDwvYxmhOU=; b=lRhpVqZsT+uVuJQtD1gLH55MFypUii+upDEjsBnJU0gg+THJge2276AojiO78h8z IciIdo91Juu/hXV5sb4+N1f648zTL+j7s+pmmsCyPBDBVnw3EtaIRMdTa4sX1MtN cDgfS1rkZnLmuvYZSmhf2QS40BviYAffaibTz80Z1xMlG53E0bRr5wLYljETaV1m thcnH4v8imCf56CMKsl5csZ8j59qGuwz0iLQrEWBoExVzMxIjpFY7C87QvBSD+PO a5EdJSSbdPPYsqXwkvSr5IEiMzU1JVKLmwHWtolK0uVYTmKL8uOI1MmhVRSeySom /7ZryjtTFGo7ZElFhONIaA==; X-AuditID: 11973e16-6d9ff7000000740c-45-5b56377db4e1 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-in7.apple.com (Apple Secure Mail Relay) with SMTP id E9.5A.29708.D77365B5; Mon, 23 Jul 2018 13:15:57 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lJGibOmrxcbsDznS2caL+Q)" 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 <0PCC00L7A5MJ3NE0@ma1-mtap-s03.corp.apple.com> for taps@ietf.org; Mon, 23 Jul 2018 13:15:57 -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 <0PCC00300516RK00@nwk-mmpp-sz09.apple.com> for taps@ietf.org; Mon, 23 Jul 2018 13:15:56 -0700 (PDT) X-Va-A: X-Va-T-CD: 5808c5f95406ec7719a15f5c3784581a X-Va-E-CD: 2b7ffef2a962bef8309cc0a2a0f33dfd X-Va-R-CD: db0b5e4a6826ed1ac08e568d5299f0a0 X-Va-CD: 0 X-Va-ID: 6bf7eaf0-44fc-42e0-82ea-fccbe26a430c X-V-A: X-V-T-CD: 5808c5f95406ec7719a15f5c3784581a X-V-E-CD: 2b7ffef2a962bef8309cc0a2a0f33dfd X-V-R-CD: db0b5e4a6826ed1ac08e568d5299f0a0 X-V-CD: 0 X-V-ID: 822990ba-2451-4490-94a5-81bac44d191b 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 <0PCC00B005K0CD00@nwk-mmpp-sz09.apple.com> for taps@ietf.org; Mon, 23 Jul 2018 13:15:55 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-23_04:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Received: from [17.234.47.79] (unknown [17.234.47.79]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PCC00B3W5MJMZB0@nwk-mmpp-sz09.apple.com> for taps@ietf.org; Mon, 23 Jul 2018 13:15:55 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Mon, 23 Jul 2018 13:15:53 -0700 To: taps WG X-Mailer: Apple Mail (2.3445.100.13.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsUiqOHDrltrHhZtMOuYucWdGAdGjyVLfjIF MEZx2aSk5mSWpRbp2yVwZRx+uoe1YLdxxZPuK4wNjE06XYycHBICJhJLT6xk6WLk4hAS2Mck cehNFytIgldAUOLH5HtACQ4OZoEwie+3GEHCQgKHmCS2/jCBqJ/DJHHz129miEHsEn9+7QCr lxDQlth72AjGXP5OC6JCW2Li9u3sEDaXxIKtp1khbF2J+V1zWCBsNon1J5YwQdhaEqc2H4Ga qCUxbUEuTLjv0CqopZwS579MhBqpI3G16yQbxGWzmSTWXGiGmpMt0fNrKzvEnGCJ/W+VIWoW Mkm83N0FNl9YQEJi855EkHI2ARWJ4982MEOENSW6Ol0h4WEj8e7UCjaQMIuAqsSnH0YgYREB aYk3c05DXaMmMf/2C9YJjLKzkEJwFiIEIUx1iSlTckEqmIEh8uTdBVYIW01i4e9FTMjiCxjZ VjEK5SZm5uhm5pnrJRYU5KTqJefnbmIExfp0O7EdjA9XWR1iFOBgVOLhvfAtNFqINbGsuDL3 EKM0B4uSOG+HR1C0kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaTbyttfV7d57mi/e3IvJc/ N96Lm7WG7bHGu6cfYgRs849GHGRqsTgn5GJxeOehA9ub5k6JuCC7Jva52yeG0PUvIxw5Tzc9 cNY/vC3/1bP9Rx6L5201mHrH17G+oEtDVsdfN2znjtVHr8nJq4teXPm9co+mTtqcgHWLGdXY 36Yab3xlmRZl901RiaU4I9FQi7moOBEA4wrz5NYCAAA= Archived-At: Subject: [Taps] To registry, or not to registry? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 23 Jul 2018 20:16:01 -0000 --Boundary_(ID_lJGibOmrxcbsDznS2caL+Q) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hello TAPS, Migrating a thread from GitHub to the email list, since it needs broad = WG input. I've pasted the discussion so far below. Essentially, the question is if we have a set of standard properties for = Transport Services APIs, should they have a formal registry or not? Thanks, Tommy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D https://github.com/taps-api/drafts/issues/210 Philipp: We will end up with a set Turns out we might need a lot of (protocol) = specific properties, we should discuss whether we need an IANA registry = of properties and how this will look like. =E2=80=A2 Include Types ? =E2=80=A2 Include Names ? =E2=80=A2 Some numeric representation ? What do we do with ENUM values? Mirja: I don't really understand why we would need a registry. Who would be = using the registry? Tommy: I agree that a registry seems unnecessary; this is not a matter of = protocol or on-the-wire standard. Philipp: If we don't want to clutter the basic API document, we will end up = having at least a half a dozen documents defining specific properties = for different protocols. Does anyone have a good alternative to collect all these except in an = IANA registry? Tommy: We do not need to have documents specify every property. Implementation = should be allowed to extend as they need. Brian: this discussion does suggest that we might want to be more explicit up = front in the interface document about the scope and purpose of the = document (i.e. this is meant primarily to define a standard API "shape", = not the particular strings and codepoints, etc.). I'll file an issue. Colin: I agree with @tfpauly that we don't need to document every property, and = with @britram that we're documenting the shape of an abstract API, but I = also see value in consistent property naming across concrete = implementations of that API. Some form of registry might make sense = here.= --Boundary_(ID_lJGibOmrxcbsDznS2caL+Q) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hello TAPS,

Migrating a thread from GitHub to the email list, since it = needs broad WG input. I've pasted the discussion so far below.

Essentially, the = question is if we have a set of standard properties for Transport = Services APIs, should they have a formal registry or not?

Thanks,
Tommy

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

https://github.com/taps-api/drafts/issues/210

Philipp:

We will end up = with a set Turns out we might need a lot of (protocol) specific = properties, we should discuss whether we need an IANA registry of = properties and how this will look like.
= =E2=80=A2 Include Types ?
= =E2=80=A2 Include Names ?
= =E2=80=A2 Some numeric representation ?
What do we do with ENUM values?

Mirja:
I don't = really understand why we would need a registry. Who would be using the = registry?

Tommy:
I agree = that a registry seems unnecessary; this is not a matter of protocol or = on-the-wire standard.

Philipp:
If we = don't want to clutter the basic API document, we will end up having at = least a half a dozen documents defining specific properties for = different protocols.
Does anyone have a good alternative = to collect all these except in an IANA registry?

Tommy:
We = do not need to have documents specify every property. = Implementation should be allowed to extend as they need.

Brian:
this discussion does suggest that we might want to be more = explicit up front in the interface document about the scope and purpose = of the document (i.e. this is meant primarily to define a standard API = "shape", not the particular strings and codepoints, etc.). I'll = file an issue.

Colin:
I agree = with @tfpauly that we don't need to document every property, = and with @britram that we're documenting the shape of an = abstract API, but I also see value in consistent property = naming across concrete implementations of that API. Some form of = registry might make sense here.
= --Boundary_(ID_lJGibOmrxcbsDznS2caL+Q)-- From nobody Mon Jul 23 13:33:00 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 1DD22130F2D for ; Mon, 23 Jul 2018 13:32:58 -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 yP0v1iiG2Iti for ; Mon, 23 Jul 2018 13:32:55 -0700 (PDT) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (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 BA811130E25 for ; Mon, 23 Jul 2018 13:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1532377975; x=2396291575; 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=wnzmTwoL9mHfk5QVXBMm0hAiVdTzykN7fIwd0FFYg+w=; b=UbHk4kELwJ1kjbL7vHMs4NpAqA9CQ0yNJrzc6sjRj1IvpYfmR12PWK6o7L5Mtvxy zdQmEZFdN6+wdyQvLS1ycD1ifDneWp93RUkkp4/bOw2pDPEimYN6Uvk1Y0+1Pb1H R6o75TVpVVzTlCODWk74KDWiL20OIAYQgOtHYx5Xf4UuU4UWA4FplE4xcTtade1h Mi8TZDN3uDtUYrtv+FvqZ4ryiEZL8guWK/M8nnyQ8E6+JlaAKMSsLB4XzCPCln9q XTRrsCAaaNxncEn98TLchyYv3ZUGqgXmkduZlPIMNVZxd3xNRJaZ4HTUBmqYGrV5 pZSLii9OI2RIT6x4miyduQ==; X-AuditID: 11ab0217-d0fff70000003e90-0b-5b563b765d35 Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id 75.8F.16016.67B365B5; Mon, 23 Jul 2018 13:32:55 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vSI2dgfkVaxj9mH9LuKFsQ)" Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PCC00HPQ6EUTK60@mr2-mtap-s03.rno.apple.com> for taps@ietf.org; Mon, 23 Jul 2018 13:32:54 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCC006006CM6000@nwk-mmpp-sz10.apple.com>; Mon, 23 Jul 2018 13:32:54 -0700 (PDT) X-Va-A: X-Va-T-CD: b6bb457c0a685d707884d44453bef0d4 X-Va-E-CD: 6abc0bb32f41bb0cde60660626bcabce X-Va-R-CD: 8aa863877eca29212e339190346a854a X-Va-CD: 0 X-Va-ID: 6bb157ed-04f6-4835-94f7-4d8e77b58600 X-V-A: X-V-T-CD: b6bb457c0a685d707884d44453bef0d4 X-V-E-CD: 6abc0bb32f41bb0cde60660626bcabce X-V-R-CD: 8aa863877eca29212e339190346a854a X-V-CD: 0 X-V-ID: 5d59213b-27b5-467c-a948-77975bf1b554 Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCC006006CU6800@nwk-mmpp-sz10.apple.com>; Mon, 23 Jul 2018 13:32:53 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-23_04:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp16.corp.apple.com-10000_instance1 Received: from [17.234.18.22] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PCC00FZC6ETW930@nwk-mmpp-sz10.apple.com>; Mon, 23 Jul 2018 13:32:53 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Mon, 23 Jul 2018 13:32:52 -0700 In-reply-to: Cc: taps WG To: Tommy Pauly References: X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUiuPlRu265dVi0wds9TBZ3YhwYPZYs+ckU wBjFZZOSmpNZllqkb5fAlfF//XPmgkbXiotnrjM1MHZbdzFyckgImEi0ztjE2MXIxSEkcJBJ YuWJp4wgCV4BQYkfk++xgNjMAmES93f9Y4crOv/qPTOE08Uk0XK3jQViFLvEn187oGxtiZ7v q1hh7H2b+uDi91/dZoSwuSQWbD0NVaMr8fbJIqgaNon1J5YwQdhaEs9m/gKq4QCz/zb5woRb Fv6CKueUOP9lIjuErSPxceJRJojbOpkkHq48ygyRyJbo+bUVqihY4vqWNqhvvjBKPN2ynw0k ISwgLdF14S7YMjagDQfWGEFCwkai8ftUZogSE4nND66B3cYioCrx8+xPsDingK3EzQ+/2SGh JS2x9NtksB9FBJQkOlZuBqsRAprT3TcP6l9Fif41h9gmMCrMQgrsWUiBPQvoCmYBdYkpU3Ih wtoST95dYIWw1SQW/l7EhCy+gJFtFaNwbmJmjm5mnpGxXmJBQU6qXnJ+7iZGUBJZzSS+g/Hz a8NDjAIcjEo8vBe+hUYLsSaWFVfmHmKU5mBREuf9sEssWkggPbEkNTs1tSC1KL6oNCe1+BAj EwenVAMja+OTxjpLV55tXx0v9cW79gfd+ra+/sBk14MqHz98flpxdRubVPLK280JtbODyx1X hd49fiFrlszi8/zVpjqLajIMDf4089uIqT1h7jYQOBK4+31bsVYpc12Xak7PobWzOUrmvkzN +3KT8dLsO/yHjlc/uX730+XHQS7l7rOm274NeJg/jfWYEktxRqKhFnNRcSIANcrgewMDAAA= Archived-At: Subject: Re: [Taps] To registry, or not to registry? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 23 Jul 2018 20:32:58 -0000 --Boundary_(ID_vSI2dgfkVaxj9mH9LuKFsQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable We had a similar discussion in the Babel WG regarding link types in our = data model - which isn't sent over the wire. We landed on having an IANA registry of strings so there is one place to = find the mapping from string to specification. We're planning on reserving all strings starting with an underscore "_" = for experimental use so the registry does not get in anyone's way. Apparently IANA registries have very low overhead. Hope this helps. David > On Jul 23, 2018, at 13:15, Tommy Pauly wrote: >=20 > Hello TAPS, >=20 > Migrating a thread from GitHub to the email list, since it needs broad = WG input. I've pasted the discussion so far below. >=20 > Essentially, the question is if we have a set of standard properties = for Transport Services APIs, should they have a formal registry or not? >=20 > Thanks, > Tommy >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > https://github.com/taps-api/drafts/issues/210 = >=20 > Philipp: >=20 > We will end up with a set Turns out we might need a lot of (protocol) = specific properties, we should discuss whether we need an IANA registry = of properties and how this will look like. > =E2=80=A2 Include Types ? > =E2=80=A2 Include Names ? > =E2=80=A2 Some numeric representation ? > What do we do with ENUM values? >=20 > Mirja: > I don't really understand why we would need a registry. Who would be = using the registry? >=20 > Tommy: > I agree that a registry seems unnecessary; this is not a matter of = protocol or on-the-wire standard. >=20 > Philipp: > If we don't want to clutter the basic API document, we will end up = having at least a half a dozen documents defining specific properties = for different protocols. > Does anyone have a good alternative to collect all these except in an = IANA registry? >=20 > Tommy: > We do not need to have documents specify every property. = Implementation should be allowed to extend as they need. >=20 > Brian: > this discussion does suggest that we might want to be more explicit up = front in the interface document about the scope and purpose of the = document (i.e. this is meant primarily to define a standard API "shape", = not the particular strings and codepoints, etc.). I'll file an issue. >=20 > Colin: > I agree with @tfpauly that we don't need to document every property, = and with @britram that we're documenting the shape of an abstract API, = but I also see value in consistent property naming across concrete = implementations of that API. Some form of registry might make sense = here. > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_vSI2dgfkVaxj9mH9LuKFsQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable We = had a similar discussion in the Babel WG regarding link types in our = data model - which isn't sent over the wire.
We landed on = having an IANA registry of strings so there is one place to find the = mapping from string to specification.
We're = planning on reserving all strings starting with an underscore "_" for = experimental use so the registry does not get in anyone's way.
Apparently IANA registries have very low overhead.
Hope this helps.

David


On Jul = 23, 2018, at 13:15, Tommy Pauly <tpauly@apple.com> wrote:

Hello = TAPS,

Migrating = a thread from GitHub to the email list, since it needs broad WG input. = I've pasted the discussion so far below.

Essentially, the question is if we have = a set of standard properties for Transport Services APIs, should they = have a formal registry or not?

Thanks,
Tommy

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

https://github.com/taps-api/drafts/issues/210

Philipp:

We will end up = with a set Turns out we might need a lot of (protocol) specific = properties, we should discuss whether we need an IANA registry of = properties and how this will look like.
= =E2=80=A2 Include Types ?
= =E2=80=A2 Include Names ?
= =E2=80=A2 Some numeric representation ?
What do we do with ENUM values?

Mirja:
I don't = really understand why we would need a registry. Who would be using the = registry?

Tommy:
I agree = that a registry seems unnecessary; this is not a matter of protocol or = on-the-wire standard.

Philipp:
If we = don't want to clutter the basic API document, we will end up having at = least a half a dozen documents defining specific properties for = different protocols.
Does anyone have a good alternative = to collect all these except in an IANA registry?

Tommy:
We = do not need to have documents specify every property. = Implementation should be allowed to extend as they need.

Brian:
this discussion does suggest that we might want to be more = explicit up front in the interface document about the scope and purpose = of the document (i.e. this is meant primarily to define a standard API = "shape", not the particular strings and codepoints, etc.). I'll = file an issue.

Colin:
I agree = with @tfpauly that we don't need to document every property, = and with @britram that we're documenting the shape of an = abstract API, but I also see value in consistent property = naming across concrete implementations of that API. Some form of = registry might make sense = here.
____________________________________________= ___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Boundary_(ID_vSI2dgfkVaxj9mH9LuKFsQ)-- From nobody Mon Jul 23 13:42:42 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 6E162130E25 for ; Mon, 23 Jul 2018 13:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZND_EkinTeZh for ; Mon, 23 Jul 2018 13:42:38 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57FDC130DF0 for ; Mon, 23 Jul 2018 13:42:38 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id t5-v6so2044793qtn.3 for ; Mon, 23 Jul 2018 13:42:38 -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; bh=w93UjS4c37kPGywpSYc4yOaMy0BcRaxb1DAa+bS7exo=; b=rFkNziQ+aPJmk7I0X64gMgG+gA640ozc7EuC0P/rw/6Jogjh89SWoomCA/OhLZuefw o1pz1vYurXzOUuNYzJZuURY7uemaluw8aE0GlOeveBSQ81izmRaRCQ0X+XqBizsh4/Oh UoHIem8QCK9xVuItSsjiMjOdinyJle/oOz7rDF16kuWu8aj00F+5BZCovty/1fgU0AKz 50EuPtzB5D62B+13tFYMyDFt9hJQ3g6l3dMNStxOOuK0UlHB/5GQtxA5L6vSFPunYUd4 OcVWGhZfJ51MRyyhZOTwr61j2C8fFPcNtcpSuIMX92Gnb5Zm28rc+iXLz/bLJcoce+ac zM6w== 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; bh=w93UjS4c37kPGywpSYc4yOaMy0BcRaxb1DAa+bS7exo=; b=nyl6/AzhLy4eqqtkqX2ULR5U+ACfXnkybE8st4UcU3zAsrXncZyGHEpo81o5pfQ/Lo 8mDo2dM1ZZkusywPoA6w3BLYtao26fARxkFVsq9zQnkZ2e/Z182/sobVKfgcIz0/0pRO 3tq3KfXDryJRIgVWCi96B9cR7gT1nQk8nZEQrbmjpUvslxkdnOp26wEiAhbgkaI1MuaE xY1xBcnZ9mmombIE9T0/0k0Da5ARSoXo4pI2yggaMslk84Iq0TRvOyMysOCTjjY1cXXD Hy5ImIiJZ9Sl9WnSr+D3sqABbcGvq1MXjoLLZYW45J20np+1S+sO1s+dvTquw/tLJNYa 6+lA== X-Gm-Message-State: AOUpUlEYrPTmbldZMwF3PaLjlz3DejqWt0migkkbo7u+QUnExDzdBg+u vmiVRWXssGXDzBD5i7v2wIgxsspU X-Google-Smtp-Source: AAOMgpfO2pDg+gIpACMzO9P7Ct9jl/5qb7H8U8Hvkg9yzinsO5oVycMzUWN23r372lIXWoTdexh5iA== X-Received: by 2002:aed:35fb:: with SMTP id d56-v6mr13543267qte.17.1532378557008; Mon, 23 Jul 2018 13:42:37 -0700 (PDT) Received: from [172.19.38.147] ([2001:4878:a000:3000:e93c:b718:474b:71d5]) by smtp.gmail.com with ESMTPSA id j45-v6sm8012295qta.46.2018.07.23.13.42.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jul 2018 13:42:36 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Cc: "Theresa Enghardt" , "Zaheduzzaman Sarker" Date: Mon, 23 Jul 2018 16:42:34 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_03131528-0CFE-4F41-B9DE-9719FECBCB8F_=" Archived-At: Subject: Re: [Taps] TAPS notes X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 23 Jul 2018 20:42:41 -0000 --=_MailMate_03131528-0CFE-4F41-B9DE-9719FECBCB8F_= Content-Type: text/plain; format=flowed; markup=markdown TAPS speakers & questioners, Please review the Etherpad notes from the meeting. Deep thanks to Theresa for doing such a thorough job and doing it quickly! --aaron On 23 Jul 2018, at 5:23, Theresa Enghardt wrote: > Hi Aaron, > > I had another look at the TAPS notes and double-checked some parts > with > the recording. > I'd consider them done now on my part, pending corrections from the > Working Group. > > See > https://etherpad.tools.ietf.org/p/notes-ietf-102-taps?useMonospaceFont=true > > Best, > Theresa --=_MailMate_03131528-0CFE-4F41-B9DE-9719FECBCB8F_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">TAPS speakers & questioners,

Please review the Etherpad notes from the meeting. Deep = thanks to Theresa for doing such a thorough job and doing it quickly!

=

--aaron

On 23 Jul 2018, at 5:23, Theresa Enghardt wrote:

Hi Aaron,

I had another look at the TAPS notes and double-checked some parts with the recording.
I'd consider them done now on my part, pending corrections from the
Working Group.

See
https://etherpad.tools.ietf.org/p/n= otes-ietf-102-taps?useMonospaceFont=3Dtrue

Best,
Theresa

--=_MailMate_03131528-0CFE-4F41-B9DE-9719FECBCB8F_=-- From nobody Mon Jul 23 17:21: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 30D3D130E71 for ; Mon, 23 Jul 2018 17:21: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 eVFwu1XQDBcY for ; Mon, 23 Jul 2018 17:21:47 -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 19D14130E50 for ; Mon, 23 Jul 2018 17:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1532391706; x=2396305306; 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=QY9qTzR9Of0N+u2YynVnurflbcOR55HqVubVW/x3QA4=; b=FlAw1NMVQWC3+ppY55OY1huyQrSI14UVdOBIqkzmQaCMHGM3Dnf0hGjIq6SnHl22 uOJULpgapwEUlmXb87C0NYMx/1GwteqH/SUcKZS9xxrZwH42/0M60q4i4zDBseRY kShDLy3O+R5I+TJBff6FRTaYvmOKTqoiE6g9+l8KEl1gz9QIhEPlY46435nNLsDc p0R4Yhmcp5DdPMSUfOGiAN+szrxLeS/Q6krelDj81k4e7H/o22RqHRI+Y7BO98eR 7YDl7ItgoDP+Kcu6DgqwaHoCDArghV7/0/TYXpsZOkUPZ2pz2Muf8MGSAxnk+M3U DFDaOD3gzsm/e9WPSakVJQ==; X-AuditID: 11973e11-a14739e000005b22-63-5b56711a82d1 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 80.9C.23330.A11765B5; Mon, 23 Jul 2018 17:21:46 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PCC002ECH09FY50@ma1-mtap-s03.corp.apple.com>; Mon, 23 Jul 2018 17:21:46 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCC00A00GK0KC00@nwk-mmpp-sz12.apple.com>; Mon, 23 Jul 2018 17:21:45 -0700 (PDT) X-Va-A: X-Va-T-CD: 9b07c31571f9e83b80203e0da6d4d958 X-Va-E-CD: fb0e756882befa175fc67125f6d8858b X-Va-R-CD: a98e0002a67f261a76e506e43f661cea X-Va-CD: 0 X-Va-ID: 6a3d3174-a856-4db9-8643-a3f6f51a592e X-V-A: X-V-T-CD: 9b07c31571f9e83b80203e0da6d4d958 X-V-E-CD: fb0e756882befa175fc67125f6d8858b X-V-R-CD: a98e0002a67f261a76e506e43f661cea X-V-CD: 0 X-V-ID: 722b34bc-17e9-4c56-a6a7-df340398d566 Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCC00G00GXFML00@nwk-mmpp-sz12.apple.com>; Mon, 23 Jul 2018 17:21:43 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-23_07:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Received: from [17.234.69.239] (unknown [17.234.69.239]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PCC003BCH068T00@nwk-mmpp-sz12.apple.com>; Mon, 23 Jul 2018 17:21:43 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> Date: Mon, 23 Jul 2018 17:21:41 -0700 Cc: "gorry@erg.abdn.ac.uk" Message-id: References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> To: Fernando Gont , taps WG X-Mailer: Apple Mail (2.3445.100.13.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLIsWRmVeSWpSXmKPExsUiqOHDritVGBZt8GizqcWTVW/YLF63zWa0 uBPjwOzR8/kFk8eSJT+ZPD4c6mEPYI7isklJzcksSy3St0vgyph29gVLwT2BiqN7d7I2MG7i 7WLk5JAQMJFoObqdqYuRi0NIYB+TxP8jh9hAErwCghI/Jt9j6WLk4GAWkJc4eF4WJMwsoCXx /VErC0T9RiaJM/vuQjldTBI/mu+wQUxll/jzawcLhK0t8erfJjj79oy3jDD25yk/mCBsLokF W0+zQti6Ep/nHWKGsNkk1p9YAlWjJfH12gM4u+HSMjYYe8LxM1DzOSXOf5nIDmHrSBxrOs8O cVwnk0R7w32oxdkS01a3MoN8JiEQLLH/rTJEzUQmiYX7f4PFhQUkJDbvSQQpFxZQk9j5+jbY LjYBFYnj3zaA3cYp4CzR1tIPdjOLgKrEoV/9LJAQMpQ4taGZERKINhKPpmwAB6KQQLXE7eXc IGERASeJRXt2Mk5gVJyFFNSzEEE9CymoFzAyr2IUyk3MzNHNzDPSSywoyEnVS87P3cQISg/T 7QR3MB5fZXWIUYCDUYmH98K30Ggh1sSy4srcQ4zSHCxK4rwbUsKihQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTAGmR+KVXf6Pee5DMOvmG2mSbE+vPumrT7zYw3jvTv7q88snqZ2YPcfl8K3 MT3lem97on++/CrRdfQqw0G1l4s4a1oblOcv+b5QwfLny8tyahMXXPlvo8h7S/Wk1qWMx9KC UxlMC998+ZipKyYxW5aH7fCl6yHbdeY88TnmkXdm1RTLx5eaJk6wV2Ipzkg01GIuKk4EAJNc hsvwAgAA Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 24 Jul 2018 00:21:51 -0000 Picking this thread up again, I would like to see us incorporate IPv6 address selection into a post-sockets API model. Here's a straw man proposal of how we can expose this via the TAPS Interface: - A new property for Local Address Preference, which can be a tuple of: 1. Stable/Public 2. Temporary/Private 3. Unique For Connection - Listeners would default to (1). Connections would default to (2) - If you specify (3), the system will try to get an entirely new IPv6 address that has never been used before - You can find out the address you used on your Listener/Connection This type of API would allow us to add in the functionality Erik had asked for, to allow a client to be able to request a new address. The other alternative would be to have some out-of-band API to request a new API, but I think marking this on a connection is preferable, since it allows us to enforce this per-path and per-protocol even. What do people think? Best, Tommy > On May 24, 2018, at 5:11 AM, Fernando Gont wrote: > > Folks, > > Any thoughts? > > Thanks! > Fernando > > > > > On 03/21/2018 07:58 PM, Fernando Gont wrote: >> Folks, >> >> Based on the feedback received today, I have split our document >> >> into this two documents: >> >> * Problem statement with respect to limitations of the Sockets API: >> >> >> * Analysis of IPv6 address properties: >> >> >> Your feedback will be appreciated. We'd also appreciate guidance on how >> to move forward. :-) >> >> Thanks! >> >> Best regards, >> > > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Jul 24 02:23:42 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 9B05A130E41 for ; Tue, 24 Jul 2018 02:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 o6D27r4oSuHV for ; Tue, 24 Jul 2018 02:23:38 -0700 (PDT) Received: from know-smtprelay-omc-1.server.virginmedia.net (know-smtprelay-omc-1.server.virginmedia.net [80.0.253.65]) (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 85488130E40 for ; Tue, 24 Jul 2018 02:23:36 -0700 (PDT) Received: from [192.168.1.35] ([79.64.221.101]) by cmsmtp with ESMTPA id htXZfgmAnqTQPhtXaf9tSR; Tue, 24 Jul 2018 10:23:34 +0100 X-Originating-IP: [79.64.221.101] X-Authenticated-User: john.s.grant@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=TO5rtWta c=1 sm=1 tr=0 a=enF7lH1AlO9fobKiMINR1A==:117 a=enF7lH1AlO9fobKiMINR1A==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=le6d79QuAAAA:8 a=GjvupxNyDNJAsXCVcHEA:9 a=QEXdDO2ut3YA:10 a=t-IPkPogAAAA:8 a=U6bCLeduiYQ24tCqYZ4A:9 a=xuGZkKCjndHQqW4G:21 a=_W_S_7VecoQA:10 a=QbAMNLWdp4a7deKPGBBn:22 To: taps@ietf.org References: From: John Grant Message-ID: <12728b70-7f78-ceed-059f-fc67b7b0a994@ninetiles.com> Date: Tue, 24 Jul 2018 10:23:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------323EEBCA073FF09A7FC716BB" Content-Language: en-GB X-CMAE-Envelope: MS4wfN9VYZZdTwCu/0fLlX/n9uFIR1gwZlepiNXvLnZSQj1/8NYcWGJ8FQUgZeUaDgXROTBVobxzsDA0rG4/FeL09mrqXkvT7M3J6ly/sqoRuFhNEJimTriU ODtwdoFjLY1r8PylkeF3A/FaS2PYRlaTKS8hwgXCwtcLb5uoeHw6uWdt Archived-At: Subject: Re: [Taps] To registry, or not to registry? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 24 Jul 2018 09:23:41 -0000 This is a multi-part message in MIME format. --------------323EEBCA073FF09A7FC716BB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 23/07/2018 21:15, Tommy Pauly wrote: > Hello TAPS, > > Migrating a thread from GitHub to the email list, since it needs broad > WG input. I've pasted the discussion so far below. > > Essentially, the question is if we have a set of standard properties > for Transport Services APIs, should they have a formal registry or not? Maybe call it an ontology, as in metadata libraries, rather than a registry. The API is an interface between the application and the network, so it needs to provide an abstraction of the service the network provides that can be understood by each side without having to know too much about how the other side is implemented. There's been some debate about that in the DetNet group recently, too. Anyway, the API should allow the application to specify byte stream or packet, constant bit rate or bursty, latency requirements, tolerance of packet loss or corruption, etc, but not ask it to select a particular protocol such as TCP. Similarly, it should provide more abstract ways for the application to say what it wants to talk to, e.g. specify a URL directly rather than having to make a separate call of gethostbyname(). Of course, it should also provide a way for an application to request features that are specific to a particular network technology, but recognise that doing so compromises portability of the application. -- John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com --------------323EEBCA073FF09A7FC716BB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 23/07/2018 21:15, Tommy Pauly wrote:
Hello TAPS,

Migrating a thread from GitHub to the email list, since it needs broad WG input. I've pasted the discussion so far below.

Essentially, the question is if we have a set of standard properties for Transport Services APIs, should they have a formal registry or not?
Maybe call it an ontology, as in metadata libraries, rather than a registry.

The API is an interface between the application and the network, so it needs to provide an abstraction of the service the network provides that can be understood by each side without having to know too much about how the other side is implemented. There's been some debate about that in the DetNet group recently, too. Anyway, the API should allow the application to specify byte stream or packet, constant bit rate or bursty, latency requirements, tolerance of packet loss or corruption, etc, but not ask it to select a particular protocol such as TCP. Similarly, it should provide more abstract ways for the application to say what it wants to talk to, e.g. specify a URL directly rather than having to make a separate call of gethostbyname().

Of course, it should also provide a way for an application to request features that are specific to a particular network technology, but recognise that doing so compromises portability of the application.
-- 
John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com
--------------323EEBCA073FF09A7FC716BB-- From nobody Tue Jul 24 02:49:27 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 16004130E59 for ; Tue, 24 Jul 2018 02:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 KurQKP2wlIcW for ; Tue, 24 Jul 2018 02:49:23 -0700 (PDT) Received: from know-smtprelay-omc-1.server.virginmedia.net (know-smtprelay-omc-1.server.virginmedia.net [80.0.253.65]) (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 3A2B713108B for ; Tue, 24 Jul 2018 02:49:23 -0700 (PDT) Received: from [192.168.1.35] ([79.64.221.101]) by cmsmtp with ESMTPA id htwXfgql9qTQPhtwXf9uJY; Tue, 24 Jul 2018 10:49:21 +0100 X-Originating-IP: [79.64.221.101] X-Authenticated-User: john.s.grant@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=TO5rtWta c=1 sm=1 tr=0 a=enF7lH1AlO9fobKiMINR1A==:117 a=enF7lH1AlO9fobKiMINR1A==:17 a=IkcTkHD0fZMA:10 a=-O5YPv7yAAAA:8 a=le6d79QuAAAA:8 a=pS0CTLFz-EsFYmwZYegA:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=B8OLwjC1-DXCQoEj:21 a=KY2BomxnFehUB3yr:21 a=QEXdDO2ut3YA:10 a=TLqBRRHTddABEfEY9lce:22 a=QbAMNLWdp4a7deKPGBBn:22 To: taps@ietf.org References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> From: John Grant Message-ID: Date: Tue, 24 Jul 2018 10:49:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-CMAE-Envelope: MS4wfG9HqTcskxbSyqUxB6jv0g/TW79rTQzR6wB/2ZAhk66fwj87zq+tEuK/DAqkHpAe9qYq+662VJcTbSjTS1nD9B5GvV2jAOEOI6f1ulysikYKWGLIpoTC QgGUJnkogTv4JP3+uVTz9NkDxGzRFQcSn+Y8xLp1Ny+JLpzOoQTvCNST Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 24 Jul 2018 09:49:25 -0000 On 24/07/2018 01:21, Tommy Pauly wrote: > Picking this thread up again, I would like to see us incorporate IPv6 address selection into a post-sockets API model. > > Here's a straw man proposal of how we can expose this via the TAPS Interface: > > - A new property for Local Address Preference, which can be a tuple of: > 1. Stable/Public > 2. Temporary/Private > 3. Unique For Connection > - Listeners would default to (1). Connections would default to (2) > - If you specify (3), the system will try to get an entirely new IPv6 address that has never been used before > - You can find out the address you used on your Listener/Connection > > This type of API would allow us to add in the functionality Erik had asked for, to allow a client to be able to request a new address. The other alternative would be to have some out-of-band API to request a new API, but I think marking this on a connection is preferable, since it allows us to enforce this per-path and per-protocol even. > > What do people think? Looks good, especially if it's not actually tied to IPv6, i.e. if you delete "IPv6" in the two places it occurs above. (I realise this is an IETF group and IETF has nailed its colours to the IPv6 mast, but it would be good if TAPS could be more widely applicable than just over the Internet, e.g. between mobile device and MEC.) -- John Grant Chair, ETSI ISG NGP Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 https://www.etsi.org/technologies-clusters/technologies/next-generation-protocols http://www.ninetiles.com From nobody Tue Jul 24 06:52:55 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 1ABA313113B for ; Tue, 24 Jul 2018 06:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 coe8FAHsY0ub for ; Tue, 24 Jul 2018 06:52:43 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id AF37413112E for ; Tue, 24 Jul 2018 06:52:43 -0700 (PDT) Received: from G-MacBook.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8E27D1B00263; Tue, 24 Jul 2018 14:52:33 +0100 (BST) Message-ID: <5B572F21.5080303@erg.abdn.ac.uk> Date: Tue, 24 Jul 2018 14:52:33 +0100 From: G Fairhurst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Grant CC: taps@ietf.org References: <12728b70-7f78-ceed-059f-fc67b7b0a994@ninetiles.com> In-Reply-To: <12728b70-7f78-ceed-059f-fc67b7b0a994@ninetiles.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] To registry, or not to registry? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 24 Jul 2018 13:52:52 -0000 On 24/07/2018, 10:23, John Grant wrote: > On 23/07/2018 21:15, Tommy Pauly wrote: >> Hello TAPS, >> >> Migrating a thread from GitHub to the email list, since it needs >> broad WG input. I've pasted the discussion so far below. >> >> Essentially, the question is if we have a set of standard properties >> for Transport Services APIs, should they have a formal registry or not? > Maybe call it an ontology, as in metadata libraries, rather than a > registry. > > The API is an interface between the application and the network, so it > needs to provide an abstraction of the service the network provides > that can be understood by each side without having to know too much > about how the other side is implemented. There's been some debate > about that in the DetNet group recently, too. Anyway, the API should > allow the application to specify byte stream or packet, constant bit > rate or bursty, latency requirements, tolerance of packet loss or > corruption, etc, but not ask it to select a particular protocol such > as TCP. Similarly, it should provide more abstract ways for the > application to say what it wants to talk to, e.g. specify a URL > directly rather than having to make a separate call of gethostbyname(). > > Of course, it should also provide a way for an application to request > features that are specific to a particular network technology, but > recognise that doing so compromises portability of the application. > -- > John Grant > Nine Tiles, Cambridge, England > +44 1223 862599 and +44 1223 511455 > http://www.ninetiles.com > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps John, I think if you take a look at the TAPS WG drafts, you'll now find that much of what you hope exists in the current work. I think the discussion of byte stream v. packet may be at a lower level that we now envisage in TAPS, but as the TAPS work moves forward I expect you'll find anything that was possible in a byte or packet stream will also be possible via the higher-level API. In most cases, we have also found the new abstraction to be also much simpler for developers to code against. Do let us know if you have further comments on the WG drafts. Gorry From nobody Tue Jul 24 07:07:08 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 6250F130E85 for ; Tue, 24 Jul 2018 07:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mv4KgVQOpPSv for ; Tue, 24 Jul 2018 07:07:03 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B890130DF3 for ; Tue, 24 Jul 2018 07:07:03 -0700 (PDT) Received: from G-MacBook.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0C9871B00263; Tue, 24 Jul 2018 15:06:58 +0100 (BST) Message-ID: <5B573282.2050504@erg.abdn.ac.uk> Date: Tue, 24 Jul 2018 15:06:58 +0100 From: G Fairhurst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: David Schinazi CC: Tommy Pauly , taps WG References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] To registry, or not to registry? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 24 Jul 2018 14:07:06 -0000 I don't yet know for sure myself.... On the one hand: I think a registry is a great way to capture the "bundle" of things that we know about needing to send across the API. Having common keywords (names) is a way to help people (who wish to take this approach) from unwantingly choosing the same function/param with a different name. And avoids accidentally choosing the same key. I like these advantages. especially if I thought people would use the registry. On the other hand, as an author I am still bemused about exactly which list of items I think /need/ could appear in this registry. I know some I'd expect, there are some I would not be surprised to see, and some I'd expect not to see. Also this doesn't stop people dreaming of slight variants of functions/params because they want to be different or don't understand/agree with another definition, especially since the concrete API isn't specified by the IETF. There are ways we could help support different uses, which I think we should consider: * We can define "well-known" IETF keywords that start with a special prefix that require some IETF practice to assign; * we can also define "public" keywords that have no prefix and are first-come-first served, the easy way to get a unique entery. * We can allow private defintions with some different prefix that are not specified by IANA. (We simply preclude this format from the registry). This approach has been used in many places, a simple, but similar transport example is the Service Codes registry: https://www.iana.org/assignments/service-codes/service-codes.xhtml - Let's all think about whether this is a useful approach for our API? Gorry On 23/07/2018, 21:32, David Schinazi wrote: > We had a similar discussion in the Babel WG regarding link types in > our data model - which isn't sent over the wire. > We landed on having an IANA registry of strings so there is one place > to find the mapping from string to specification. > We're planning on reserving all strings starting with an underscore > "_" for experimental use so the registry does not get in anyone's way. > Apparently IANA registries have very low overhead. > Hope this helps. > > David > > >> On Jul 23, 2018, at 13:15, Tommy Pauly > > wrote: >> >> Hello TAPS, >> >> Migrating a thread from GitHub to the email list, since it needs >> broad WG input. I've pasted the discussion so far below. >> >> Essentially, the question is if we have a set of standard properties >> for Transport Services APIs, should they have a formal registry or not? >> >> Thanks, >> Tommy >> >> ====================================== >> >> https://github.com/taps-api/drafts/issues/210 >> >> Philipp: >> >> We will end up with a set Turns out we might need a lot of >> (protocol) specific properties, we should discuss whether we need >> an IANA registry of properties and how this will look like. >> • Include Types ? >> • Include Names ? >> • Some numeric representation ? >> What do we do with ENUM values? >> >> Mirja: >> >> I don't really understand why we would need a registry. Who would >> be using the registry? >> >> Tommy: >> >> I agree that a registry seems unnecessary; this is not a matter >> of protocol or on-the-wire standard. >> >> Philipp: >> >> If we don't want to clutter the basic API document, we will end >> up having at least a half a dozen documents defining specific >> properties for different protocols. >> Does anyone have a good alternative to collect all these except >> in an IANA registry? >> >> Tommy: >> >> We do not need to have documents specify every property. >> Implementation should be allowed to extend as they need. >> >> Brian: >> >> this discussion does suggest that we might want to be more >> explicit up front in the interface document about the scope and >> purpose of the document (i.e. this is meant primarily to define a >> standard API "shape", not the particular strings and codepoints, >> etc.). I'll file an issue. >> >> Colin: >> >> I agree with @tfpauly that we don't need to document every >> property, and with @britram that we're documenting the shape of >> an abstract API, but I also see value in consistent property >> naming across concrete implementations of that API. Some form of >> registry might make sense here. >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Jul 24 11:14:08 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 1D43F130E66 for ; Tue, 24 Jul 2018 11:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 OVkVl6kiuZ8O for ; Tue, 24 Jul 2018 11:14:03 -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 11BF3130E22 for ; Tue, 24 Jul 2018 11:14:03 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id b5-v6so3224782qkg.6 for ; Tue, 24 Jul 2018 11:14:02 -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:content-transfer-encoding; bh=x/bBG+T3eOdQE97wgPCPzCSe/eMEPhz3dazO7tYKngI=; b=F4b9lvlLhqCrFao5ZEI17xeB3QIqQ/8D4NdYlbUN2Jgd+8W22NCkb/v5kMzsXVDd3a 80GEDvDDg0rL6eIfG9cXsjAyfDIfaGZ++YamU3ZpHPAgAUac7g/qIr0lWaZljJSj+SLg vczSSIFTke3HmLHzP13h15QOChmyESMfUCIKO0bg+yVwn+dsZ7/6wNNDi9XOfWssFjpL Ms7cLeQiJ5biCDYPt1XAyhZGhXi+aHB8Lw8gG6wLKzv2mqSj+uqt3r1hzhpQ5/cNRrVR EAZl3/sL1zqbvpiXPTPRPSJzVf3ey7o2GsbOfSaTBsG5Xf+ZkPwvbOBQKFn+PNCYo3N6 Gasw== 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:content-transfer-encoding; bh=x/bBG+T3eOdQE97wgPCPzCSe/eMEPhz3dazO7tYKngI=; b=PHdc6YmIH4sG+izS8O4Lm/bHD4BoicS2ffQ1lF+ts0uEI1ndhocBMl0y53EOEcshFU eQmfqG3oetKLUOh9HdNhpB3rZAD6NpKT2LzbY4UXbq5kHTbhEUZEpRCqRnKn+iSpwb6y 9cFh9vYJ/Pypuai4pI7zAECX8XAXJlkSd7uipK/CNhwwg4E+vFV22BfylxXLs0W+SSlj UHSSWz/yPW/QjJF/WeS2iBiSXuhsi/agyc9AWfi98KFqBrz99/QXDJWOugD83n4qlGOx 3eAzNtSXqsaeT/s3NL5RaM801BOmwM2BBtwUZlf32Xodgcan4mIOQQqc4+OH4pp9pgZ9 +ndg== X-Gm-Message-State: AOUpUlFzSM5Fwjb9roXr/KOYd24o+VOB5TzI8LHIOaAzHCma6iEqKHlC k1VAx5b+VEoBNGf+NJuG15A= X-Google-Smtp-Source: AAOMgpeq21mHGdmMB7zQliUITopHkecV1p0IsFJPh3KbeC2rweedTMUejy4uD+cnYlYkKib0TR0IhA== X-Received: by 2002:a37:380f:: with SMTP id f15-v6mr16868213qka.177.1532456041875; Tue, 24 Jul 2018 11:14:01 -0700 (PDT) Received: from [172.19.32.175] ([2001:4878:a000:3000:d5d7:fe10:83a5:29a9]) by smtp.gmail.com with ESMTPSA id h10-v6sm7156155qtm.48.2018.07.24.11.14.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jul 2018 11:14:01 -0700 (PDT) From: "Aaron Falk" To: "G Fairhurst" Cc: "David Schinazi" , "Tommy Pauly" , "taps WG" Date: Tue, 24 Jul 2018 14:13:59 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <315C7FBD-D322-4506-813C-82BD0F612F28@gmail.com> In-Reply-To: <5B573282.2050504@erg.abdn.ac.uk> References: <5B573282.2050504@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_96CA1503-9246-496B-837A-6F795F433EEF_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] To registry, or not to registry? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 24 Jul 2018 18:14:06 -0000 --=_MailMate_96CA1503-9246-496B-837A-6F795F433EEF_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Caveat: I am not an expert on registries but my sense is that they are most useful for interoperability. I think Gorry's concern about redundancy much less important. And, in fact, it may take a while to figure out how to describe the parameters. It might be more useful to allow for variety in how these are defined to permit creative approaches. YMMV of course. --aaron On 24 Jul 2018, at 10:06, G Fairhurst wrote: > I don't yet know for sure myself.... > > On the one hand: I think a registry is a great way to capture the > "bundle" of things that we know about needing to send across the API. > Having common keywords (names) is a way to help people (who wish to > take this approach) from unwantingly choosing the same function/param > with a different name. And avoids accidentally choosing the same key. > I like these advantages. especially if I thought people would use the > registry. > > On the other hand, as an author I am still bemused about exactly which > list of items I think /need/ could appear in this registry. I know > some I'd expect, there are some I would not be surprised to see, and > some I'd expect not to see. Also this doesn't stop people dreaming of > slight variants of functions/params because they want to be different > or don't understand/agree with another definition, especially since > the concrete API isn't specified by the IETF. > > There are ways we could help support different uses, which I think we > should consider: > * We can define "well-known" IETF keywords that start with a special > prefix that require some IETF practice to assign; > * we can also define "public" keywords that have no prefix and are > first-come-first served, the easy way to get a unique entery. > * We can allow private defintions with some different prefix that are > not specified by IANA. (We simply preclude this format from the > registry). > > This approach has been used in many places, a simple, but similar > transport example is the Service Codes registry: > https://www.iana.org/assignments/service-codes/service-codes.xhtml > > - Let's all think about whether this is a useful approach for our API? > > Gorry > > > On 23/07/2018, 21:32, David Schinazi wrote: >> We had a similar discussion in the Babel WG regarding link types in >> our data model - which isn't sent over the wire. >> We landed on having an IANA registry of strings so there is one place >> to find the mapping from string to specification. >> We're planning on reserving all strings starting with an underscore >> "_" for experimental use so the registry does not get in anyone's >> way. >> Apparently IANA registries have very low overhead. >> Hope this helps. >> >> David >> >> >>> On Jul 23, 2018, at 13:15, Tommy Pauly >> > wrote: >>> >>> Hello TAPS, >>> >>> Migrating a thread from GitHub to the email list, since it needs >>> broad WG input. I've pasted the discussion so far below. >>> >>> Essentially, the question is if we have a set of standard properties >>> for Transport Services APIs, should they have a formal registry or >>> not? >>> >>> Thanks, >>> Tommy >>> >>> ====================================== >>> >>> https://github.com/taps-api/drafts/issues/210 >>> >>> Philipp: >>> >>> We will end up with a set Turns out we might need a lot of >>> (protocol) specific properties, we should discuss whether we >>> need >>> an IANA registry of properties and how this will look like. >>> • Include Types ? >>> • Include Names ? >>> • Some numeric representation ? >>> What do we do with ENUM values? >>> >>> Mirja: >>> >>> I don't really understand why we would need a registry. Who >>> would >>> be using the registry? >>> >>> Tommy: >>> >>> I agree that a registry seems unnecessary; this is not a matter >>> of protocol or on-the-wire standard. >>> >>> Philipp: >>> >>> If we don't want to clutter the basic API document, we will end >>> up having at least a half a dozen documents defining specific >>> properties for different protocols. >>> Does anyone have a good alternative to collect all these except >>> in an IANA registry? >>> >>> Tommy: >>> >>> We do not need to have documents specify every property. >>> Implementation should be allowed to extend as they need. >>> >>> Brian: >>> >>> this discussion does suggest that we might want to be more >>> explicit up front in the interface document about the scope and >>> purpose of the document (i.e. this is meant primarily to define >>> a >>> standard API "shape", not the particular strings and codepoints, >>> etc.). I'll file an issue. >>> >>> Colin: >>> >>> I agree with @tfpauly that we don't need to document every >>> property, and with @britram that we're documenting the shape of >>> an abstract API, but I also see value in consistent property >>> naming across concrete implementations of that API. Some form of >>> registry might make sense here. >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> >> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --=_MailMate_96CA1503-9246-496B-837A-6F795F433EEF_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Caveat: I am not an expert on registries but my sense is t= hat they are most useful for interoperability. I think Gorry's concern a= bout redundancy much less important. And, in fact, it may take a while t= o figure out how to describe the parameters. It might be more useful to = allow for variety in how these are defined to permit creative approaches.= YMMV of course.

--aaron

On 24 Jul 2018, at 10:06, G Fairhurst wrote:

I don't yet know for sure myself...= =2E

On the one hand: I think a registry is a great way to capture the "bundle= " of things that we know about needing to send across the API. Having com= mon keywords (names) is a way to help people (who wish to take this appro= ach) from unwantingly choosing the same function/param with a different n= ame. And avoids accidentally choosing the same key. I like these advantag= es. especially if I thought people would use the registry.

On the other hand, as an author I am still bemused about exactly which li= st of items I think /need/ could appear in this registry. I know some I'd= expect, there are some I would not be surprised to see, and some I'd exp= ect not to see. Also this doesn't stop people dreaming of slight variants= of functions/params because they want to be different or don't understan= d/agree with another definition, especially since the concrete API isn't = specified by the IETF.

There are ways we could help support different uses, which I think we sho= uld consider:
* We can define "well-known" IETF keywords that start with a special pref= ix that require some IETF practice to assign;
* we can also define "public" keywords that have no prefix and are first-= come-first served, the easy way to get a unique entery.
* We can allow private defintions with some different prefix that are not= specified by IANA. (We simply preclude this format from the registry).
This approach has been used in many places, a simple, but similar transpo= rt example is the Service Codes registry:
https://www.iana.org/assignments/service-codes= /service-codes.xhtml

- Let's all think about whether this is a useful approach for our API?
Gorry


On 23/07/2018, 21:32, David Schinazi wrote:

We had a si= milar discussion in the Babel WG regarding link types in our data model -= which isn't sent over the wire.
We landed on having an IANA registry of strings so there is one place to = find the mapping from string to specification.
We're planning on reserving all strings starting with an underscore "_" f= or experimental use so the registry does not get in anyone's way.
Apparently IANA registries have very low overhead.
Hope this helps.

David

On Jul 23, = 2018, at 13:15, Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>> = wrote:

Hello TAPS,

Migrating a thread from GitHub to the email list, since it needs broad WG= input. I've pasted the discussion so far below.

Essentially, the question is if we have a set of standard properties for = Transport Services APIs, should they have a formal registry or not?

Thanks,
Tommy

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

https://github.com/taps-api/drafts/issues/210

Philipp:

We will end up with a set Turns out we might need a lot of
(protocol) specific properties, we should discuss whether we need
= an IANA registry of properties and how this will look like.
=E2=80=A2 Include Types ?
=E2=80=A2 Include Names ?
=E2=80=A2 Some numeric representation ?
What do we do with ENUM values?

Mirja:

I don't really understand why we would need a registry. Who would
= be using the registry?

Tommy:

I agree that a registry seems unnecessary; this is not a matter
of protocol or on-the-wire standard.

Philipp:

If we don't want to clutter the basic API document, we will end
up having at least a half a dozen documents defining specific
properties for different protocols.
Does anyone have a good alternative to collect all these except
in an IANA registry?

Tommy:

We do not need to have documents specify every property.
Implementation should be allowed to extend as they need.

Brian:

this discussion does suggest that we might want to be more
explicit up front in the interface document about the scope and
purpose of the document (i.e. this is meant primarily to define a
= standard API "shape", not the particular strings and codepoints,
etc.). I'll file an issue.

Colin:

I agree with @tfpauly that we don't need to document every
property, and with @britram that we're documenting the shape of
an abstract API, but I also see value in consistent property
naming across concrete implementations of that API. Some form of
registry might make sense here.

_______________________________________________
Taps mailing list
Taps@ietf.org <m= ailto:Taps@ietf.org>
https://www.ietf.org/mailman/listinfo/taps

____________________________________________= ___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

____________________________________________= ___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--=_MailMate_96CA1503-9246-496B-837A-6F795F433EEF_=-- From nobody Tue Jul 24 19:58: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 B1ACF130EF0 for ; Tue, 24 Jul 2018 19:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5nWzp2L5Ujr for ; Tue, 24 Jul 2018 19:58:40 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B08130DE5 for ; Tue, 24 Jul 2018 19:58:40 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id v71-v6so6667299itb.3 for ; Tue, 24 Jul 2018 19:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=U13hAkoS1OiIWA7U543ZdTxDcOyJWpy3TFFS4Zqtn/A=; b=AVmkbtyI9WFCD+2scK6UGPNPgnDj8u1XIukJVtfGNk/FRmLZI7BSJbd12MWBaaH7pR ZXMMQ7e7ynkki8ExzsX8bEC9pr6NKQrKVl8+2u9mv0XX+DIS5QawgkM2gwPJMuwPi+YH EtQ7unasDqcy5dFDXiaq+H9AyrzdxN1KvHSFZK6pPEEdEXXHswvhj8M3umwAIqAU4gU5 WcyOp//PCiyjlKuKXheoWbg6a/KQB6s4LJBNdOBQIDrH3XpQYJ0H8CPCAgdfxQFsWRWp EsKGoDMh5/So4k75yJh6119TDKmcvKoJLaz+QmL/9fq/6ZmWHHd/LXCrfNInv9D1jN34 yaKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=U13hAkoS1OiIWA7U543ZdTxDcOyJWpy3TFFS4Zqtn/A=; b=GBJVhhFRsjYJ/CpdjUOrgyE7TmEmDZ7h/e6rU5o4G9wlRoNVb6NuHdXOFWDZV16H99 cCtS+6hrO/0rQ6U1N9XeeSL4iGHTyufaS6kGS4F66u70QyBVM7w/ZWUyY6ZZdnS1VZHN YS6RYFiHeVsT7dWM/cYY2IiXgU/X6SNAh8FbD6zNlWjWtwSDa2f3Nw4Jh8vSLn5xCm73 6wlyrQ4UWxSNFH/J0EqVqTNY78wtzdlQ22j0LMW6lY33bRTIzQZg0tKFUbFExIkDnjl+ aQ2GVkrGiKFTzT6Qu8R+1geSuNFnhJrfVGW6hNB6yt8ETAy4Fwgz0QDth3Pf1NpdaYSs kpyg== X-Gm-Message-State: AOUpUlECrq2GvKCbaIR3Y0bmahmpNeZhhxnB6ErEC40a39+O/DXU18ge ghSuwTNrUbfyYuE+Z0SPa6c+Nf1tMLEhcFjt0qM= X-Google-Smtp-Source: AAOMgpfvc1UVfoJSLsNfa+zoviW5+OZoSIIhoR5Pk3pKJIgsk4KNeEf5rEUZJ/2StnBHf7M+wWrUKOzLtqkTSu3acmY= X-Received: by 2002:a24:643:: with SMTP id 64-v6mr5061282itv.109.1532487519417; Tue, 24 Jul 2018 19:58:39 -0700 (PDT) MIME-Version: 1.0 References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> In-Reply-To: From: Christopher Wood Date: Tue, 24 Jul 2018 19:58:27 -0700 Message-ID: To: Tommy Pauly Cc: Fernando Gont , taps WG , gorry@erg.abdn.ac.uk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 02:58:42 -0000 On Mon, Jul 23, 2018 at 5:21 PM Tommy Pauly wrote: > > Picking this thread up again, I would like to see us incorporate IPv6 add= ress selection into a post-sockets API model. > > Here's a straw man proposal of how we can expose this via the TAPS Interf= ace: > > - A new property for Local Address Preference, which can be a tuple of: > 1. Stable/Public > 2. Temporary/Private > 3. Unique For Connection > - Listeners would default to (1). Connections would default to (2) > - If you specify (3), the system will try to get an entirely new IPv6 add= ress that has never been used before > - You can find out the address you used on your Listener/Connection > > This type of API would allow us to add in the functionality Erik had aske= d for, to allow a client to be able to request a new address. The other alt= ernative would be to have some out-of-band API to request a new API, but I = think marking this on a connection is preferable, since it allows us to enf= orce this per-path and per-protocol even. > > What do people think? Perhaps unsurprisingly, I am fond of this API. Would it be feasible for connections to default to (3) and fall back to (2) if unsuccessful? Best, Chris From nobody Wed Jul 25 03:02:13 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 6647B130E1E for ; Wed, 25 Jul 2018 03:02:10 -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] 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 9zbR8bC359Se for ; Wed, 25 Jul 2018 03:02:07 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id EE05E12DD85 for ; Wed, 25 Jul 2018 03:02:05 -0700 (PDT) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6C9171B007B3; Wed, 25 Jul 2018 11:01:57 +0100 (BST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id C318921AE8; Wed, 25 Jul 2018 06:01:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 25 Jul 2018 06:01:53 -0400 X-ME-Proxy: X-ME-Sender: Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [137.50.17.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 44621E465F; Wed, 25 Jul 2018 06:01:52 -0400 (EDT) Date: Wed, 25 Jul 2018 11:01:59 +0100 From: Tom Jones To: Christopher Wood Cc: Tommy Pauly , gorry@erg.abdn.ac.uk, Fernando Gont , taps WG Message-ID: <20180725100158.GA68757@tom-desk.erg.abdn.ac.uk> References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 10:02:11 -0000 On Tue, Jul 24, 2018 at 07:58:27PM -0700, Christopher Wood wrote: > On Mon, Jul 23, 2018 at 5:21 PM Tommy Pauly wrote: > > > > Picking this thread up again, I would like to see us incorporate IPv6 address selection into a post-sockets API model. > > > > Here's a straw man proposal of how we can expose this via the TAPS Interface: > > > > - A new property for Local Address Preference, which can be a tuple of: > > 1. Stable/Public > > 2. Temporary/Private > > 3. Unique For Connection > > - Listeners would default to (1). Connections would default to (2) > > - If you specify (3), the system will try to get an entirely new IPv6 address that has never been used before > > - You can find out the address you used on your Listener/Connection > > > > This type of API would allow us to add in the functionality Erik had asked for, to allow a client to be able to request a new address. The other alternative would be to have some out-of-band API to request a new API, but I think marking this on a connection is preferable, since it allows us to enforce this per-path and per-protocol even. > > > > What do people think? > > Perhaps unsurprisingly, I am fond of this API. Would it be feasible > for connections to default to (3) and fall back to (2) if > unsuccessful? > I would like to echo my fondness of the API and the preference for (3) falling back to (2) if it is feasible. - Tom From nobody Wed Jul 25 07:48:22 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 3F436130E0C for ; Wed, 25 Jul 2018 07:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1QtNkf8Jy_s for ; Wed, 25 Jul 2018 07:48:19 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E0B130DF7 for ; Wed, 25 Jul 2018 07:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2912; q=dns/txt; s=iport; t=1532530099; x=1533739699; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aNP8m91m9vt9uqybi42TirlZkj7wgalJ/XPkS4031ZA=; b=L5SVvsLfkadd7YcXkmUe1ktp4uqWzl/tybCOSTi4ewrOxqvsjXz3WKLv OmRzKPwyz29QuprDwDJuVhutgBYfs16nm5t93e4eenh0U8YSCX4qXqoNo /JRk1WnW4B63XMHwb83YZk/cH9eCcateoc3KvqYkbpSwPPLn/G+mCpU6J A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEBwBnjFhb/4kNJK1bDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDTWN/KAqDdJRBgWgkgzuUCAsYC4RJAheCTSE3FQECAQE?= =?us-ascii?q?CAQECbRwMhTcBAQQBASEROgsQAgEIEAgCAiYCAgIlCxUQAgQBDQWDIAGBfw+?= =?us-ascii?q?vaoEuilIFgQuHdxeBQT+BEScME4JMgxsBAYEfWIJqMYIkApl1CQKPM41/kgY?= =?us-ascii?q?CERSBJDMigVJwFTsqAYI+ixWFBDpvjCgqgQSBGwEB?= X-IronPort-AV: E=Sophos;i="5.51,401,1526342400"; d="scan'208";a="148134390" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2018 14:48:18 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id w6PEmHwc021397 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Jul 2018 14:48:18 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 25 Jul 2018 10:48:17 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Wed, 25 Jul 2018 10:48:17 -0400 From: "Eric Vyncke (evyncke)" To: Tom Jones , Christopher Wood CC: "gorry@erg.abdn.ac.uk" , Fernando Gont , Tommy Pauly , taps WG Thread-Topic: [Taps] IPv6 address usage Thread-Index: AQHT81hbvPVicm0ocEuz5z3PwxfhhKSfoCPSgAC5R4CAAAzwgA== Date: Wed, 25 Jul 2018 14:48:17 +0000 Message-ID: <775025E3-1C5D-4871-93C3-B39B92383C64@cisco.com> References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> <20180725100158.GA68757@tom-desk.erg.abdn.ac.uk> In-Reply-To: <20180725100158.GA68757@tom-desk.erg.abdn.ac.uk> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.6] Content-Type: text/plain; charset="utf-8" Content-ID: <4416B4DD6AC5C2419978FFD35CD2515B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 14:48:21 -0000 QmVpbmcgYSBsYXllci0zIHBlcnNvbiwgSSBhbSBhIChqdXN0KSBsaXR0bGUgY29uY2VybmVkIGJ5 IGhhdmluZyBvbmUgSVB2NiBhZGRyZXNzIHBlciBjb25uZWN0aW9uIGFzIGl0IGNvdWxkIHB1dCBz b21lIHN0cmVzcyBvbiBOZWlnaGJvciBEaXNjb3ZlcnkgKG1jYXN0IHRyYWZmaWMgZHJhaW5pbmcg YmF0dGVyeSwgY2FjaGUgc3BhY2UvbWFpbnRlbmFuY2UpIGlmIHVzZWQgYnkgZGVmYXVsdCBvbiB2 ZXJ5IHNob3J0IGxpdmUgY29ubmVjdGlvbnMNCg0KSnVzdCBhIHRob3VnaHQNCg0KLcOpcmljDQoN Cu+7v09uIDI1LzA3LzIwMTgsIDEyOjAyLCAiVGFwcyBvbiBiZWhhbGYgb2YgVG9tIEpvbmVzIiA8 dGFwcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0b21AZXJnLmFiZG4uYWMudWs+IHdy b3RlOg0KDQogICAgT24gVHVlLCBKdWwgMjQsIDIwMTggYXQgMDc6NTg6MjdQTSAtMDcwMCwgQ2hy aXN0b3BoZXIgV29vZCB3cm90ZToNCiAgICA+IE9uIE1vbiwgSnVsIDIzLCAyMDE4IGF0IDU6MjEg UE0gVG9tbXkgUGF1bHkgPHRwYXVseUBhcHBsZS5jb20+IHdyb3RlOg0KICAgID4gPg0KICAgID4g PiBQaWNraW5nIHRoaXMgdGhyZWFkIHVwIGFnYWluLCBJIHdvdWxkIGxpa2UgdG8gc2VlIHVzIGlu Y29ycG9yYXRlIElQdjYgYWRkcmVzcyBzZWxlY3Rpb24gaW50byBhIHBvc3Qtc29ja2V0cyBBUEkg bW9kZWwuDQogICAgPiA+DQogICAgPiA+IEhlcmUncyBhIHN0cmF3IG1hbiBwcm9wb3NhbCBvZiBo b3cgd2UgY2FuIGV4cG9zZSB0aGlzIHZpYSB0aGUgVEFQUyBJbnRlcmZhY2U6DQogICAgPiA+DQog ICAgPiA+IC0gQSBuZXcgcHJvcGVydHkgZm9yIExvY2FsIEFkZHJlc3MgUHJlZmVyZW5jZSwgd2hp Y2ggY2FuIGJlIGEgdHVwbGUgb2Y6DQogICAgPiA+ICAgICAxLiBTdGFibGUvUHVibGljDQogICAg PiA+ICAgICAyLiBUZW1wb3JhcnkvUHJpdmF0ZQ0KICAgID4gPiAgICAgMy4gVW5pcXVlIEZvciBD b25uZWN0aW9uDQogICAgPiA+IC0gTGlzdGVuZXJzIHdvdWxkIGRlZmF1bHQgdG8gKDEpLiBDb25u ZWN0aW9ucyB3b3VsZCBkZWZhdWx0IHRvICgyKQ0KICAgID4gPiAtIElmIHlvdSBzcGVjaWZ5ICgz KSwgdGhlIHN5c3RlbSB3aWxsIHRyeSB0byBnZXQgYW4gZW50aXJlbHkgbmV3IElQdjYgYWRkcmVz cyB0aGF0IGhhcyBuZXZlciBiZWVuIHVzZWQgYmVmb3JlDQogICAgPiA+IC0gWW91IGNhbiBmaW5k IG91dCB0aGUgYWRkcmVzcyB5b3UgdXNlZCBvbiB5b3VyIExpc3RlbmVyL0Nvbm5lY3Rpb24NCiAg ICA+ID4NCiAgICA+ID4gVGhpcyB0eXBlIG9mIEFQSSB3b3VsZCBhbGxvdyB1cyB0byBhZGQgaW4g dGhlIGZ1bmN0aW9uYWxpdHkgRXJpayBoYWQgYXNrZWQgZm9yLCB0byBhbGxvdyBhIGNsaWVudCB0 byBiZSBhYmxlIHRvIHJlcXVlc3QgYSBuZXcgYWRkcmVzcy4gVGhlIG90aGVyIGFsdGVybmF0aXZl IHdvdWxkIGJlIHRvIGhhdmUgc29tZSBvdXQtb2YtYmFuZCBBUEkgdG8gcmVxdWVzdCBhIG5ldyBB UEksIGJ1dCBJIHRoaW5rIG1hcmtpbmcgdGhpcyBvbiBhIGNvbm5lY3Rpb24gaXMgcHJlZmVyYWJs ZSwgc2luY2UgaXQgYWxsb3dzIHVzIHRvIGVuZm9yY2UgdGhpcyBwZXItcGF0aCBhbmQgcGVyLXBy b3RvY29sIGV2ZW4uDQogICAgPiA+DQogICAgPiA+IFdoYXQgZG8gcGVvcGxlIHRoaW5rPw0KICAg ID4gDQogICAgPiBQZXJoYXBzIHVuc3VycHJpc2luZ2x5LCBJIGFtIGZvbmQgb2YgdGhpcyBBUEku IFdvdWxkIGl0IGJlIGZlYXNpYmxlDQogICAgPiBmb3IgY29ubmVjdGlvbnMgdG8gZGVmYXVsdCB0 byAoMykgYW5kIGZhbGwgYmFjayB0byAoMikgaWYNCiAgICA+IHVuc3VjY2Vzc2Z1bD8NCiAgICA+ IA0KICAgIA0KICAgIEkgd291bGQgbGlrZSB0byBlY2hvIG15IGZvbmRuZXNzIG9mIHRoZSBBUEkg YW5kIHRoZSBwcmVmZXJlbmNlIGZvciAoMykNCiAgICBmYWxsaW5nIGJhY2sgdG8gKDIpIGlmIGl0 IGlzIGZlYXNpYmxlLg0KICAgIA0KICAgIC0gVG9tDQogICAgDQogICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBUYXBzIG1haWxpbmcgbGlzdA0K ICAgIFRhcHNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RhcHMNCiAgICANCg0K From nobody Wed Jul 25 08:05: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 1A574130EA7 for ; Wed, 25 Jul 2018 08:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMkeK2NHc06w for ; Wed, 25 Jul 2018 08:05:07 -0700 (PDT) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (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 DD975130E6A for ; Wed, 25 Jul 2018 08:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1532531106; x=2396444706; 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=QneCOgHUZrt1kbyFO075QXYUUc7rxOH3oQPKmayAEvI=; b=J7P+Cf6KnkcbhgWcwojwT97w8/pp1+D7AbI3DJ7qX9RjONPjRrBqPtz5zY4cXz2l hT0xLUTEdBaapECHupLRMSuuv9+OGVa+wQH0vjkNcv5qw+N5GRKeEYbp5o88Ag5/ ZTpAC2tM/pNLAjA+KP5WGAC8HR+gi1dihsaWITkF0CsbxfVQ3z40rgynI3RSSWzl wIcu8nbQc42hlYLiVUdodHqAWz9jkSQ6smqVGkXoMBY1s/OYZTJ9fxZG38/7k6Yv 37DIcXmsezmEhvuCo+ynhgt5pUvn/QAE0Ls6vtmR0iFX2dghVE3H51+H7d+IVeT+ PW/P9CmvmRtAHOKwfU93EQ==; X-AuditID: 11ab0217-d27ff70000003e90-ca-5b5891a16bc8 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-in23.apple.com (Apple Secure Mail Relay) with SMTP id 76.32.16016.1A1985B5; Wed, 25 Jul 2018 08:05:06 -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 mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PCF00EH2GKH8G60@mr2-mtap-s01.rno.apple.com>; Wed, 25 Jul 2018 08:05: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 <0PCF00900GFS8600@nwk-mmpp-sz09.apple.com>; Wed, 25 Jul 2018 08:05:05 -0700 (PDT) X-Va-A: X-Va-T-CD: d19ce16414be8d213766d4f317f78d66 X-Va-E-CD: fb0e756882befa175fc67125f6d8858b X-Va-R-CD: a98e0002a67f261a76e506e43f661cea X-Va-CD: 0 X-Va-ID: f63e33a7-ff3d-4902-a314-42b3f6e901c3 X-V-A: X-V-T-CD: d19ce16414be8d213766d4f317f78d66 X-V-E-CD: fb0e756882befa175fc67125f6d8858b X-V-R-CD: a98e0002a67f261a76e506e43f661cea X-V-CD: 0 X-V-ID: 84c982a9-899e-4a0a-bb9a-87985e007106 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 <0PCF00900GFD0Y00@nwk-mmpp-sz09.apple.com>; Wed, 25 Jul 2018 08:05:04 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-25_03:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp15.corp.apple.com-10000_instance1 Received: from [17.234.74.15] (unknown [17.234.74.15]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PCF00MYYGKF1G50@nwk-mmpp-sz09.apple.com>; Wed, 25 Jul 2018 08:05:03 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <775025E3-1C5D-4871-93C3-B39B92383C64@cisco.com> Date: Wed, 25 Jul 2018 08:05:02 -0700 Cc: Tom Jones , Christopher Wood , "gorry@erg.abdn.ac.uk" , Fernando Gont , taps WG Content-transfer-encoding: quoted-printable Message-id: <50004FDB-5F25-43AE-8B7B-9CF479D56EA5@apple.com> References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> <20180725100158.GA68757@tom-desk.erg.abdn.ac.uk> <775025E3-1C5D-4871-93C3-B39B92383C64@cisco.com> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.3445.100.13.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUiuPlRq+6iiRHRBm2dTBbTv19js5h2bQW7 xZNVb9gsXrfNZrS4E2Px/X2EA5vHiWVXWD16Pr9g8tg56y67x5IlP5k8PhzqYQ9gjeKySUnN ySxLLdK3S+DK+HU6raBLtOL1skvMDYzPBLoYOTkkBEwkzk7sZOpi5OIQEjjIJHHjVj8LSIJX QFDix+R7QDYHB7OAusSUKbkQNeuYJFquP2YGqRES6GKS6O/1hxjELvHn1w4WCFtb4u+Ze8ww 9u0Zbxlh7M9TfjBB2FwSC7aeZoWwdSVOXjwCFWeTWH9iCZStJbFq7w1GGLvh0jI2GHvC8TNQ uzglzn+ZyA5yp4SAjsSzm54Qd3YC3Tn/MtT8bInL/79D1QdL/DnUwwxR1M8kMXPOJEaQZmEB CYnNexJBaoQF1CR2vr4NtotNQEXi+LcNYL9wCthKTFsD8ReLgKrEkqXXweYwCxxnlPj85yfY MmagJ5+8u8AKCUQbiQ8fnrFALLvNJHFiQQ9Yt4iAg8TNDfPYJzAqzkIK7FmIwJ6FZNQCRuZV jMK5iZk5upl5RsZ6iQUFOal6yfm5mxhBKWU1k/gOxs+vDQ8xCnAwKvHwfrALjxZiTSwrrsw9 xCjNwaIkzvthl1i0kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsblT0Ks9QVz/y56oG7Cu5U/ xiF1vxZ/Aus2wV8/eTI7ykzbS6/I2HBPsJB9pFft1s8q2sckECchYt6j2nbseMl/1cVRr/3s pz3vcfU0rJnpwdXVtLx8rorCrnQrtcDp+sLl65c3F5ksl609bOF/2KhFvHa/RPOslGmqe7Xn pe7zOmN/cO0LJZbijERDLeai4kQAVSbuxgoDAAA= Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:05:23 -0000 Hi Eric, Yes, I'm inclined to agree=E2=80=94I think that having a unique address = per connection shouldn't be the default; an application could certainly = always set it if it wants to decrease linkability? Perhaps a default = could be something more per-user or per-application. Best, Tommy > On Jul 25, 2018, at 7:48 AM, Eric Vyncke (evyncke) = wrote: >=20 > Being a layer-3 person, I am a (just) little concerned by having one = IPv6 address per connection as it could put some stress on Neighbor = Discovery (mcast traffic draining battery, cache space/maintenance) if = used by default on very short live connections >=20 > Just a thought >=20 > -=C3=A9ric >=20 > =EF=BB=BFOn 25/07/2018, 12:02, "Taps on behalf of Tom Jones" = wrote: >=20 > On Tue, Jul 24, 2018 at 07:58:27PM -0700, Christopher Wood wrote: >> On Mon, Jul 23, 2018 at 5:21 PM Tommy Pauly wrote: >>>=20 >>> Picking this thread up again, I would like to see us incorporate = IPv6 address selection into a post-sockets API model. >>>=20 >>> Here's a straw man proposal of how we can expose this via the TAPS = Interface: >>>=20 >>> - A new property for Local Address Preference, which can be a tuple = of: >>> 1. Stable/Public >>> 2. Temporary/Private >>> 3. Unique For Connection >>> - Listeners would default to (1). Connections would default to (2) >>> - If you specify (3), the system will try to get an entirely new = IPv6 address that has never been used before >>> - You can find out the address you used on your Listener/Connection >>>=20 >>> This type of API would allow us to add in the functionality Erik had = asked for, to allow a client to be able to request a new address. The = other alternative would be to have some out-of-band API to request a new = API, but I think marking this on a connection is preferable, since it = allows us to enforce this per-path and per-protocol even. >>>=20 >>> What do people think? >>=20 >> Perhaps unsurprisingly, I am fond of this API. Would it be feasible >> for connections to default to (3) and fall back to (2) if >> unsuccessful? >>=20 >=20 > I would like to echo my fondness of the API and the preference for = (3) > falling back to (2) if it is feasible. >=20 > - Tom >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Jul 25 08:34:48 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 957AE12F1AC for ; Wed, 25 Jul 2018 08:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpk6lQEnV8Ju for ; Wed, 25 Jul 2018 08:34:44 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD8612D7F8 for ; Wed, 25 Jul 2018 08:34:43 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id w11-v6so6698005iob.2 for ; Wed, 25 Jul 2018 08:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wLgg8EQJBAxH0uYDbWtaJXE0A4xiNGyfz55JJFSc9vU=; b=td5sHtI+hdLHKgWFjLPbJRYoPPFCDIPkTco+NwIpyfYjQbVmP9n93NIZx6YrEDmT1i a6h9af8DNqmOgEM6aCHIIqI8DmEhN6HNjnSglZpxVsWgOlgXfzcn+vksbI4F2Izyzxpw yVoZ94gQU1Y4/bsOduv39TY2rCEpdiNoNz4idLS0TqWG4N4dDHyhWH/vpnFBQvfjUeDI TElH7fgO+B9He3gXA+s+M6AHJpd1jaRZ7F1S1Q7ZEYs0qF6odm15aRH1SEzyWVNESxcS Ozjzcmm9XBe1WmRNx0EqeN1qguHhSMLo7hAdkuG6pAn7DY26UD/p1ROlm3MvqdNHJhWU 4ydQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wLgg8EQJBAxH0uYDbWtaJXE0A4xiNGyfz55JJFSc9vU=; b=fFH+Ra7mF9H0HYSmAdyCz4QGcszQGp9uvJmFs329UfHIUd3pMp3wWpgG5LyklWMmAW 9aHEVRie/SS/kZKeZ43PnYNRlY0wym/QO7YW52QhbxkWjHZRxfwXjLz6qDuHVIz28tit mjKzZ3HNdXr9u/NCUuvhK2n3UdcThVBj1rLb0cEETlLcMgFdt4BIIV+a7aRvzW/grSnA bODvf21PT3Z6oF1f9kBlo52V4Z4kAbI6fxER0TnKbIKvpogE33xJ+9pmnWcn1adyZUb9 sHTootlaKh8ar2hjJuv9KhUuKy+rQbDIyEdGL4dSdoYOn5FwLaUuc+Q/CSwAkWEmGfhf ZXlw== X-Gm-Message-State: AOUpUlHudmnA8nhvl9ez8ZpBJgdlMK8xPNNyxYb4FOMe5A6IC2/CybtM oscrDlb/FA6WZd3FrUBCT16oDT2NFG2noyxHtoIotULAVFE= X-Google-Smtp-Source: AAOMgpfFEioqt1z9YuUsiOI2nzk/UKgk0IHVYILMhDKxUiuytT4r0E4DbWihluAM245YFh3VI0Q+2dWUvIeI2bXv1js= X-Received: by 2002:a6b:1f8e:: with SMTP id f136-v6mr17538145iof.289.1532532883009; Wed, 25 Jul 2018 08:34:43 -0700 (PDT) MIME-Version: 1.0 References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> <20180725100158.GA68757@tom-desk.erg.abdn.ac.uk> <775025E3-1C5D-4871-93C3-B39B92383C64@cisco.com> <50004FDB-5F25-43AE-8B7B-9CF479D56EA5@apple.com> In-Reply-To: <50004FDB-5F25-43AE-8B7B-9CF479D56EA5@apple.com> From: Christopher Wood Date: Wed, 25 Jul 2018 08:34:31 -0700 Message-ID: To: Tommy Pauly Cc: evyncke=40cisco.com@dmarc.ietf.org, Tom Jones , gorry@erg.abdn.ac.uk, Fernando Gont , taps WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:34:46 -0000 On Wed, Jul 25, 2018 at 8:05 AM Tommy Pauly wrote: > > Yes, I'm inclined to agree=E2=80=94I think that having a unique address p= er connection shouldn't be the default; an application could certainly alwa= ys set it if it wants to decrease linkability? Applications should not have to opt-in to better privacy. Decreased linkability should be the default. So if doing this per-connection is shown (not just believed) to be infeasible, then per-application is a reasonable compromise. Best, Chris > Perhaps a default could be something more per-user or per-application. > > Best, > Tommy > > > On Jul 25, 2018, at 7:48 AM, Eric Vyncke (evyncke) wrote: > > > > Being a layer-3 person, I am a (just) little concerned by having one IP= v6 address per connection as it could put some stress on Neighbor Discovery= (mcast traffic draining battery, cache space/maintenance) if used by defau= lt on very short live connections > > > > Just a thought > > > > -=C3=A9ric > > > > =EF=BB=BFOn 25/07/2018, 12:02, "Taps on behalf of Tom Jones" wrote: > > > > On Tue, Jul 24, 2018 at 07:58:27PM -0700, Christopher Wood wrote: > >> On Mon, Jul 23, 2018 at 5:21 PM Tommy Pauly wrote: > >>> > >>> Picking this thread up again, I would like to see us incorporate IPv6= address selection into a post-sockets API model. > >>> > >>> Here's a straw man proposal of how we can expose this via the TAPS In= terface: > >>> > >>> - A new property for Local Address Preference, which can be a tuple o= f: > >>> 1. Stable/Public > >>> 2. Temporary/Private > >>> 3. Unique For Connection > >>> - Listeners would default to (1). Connections would default to (2) > >>> - If you specify (3), the system will try to get an entirely new IPv6= address that has never been used before > >>> - You can find out the address you used on your Listener/Connection > >>> > >>> This type of API would allow us to add in the functionality Erik had = asked for, to allow a client to be able to request a new address. The other= alternative would be to have some out-of-band API to request a new API, bu= t I think marking this on a connection is preferable, since it allows us to= enforce this per-path and per-protocol even. > >>> > >>> What do people think? > >> > >> Perhaps unsurprisingly, I am fond of this API. Would it be feasible > >> for connections to default to (3) and fall back to (2) if > >> unsuccessful? > >> > > > > I would like to echo my fondness of the API and the preference for (= 3) > > falling back to (2) if it is feasible. > > > > - Tom > > > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > > > > > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > From nobody Wed Jul 25 08:48:30 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 7D93912DD85 for ; Wed, 25 Jul 2018 08:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TheYHkF1Ff6l for ; Wed, 25 Jul 2018 08:48:26 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8B012D7F8 for ; Wed, 25 Jul 2018 08:48:26 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id d189-v6so14722626oib.6 for ; Wed, 25 Jul 2018 08:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Avb6yYYYkVtJX2P2qORczo8QGTdEuYHGQbjcYhqEzdM=; b=aPNfKZflohjpPAEr4uvHwW9qapOvMqVXZR66XVMRdc9Et7vD943W6LqLPrBszMkdKf W2Ytk36sXJECRdMFpX68eJeSxVNr+ryYiM/xNz/2zJhpZ0uE3UTLCb/hVdOgUO56Wcln GcZHzdsQi4IrBljgTYoxzhVUS5T1Niax2B7RE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Avb6yYYYkVtJX2P2qORczo8QGTdEuYHGQbjcYhqEzdM=; b=NTg2d4Yp98Tb6DPsemUeckpgbk0NmpZA2p/DGGdOFBqlQ40MegGl3R1hm3zGNMZK9O w8tJ8VmEzRT8NTkRpnFb5PmtTN/C38bZwihpoAF0Khdk24HEwC8wTtMZiZJ31ugSvsCm zaHeUtOlIkKA3W0ud5Zb1uEsBNxAF9okTLRLDrv33xMyqmv23MwWyUN2JIYNAUTXjojI twwNPQ/ka5iRs0vn7QtqMMRbl7e6wokIDjQZeUuQXK/YGqIVAUt31Msh8CF5tbdWn1zi juHBiYlCanaHrZX4+tTKgAFWr6Wqb2BJE0pY8UeXyiN2LrdDxy1oF0eAshvqurpU7u/F siEw== X-Gm-Message-State: AOUpUlEko4ebwzWx3xDnGp22Ep8TTdacK1Obml8++Q/yVf7V+T9m5yeC h2PaW/0+ZUKmiPwL0kDIbJUAdoEOkaDnEPCc6u53WZnnDno= X-Google-Smtp-Source: AAOMgpeSeIt6fjr+KaUpoItLKI4bsHMKhVWzOU4jUXzLTSTbsNT5J/X4tjA+x+ijvAr4kUZZPlcoC+dT7QD9P9PTWZ4= X-Received: by 2002:aca:d0d7:: with SMTP id j84-v6mr3614799oiy.189.1532533705390; Wed, 25 Jul 2018 08:48:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:204a:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 08:48:24 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> <20180725100158.GA68757@tom-desk.erg.abdn.ac.uk> <775025E3-1C5D-4871-93C3-B39B92383C64@cisco.com> <50004FDB-5F25-43AE-8B7B-9CF479D56EA5@apple.com> From: Kyle Rose Date: Wed, 25 Jul 2018 15:48:24 +0000 Message-ID: To: Christopher Wood Cc: Tommy Pauly , "Gorry (erg)" , evyncke=40cisco.com@dmarc.ietf.org, taps WG , Tom Jones , Fernando Gont Content-Type: multipart/alternative; boundary="0000000000001dcd490571d4cf24" Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:48:29 -0000 --0000000000001dcd490571d4cf24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2018 at 3:34 PM, Christopher Wood < christopherwood07@gmail.com> wrote: > On Wed, Jul 25, 2018 at 8:05 AM Tommy Pauly wrote: > > > > Yes, I'm inclined to agree=E2=80=94I think that having a unique address= per > connection shouldn't be the default; an application could certainly alway= s > set it if it wants to decrease linkability? > > Applications should not have to opt-in to better privacy. Decreased > linkability should be the default. So if doing this per-connection is > shown (not just believed) to be infeasible, then per-application is a > reasonable compromise. > The problem is that it might not be a dichotomy between "feasible" and "infeasible". What if the tradeoff is increased connection latency from acquiring a new address (either by DHCP or SLAAC/DAD)? What if it increases network load from neighbor discovery so much that the LAN visibly slows down? I would argue that the default should be BCP for the network architecture in question, whatever that is, and leave the determination of BCP to those SMEs. Kyle --0000000000001dcd490571d4cf24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 25, 2018 at 3:34 PM, Christopher Wood <christopherwood07@gmail.com> wrote:
On Wed, Jul 25, 2018 at 8:05 AM Tommy Pauly <tpauly@apple.com> wrote:
>
> Yes, I'm inclined to agree=E2=80=94I think that having a unique ad= dress per connection shouldn't be the default; an application could cer= tainly always set it if it wants to decrease linkability?

Applications should not have to opt-in to better privacy. Decreased<= br> linkability should be the default. So if doing this per-connection is
shown (not just believed) to be infeasible, then per-application is a
reasonable compromise.

The problem is t= hat it might not be a dichotomy between "feasible" and "infe= asible". What if the tradeoff is increased connection latency from acq= uiring a new address (either by DHCP or SLAAC/DAD)? What if it increases ne= twork load from neighbor discovery so much that the LAN visibly slows down?=

I would argue that the default should be BCP for = the network architecture in question, whatever that is, and leave the deter= mination of BCP to those SMEs.

Kyle
<= div>
--0000000000001dcd490571d4cf24-- From nobody Wed Jul 25 08:52:55 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 6BC63130E72 for ; Wed, 25 Jul 2018 08:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yx50N-oVNf2 for ; Wed, 25 Jul 2018 08:52:30 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 0649F130DC1 for ; Wed, 25 Jul 2018 08:52:27 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id l14-v6so6714669iob.7 for ; Wed, 25 Jul 2018 08:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rI4yic4sA9S71YF4ZFBGEATz5XyeExb6m/jRbD2I3wU=; b=YfKdbjZg7ZzEmPHKqftG8ieqvxzZDaKbZ3qsiCfbPNZwCVNvq78VL1dy/eYveGrGZh Y9Z8aXnBoDt8joVVMBgbKGpvlFHXp5qiVE8teJlbch4XoU27PvgCE5VrDjTbA/9Gpagl /oNFYew2g9Vya1mk3aDlwXOw9wGDucMLJs8+poRifyoN939egiHr3hlpm943F7TP1hEs dUCBxFZ8uX2tdhQHgIS5xiF452HZwyCuqmiJ61CBKWrV6y2YV1IADKfvA8I54LNVeRV0 Tw66kgRBuCs8EudJcKKl0JfADAtOQbzGeZ7NmAVNpqvYNQf4giS7UzSczcx5QX255nIf BA0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rI4yic4sA9S71YF4ZFBGEATz5XyeExb6m/jRbD2I3wU=; b=HgjdNuSQC7s3pTMv0EZuFhJe6NBdQd35p1ZZPkFx20H6MIaNbq/UxiJwL4/1EaNlqX gPZ+XzgPgkMgkRYo/HNAL3cENPwrk7CFRfowqlXJQulXEmeoohCOe1TH//ulTkC1czlZ xjG+CR/pVu59Mtt8sVcapwTkTpvG9RpLKfdYPnEBLfp2SzskJgAKhxuXorCLTJOtwOSP PviMoi4AUouzsOKBDiXT7RWFL4cTwi6Vpf94jNpFZTB/aud6Ul7is7QTh4HRpd5e4i8l ZSHHMH1YISa92tEnyidSUFaNfvhvgSJCndgXuhKA0A7LS18i+PEJlo8/eyoibrsuX+AW Gbvg== X-Gm-Message-State: AOUpUlFzoA3vl2Qxy38IrGTFR+EzeDjxxYYFm2jPZUIFdbf0UO6Pun6f 7feDuG2kh7tfBSOCeIMKX2O3aAGrkaxcJb302LY= X-Google-Smtp-Source: AAOMgpervcanoV/iEiqjgubpfYR4VChomXV+fEzjWP/4+Xx04xKZMvbsO7ssQOfz3IR73fWo5kAmSqjpn+o/Fkbr2fE= X-Received: by 2002:a6b:8828:: with SMTP id k40-v6mr18047461iod.68.1532533946265; Wed, 25 Jul 2018 08:52:26 -0700 (PDT) MIME-Version: 1.0 References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> <20180725100158.GA68757@tom-desk.erg.abdn.ac.uk> <775025E3-1C5D-4871-93C3-B39B92383C64@cisco.com> <50004FDB-5F25-43AE-8B7B-9CF479D56EA5@apple.com> In-Reply-To: From: Christopher Wood Date: Wed, 25 Jul 2018 08:52:14 -0700 Message-ID: To: Kyle Rose Cc: Tommy Pauly , gorry@erg.abdn.ac.uk, evyncke=40cisco.com@dmarc.ietf.org, taps WG , Tom Jones , Fernando Gont Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:52:38 -0000 On Wed, Jul 25, 2018 at 8:48 AM Kyle Rose wrote: > > On Wed, Jul 25, 2018 at 3:34 PM, Christopher Wood wrote: >> >> On Wed, Jul 25, 2018 at 8:05 AM Tommy Pauly wrote: >> > >> > Yes, I'm inclined to agree=E2=80=94I think that having a unique addres= s per connection shouldn't be the default; an application could certainly a= lways set it if it wants to decrease linkability? >> >> Applications should not have to opt-in to better privacy. Decreased >> linkability should be the default. So if doing this per-connection is >> shown (not just believed) to be infeasible, then per-application is a >> reasonable compromise. > > > The problem is that it might not be a dichotomy between "feasible" and "i= nfeasible". What if the tradeoff is increased connection latency from acqui= ring a new address (either by DHCP or SLAAC/DAD)? What if it increases netw= ork load from neighbor discovery so much that the LAN visibly slows down? I would consider that infeasible, then. Note that I am simply advocating for a change in mindset wherein we consider privacy first at marginal costs. I realize that's an unpopular opinion. > I would argue that the default should be BCP for the network architecture= in question, whatever that is, and leave the determination of BCP to those= SMEs. That might work, too. Best, Chris From nobody Wed Jul 25 09:50: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 3B7E2130ED7 for ; Wed, 25 Jul 2018 09:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqhuEbImYy4s for ; Wed, 25 Jul 2018 09:49:58 -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 0BEFE130E78 for ; Wed, 25 Jul 2018 09:49:58 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id m13-v6so8310626qth.1 for ; Wed, 25 Jul 2018 09:49:57 -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; bh=Cz5lgDZWV9jJRqz0f3jcrnaCyHArpRyN2s1prUM8VVg=; b=nOPHKo3lqALF21HfDNX4jC9+UrT7T+hUtP8VxW4ned9KImjNJ/TVKiW6M0eVXR7v7a Yrc3aZcQULtRFIzfFGs9SEEfd8aqMR2yOiR67pV5j/mOi2gNs10qakN+ly1D2B7HgVgx Rs4P/q2o7YR4uFiEEKSMMSslBWCnzPfcN4xjkIhWYAhfkn8Wd8BQgxKabz5ZfJi01OZb UbLVgqgAerUuzNGIHP7WOrTgnMK7XcNna8eAqFkbjohkmpZnq5s7C6u17J1MmJPFbns5 CW1iQMA3L2Q0jbyvPGgwVFqOG+MlmZvOg3g6Uo+j7o/+YNeMyb4lproJr5R564iK1XDU bsgg== 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; bh=Cz5lgDZWV9jJRqz0f3jcrnaCyHArpRyN2s1prUM8VVg=; b=uCjCud1Xt/cYVWn9HehtnLEEp0aAJGQa1AgAMVZuUZX89ExGJk2E98uQ8QlRhhDnF2 IGXVpN31pTYrOl/hT3plNEZVA6OvNUYq3NtgzXRkQ+i0riogiOYqtQkt0VicRVI5RxAm CSrPrstzQhHhxIaDSZOFP80ZjkjfiLl5T6mdrM2T1IJruK9SoK5QGo77DugG4XSrDlJh TclHJ1txQotFU8JM6c+Dts1Yn5cKWQB3vVZpoaSQNlK432Agf/0g+F9vU/+3ZPuAx0/n 4fmwS84u3TK2YnDCuK5NpLWWRQAuS/Ca++/5WvoKg/SdvojqYgY2ncmqAHrN+JVIXnGx 3u4A== X-Gm-Message-State: AOUpUlHK2+H2swelu/EzHGxJ84c6n3IXlUZjNOLzFHqdoG8aYOmx2IY8 7tE+y2HaHS/hhcpy2kpVK9o= X-Google-Smtp-Source: AAOMgpc41yW/gNyb10c0KsFYmA/mGBp7AljGz6z7wGakna9nLkZN68dzWmKkMaCWdj5jOYU28RL2JQ== X-Received: by 2002:a0c:ae89:: with SMTP id j9-v6mr19921841qvd.174.1532537397088; Wed, 25 Jul 2018 09:49:57 -0700 (PDT) Received: from [172.19.33.74] ([2001:4878:a000:3000:81e6:a0c8:300c:926a]) by smtp.gmail.com with ESMTPSA id t3-v6sm11918866qtj.36.2018.07.25.09.49.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jul 2018 09:49:55 -0700 (PDT) From: "Aaron Falk" To: "Christopher Wood" Cc: "Kyle Rose" , gorry@erg.abdn.ac.uk, evyncke=40cisco.com@dmarc.ietf.org, "Tom Jones" , "Fernando Gont" , "Tommy Pauly" , "taps WG" Date: Wed, 25 Jul 2018 12:49:53 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <0B4E29B3-EE35-471D-8038-54BE4FDC76BA@gmail.com> In-Reply-To: References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> <20180725100158.GA68757@tom-desk.erg.abdn.ac.uk> <775025E3-1C5D-4871-93C3-B39B92383C64@cisco.com> <50004FDB-5F25-43AE-8B7B-9CF479D56EA5@apple.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_8323856D-E719-4BAC-93D5-ADEDC7572952_=" Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 16:50:08 -0000 --=_MailMate_8323856D-E719-4BAC-93D5-ADEDC7572952_= Content-Type: text/plain; format=flowed; markup=markdown On 25 Jul 2018, at 11:52, Christopher Wood wrote: > Note that I am simply > advocating for a change in mindset wherein we consider privacy first > at marginal costs. I realize that's an unpopular opinion. Consider it first? Not unpopular as I see it. Prioritize it above all other considerations? (Or below, for that matter.) That would be a concern. And AFAICT no one is suggesting that. > >> I would argue that the default should be BCP for the network >> architecture in question, whatever that is, and leave the >> determination of BCP to those SMEs. > > > That might work, too. I assume by 'network architecture' we are talking about 'access technologies', yes? If those BCPs are stated somewhere, that seems reasonable. I'm not sure whether this has been considered in depth or in an access-technology-specific way. Any citations? --aaron --=_MailMate_8323856D-E719-4BAC-93D5-ADEDC7572952_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= br>

On 25 Jul 2018, at 11:52, Christopher Wood wrote:<= /p>

Note that I am simply
advocating for a change in mindset wherein we consider privacy first
at marginal costs. I realize that's an unpopular opinion.

Consider it first? Not unpopular as I see i= t. Prioritize it above all other considerations? (Or below, for that ma= tter.) That would be a concern. And AFAICT no one is suggesting that.

<= p dir=3D"auto">I would argue that the default should be BCP for the netwo= rk architecture in question, whatever that is, and leave the determinatio= n of BCP to those SMEs.

That might work, too.

I assume by 'network architecture' we are ta= lking about 'access technologies', yes? If those BCPs are stated somewhe= re, that seems reasonable. I'm not sure whether this has been considere= d in depth or in an access-technology-specific way. Any citations?

--aaron

--=_MailMate_8323856D-E719-4BAC-93D5-ADEDC7572952_=-- From nobody Wed Jul 25 10:08: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 7614E130E97 for ; Wed, 25 Jul 2018 10:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRxX6bCLqAP4 for ; Wed, 25 Jul 2018 10:08:10 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30935130E9B for ; Wed, 25 Jul 2018 10:08:10 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id w126-v6so15185633oie.7 for ; Wed, 25 Jul 2018 10:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XlXc7WeBc8Hz8dSVXxjmue/rpQR6rBj4W7E9HJ/sd3U=; b=Ed3plXiLUv9H1mJBLigVJaOurdYNgdFwaJiPHdacsUBjq3PtqTfVZOiTRJhVEo9jC+ TnsGLbd7vf2cqneB0E9TZm8FLO85if6vjM/8wISqrq3KJd+ex2AV0UZ7gfiFYLVq236s jnonrq0rHCizmDfAac6W4xNu+qPYgwMdS+EEI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XlXc7WeBc8Hz8dSVXxjmue/rpQR6rBj4W7E9HJ/sd3U=; b=DCHAn5MmV+AXtpxcpFLeSVcr+mFuQWKccPoGM60DSlPD8HKVEWVm41sk0l+EuJbrnM huhxBvlvqahTsRPYZH7370qX5mxyX4q+DrWR38P0nM/S57k9xuKXFEjuofWKpuuJbvcR rEWGAtUnWqTqpREF0U2MjFlpzd1sgG6xLz6OlSn3NvO1pSzn2sBSVGWIQsgzcxIWOlAj IIutVEkw5fbf+uJNy0kIsC6MckMGN61Ryu323cCbFnvbavFNDsQ+wjuisASx+BCkuFL4 4Dnqep+UnKMQkIjz8/aZzJXNOMoz36jlAb0rEFD8ZauoTnD8cIlugPsxs5YLKZShLd0Z GNXQ== X-Gm-Message-State: AOUpUlEny9OsQMs9gOt0vsixkLQbele+OhDGscNZ3eGNPQtWTlsroPdU RCntfBTZ8oMA6CwlAtRSGBoRKN0922nTFUjZtBts0A== X-Google-Smtp-Source: AAOMgpf5ugJjx0i52Bn83qk9m8KJK6OBiHgN3haGO6XwnIUAloajN/Oq4nGPjx6mb5aeIk5NyW1CK43XMjUH8sGf8Ek= X-Received: by 2002:aca:d8d6:: with SMTP id p205-v6mr3933252oig.96.1532538489402; Wed, 25 Jul 2018 10:08:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:204a:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 10:08:08 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <0B4E29B3-EE35-471D-8038-54BE4FDC76BA@gmail.com> References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> <20180725100158.GA68757@tom-desk.erg.abdn.ac.uk> <775025E3-1C5D-4871-93C3-B39B92383C64@cisco.com> <50004FDB-5F25-43AE-8B7B-9CF479D56EA5@apple.com> <0B4E29B3-EE35-471D-8038-54BE4FDC76BA@gmail.com> From: Kyle Rose Date: Wed, 25 Jul 2018 17:08:08 +0000 Message-ID: To: Aaron Falk Cc: Christopher Wood , "Gorry (erg)" , evyncke=40cisco.com@dmarc.ietf.org, Tom Jones , Fernando Gont , Tommy Pauly , taps WG Content-Type: multipart/alternative; boundary="000000000000440ee50571d5eca2" Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:08:14 -0000 --000000000000440ee50571d5eca2 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 25, 2018 at 4:49 PM, Aaron Falk wrote: > > I would argue that the default should be BCP for the network architecture > in question, whatever that is, and leave the determination of BCP to those > SMEs. > > That might work, too. > > I assume by 'network architecture' we are talking about 'access > technologies', yes? > I was intentionally being very generic. You're unlikely to come up with privacy addresses (as such) on v4, given the paucity of the address space, but the NAT itself can do useful things to hide the identity of an individual user if the network behind the NAT is large enough. > If those BCPs are stated somewhere, that seems reasonable. I'm not sure > whether this has been considered in depth or in an > access-technology-specific way. Any citations? > RFC 7217 has no BCP number, but it is a proposed standard and is widely-accepted best practice for v6 operators using SLAAC. The DHCPv6 bis document (full disclosure: which I reviewed for secdir) contains some language around user privacy. For v4 with NAT, there's 1631: q[ On the other hand, NAT itself can be seen as providing a kind of privacy mechanism. This comes from the fact that machines on the backbone cannot monitor which hosts are sending and receiving traffic (assuming of course that the application data is encrypted) ] and the document that obsoleted it, 3022, which reorders the q[ Traditional NAT can be viewed as providing a privacy mechanism as sessions are uni-directional from private hosts and the actual addresses of the private hosts are not visible to external hosts. ] Curious to know what the IESG thinks about this one (or indeed anything related to NAT) now, but any further discussion along those lines can probably be taken to ietf@. ;-) Kyle --000000000000440ee50571d5eca2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 25, 2018 at 4:49 PM, Aaron Falk <aaron.fal= k@gmail.com> wrote:

I would argue that t= he default should be BCP for the network architecture in question, whatever= that is, and leave the determination of BCP to those SMEs.

That might work, too.

I assume by 'network architecture&#= 39; we are talking about 'access technologies', yes?

I was i= ntentionally being very=20 generic. You're unlikely to come up with privacy addresses (as such) on= =20 v4, given the paucity of the address space, but the NAT itself can do usefu= l things to hide the identity of an individual user if the network behind t= he NAT is large enough.

If those BCPs are stated somewher= e, that seems reasonable. I'm not sure whether this has been consider= ed in depth or in an access-technology-specific way. Any citations?

RFC 7217 has no BCP number, but it is a pr= oposed standard and is widely-accepted best practice for v6 operators using= SLAAC. The DHCPv6 bis document (full disclosure: which I reviewed for secd= ir) contains some language around user privacy.

For v4 with NAT, there's 1631:

q[ On the oth= er hand, NAT itself can be seen as providing a kind of
=C2=A0=C2=A0 priv= acy mechanism. This comes from the fact that machines on the
=C2=A0=C2= =A0 backbone cannot monitor which hosts are sending and receiving traffic=C2=A0=C2=A0 (assuming of course that the application data is encrypted) = ]

and the document that obsoleted it, 3022, which = reorders the

q[ Traditional NAT can be viewed= as providing a privacy mechanism as
=C2=A0=C2=A0 sessions are uni-direc= tional from private hosts and the actual
=C2=A0=C2=A0 addresses of the p= rivate hosts are not visible to external hosts. ]

<= div>Curious to know what the IESG thinks about this one (or indeed anything= related to NAT) now, but any further discussion along those lines can prob= ably be taken to ietf@. ;-)

Kyle
--000000000000440ee50571d5eca2-- From nobody Thu Jul 26 06:19:26 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 47516131135 for ; Thu, 26 Jul 2018 06:19:24 -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, 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 FOjs1xW4XlZS for ; Thu, 26 Jul 2018 06:19:21 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2BC131002 for ; Thu, 26 Jul 2018 06:19:21 -0700 (PDT) Received: from [192.168.1.5] (unknown [188.163.97.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7626780524; Thu, 26 Jul 2018 15:19:17 +0200 (CEST) To: Tommy Pauly , taps WG Cc: "gorry@erg.abdn.ac.uk" References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <224f2425-5ce5-377d-01b3-dd0afff57bb1@si6networks.com> Date: Thu, 26 Jul 2018 15:10:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 26 Jul 2018 13:19:24 -0000 Tommy, On 07/24/2018 02:21 AM, Tommy Pauly wrote: > Picking this thread up again, I would like to see us incorporate IPv6 address selection into a post-sockets API model. > > Here's a straw man proposal of how we can expose this via the TAPS Interface: > > - A new property for Local Address Preference, which can be a tuple of: > 1. Stable/Public > 2. Temporary/Private > 3. Unique For Connection > - Listeners would default to (1). Connections would default to (2) > - If you specify (3), the system will try to get an entirely new IPv6 address that has never been used before > - You can find out the address you used on your Listener/Connection > > This type of API would allow us to add in the functionality Erik had asked for, to allow a client to be able to request a new address. The other alternative would be to have some out-of-band API to request a new API, but I think marking this on a connection is preferable, since it allows us to enforce this per-path and per-protocol even. > > What do people think? I think that there are three key issues here: 1) Discussion of tradeoffs 2) Specification of mechanisms that allow us to convey different policies 3) Selection of e.g. defaults/desired actions First step is #1, which is what we did in one of our IDs, and of course needs more work. This helps us understand the implications f each of the possible options, and maybe decide what to expose in #2, and e.g. what the defaults should be for #3 -- and maybe even rule out some cases. That's what at least I'd suggest that we start with #1 (draft-gont-taps-address-usage-problem-statement & draft-gont-taps-address-analysis). In many cases, there are tradeoffs. So one should provide the mechanisms that allow apps/OSes t make the tradeoffs. But everything starts with understanding the problem, and understanding the tradeoffs. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jul 26 06:19:31 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 36793131002 for ; Thu, 26 Jul 2018 06:19:25 -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, 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 pi0AN2Z1NOIe for ; Thu, 26 Jul 2018 06:19:23 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47BDB131133 for ; Thu, 26 Jul 2018 06:19:23 -0700 (PDT) Received: from [192.168.1.5] (unknown [188.163.97.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 02F4782567; Thu, 26 Jul 2018 15:19:20 +0200 (CEST) To: "Eric Vyncke (evyncke)" , Tom Jones , Christopher Wood Cc: "gorry@erg.abdn.ac.uk" , Tommy Pauly , taps WG References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> <20180725100158.GA68757@tom-desk.erg.abdn.ac.uk> <775025E3-1C5D-4871-93C3-B39B92383C64@cisco.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <0ff678f7-4ed0-103d-2177-e4394b104e79@si6networks.com> Date: Thu, 26 Jul 2018 15:18:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <775025E3-1C5D-4871-93C3-B39B92383C64@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 26 Jul 2018 13:19:25 -0000 On 07/25/2018 04:48 PM, Eric Vyncke (evyncke) wrote: > Being a layer-3 person, I am a (just) little concerned by having one IPv6 address per connection as it could put some stress on Neighbor Discovery (mcast traffic draining battery, cache space/maintenance) if used by default on very short live connections > > Just a thought FWIW, while "one address per connection" is certainly mentioned as "an extreme case" in , I do agree and share Eric's concern. If anything, one might think f "one address per module" (whatever that is), or one address per process/thread... but I'm not sure I'd default to "one address per connection". I think that there might only be specific cases/scenarios where one might want to do this. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jul 26 06:26: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 BAB8A13114F for ; Thu, 26 Jul 2018 06:26:04 -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, 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 YVZUg4KO8lMX for ; Thu, 26 Jul 2018 06:26:02 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CAA3131146 for ; Thu, 26 Jul 2018 06:26:02 -0700 (PDT) Received: from [192.168.1.5] (unknown [188.163.97.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7FF1080524; Thu, 26 Jul 2018 15:26:00 +0200 (CEST) To: Christopher Wood , Tommy Pauly Cc: evyncke=40cisco.com@dmarc.ietf.org, Tom Jones , gorry@erg.abdn.ac.uk, taps WG References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> <20180725100158.GA68757@tom-desk.erg.abdn.ac.uk> <775025E3-1C5D-4871-93C3-B39B92383C64@cisco.com> <50004FDB-5F25-43AE-8B7B-9CF479D56EA5@apple.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <8f72326a-6e37-0d95-e1f6-08da37c82976@si6networks.com> Date: Thu, 26 Jul 2018 15:20:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 26 Jul 2018 13:26:05 -0000 On 07/25/2018 05:34 PM, Christopher Wood wrote: > On Wed, Jul 25, 2018 at 8:05 AM Tommy Pauly wrote: >> >> Yes, I'm inclined to agree—I think that having a unique address per connection shouldn't be the default; an application could certainly always set it if it wants to decrease linkability? > > Applications should not have to opt-in to better privacy. Decreased > linkability should be the default. So if doing this per-connection is > shown (not just believed) to be infeasible, then per-application is a > reasonable compromise. Certainly, one address per application would be a more sensible default. However, I'm of the idea that whatever default one picks is the result of an analysys of tradeoffs, and not the other way around. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jul 26 10:13: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 38C47130EDC for ; Thu, 26 Jul 2018 10:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b68W9-c1SXz0 for ; Thu, 26 Jul 2018 10:13:38 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC21D130E85 for ; Thu, 26 Jul 2018 10:13:37 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id l7-v6so1967857ioj.1 for ; Thu, 26 Jul 2018 10:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hr8w0iZxqWMSPdydJADTNLb4loUR2i2hdI3xW41cD2w=; b=raA4dq4LcdJdGfs8VurwMDHNqx67gNOr8XYyfck+6ngRKjvCk0Zhi6m7c7xShX4b09 RTEg5JOvfmRVd9uqxObhMSWeaskHCfo+qY9+DOyfSpD1PwL+JIBb0VnH+OFiV32oTCBO 8yxyra6HZKFS+J3xGTyevRamMeMQuyxYgyEdpiSmnC5ElC4esfDdcS1E7t8dCX6L2hrI pRPBi2j4HHEqo4KCkgbnWcyhJXs4AU4RusL7d1PB2GQeCwTmWkZS1jVVkxPD881sCOS+ 04pbskWXuE9ULI7tJN/kH0y7ptycuvOp6jfj9xEn/BkLG0SnceFESY2w/CHMmBfDoWCm YnSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hr8w0iZxqWMSPdydJADTNLb4loUR2i2hdI3xW41cD2w=; b=kG0qaCU2JaO+8Mji7QlDGYX5i2sl/8h8h4SeNVFaRMvQp+G6tB7a6fkjeykZmHcQkK QrIyJy2k4x6Lg6VEe2xg2rID1q+yV4xxk604cLYp1r+GO4AEKrcOAxx3CCUbsmWYzCMH eepTPskL7Gf40h7kcbREXgXG1ykrvhLH9mZr8eOphDS106vcyMdO9FYg6CfOQBhjxzNZ 8AyyCeG6T7sstuF1GxoFxK3rg/tRxJSU+RKCZ7YEjvgEgL/dz+Uw3ZSlA1FNz0g0vb7h G3tvzL6Ym8ctNSc0lmBCFVz3uoZ1juPRhoJQPPJ/fyLNazvqLbX55VL4JzSEp2V48Ini jOtw== X-Gm-Message-State: AOUpUlEA3eZBZX23t/R7gCVRenGu5ntDVSCsgGog9WR0aq4rFGopGcyN z8t2UjhvR01XxxXOG3zYnguYbjWc5ZyDbe/xnLY= X-Google-Smtp-Source: AAOMgpdEoE6fEfvXGzFLJbqXw37CxHPTNY03HkH2SQ6G8GgZ6nBr4X7BVFkiLWcavGBUs1lS5mxFPyZ+Izdeeskw5wA= X-Received: by 2002:a6b:8828:: with SMTP id k40-v6mr2438686iod.68.1532625217054; Thu, 26 Jul 2018 10:13:37 -0700 (PDT) MIME-Version: 1.0 References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> <20180725100158.GA68757@tom-desk.erg.abdn.ac.uk> <775025E3-1C5D-4871-93C3-B39B92383C64@cisco.com> <50004FDB-5F25-43AE-8B7B-9CF479D56EA5@apple.com> <8f72326a-6e37-0d95-e1f6-08da37c82976@si6networks.com> In-Reply-To: <8f72326a-6e37-0d95-e1f6-08da37c82976@si6networks.com> From: Christopher Wood Date: Thu, 26 Jul 2018 10:13:24 -0700 Message-ID: To: Fernando Gont Cc: Tommy Pauly , evyncke=40cisco.com@dmarc.ietf.org, Tom Jones , gorry@erg.abdn.ac.uk, taps WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 26 Jul 2018 17:13:39 -0000 On Thu, Jul 26, 2018 at 6:26 AM Fernando Gont wrote= : > > On 07/25/2018 05:34 PM, Christopher Wood wrote: > > On Wed, Jul 25, 2018 at 8:05 AM Tommy Pauly wrote: > >> > >> Yes, I'm inclined to agree=E2=80=94I think that having a unique addres= s per connection shouldn't be the default; an application could certainly a= lways set it if it wants to decrease linkability? > > > > Applications should not have to opt-in to better privacy. Decreased > > linkability should be the default. So if doing this per-connection is > > shown (not just believed) to be infeasible, then per-application is a > > reasonable compromise. > > Certainly, one address per application would be a more sensible default. > However, I'm of the idea that whatever default one picks is the result > of an analysys of tradeoffs, and not the other way around. I concur. Privacy is not binary, as Aaron suggests. It's a gradient, so tradeoffs must necessarily be made based on use case analysis. Best, Chris From nobody Mon Jul 30 03:23: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 A5749130E7A for ; Mon, 30 Jul 2018 03:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 M8As1s0ib_gm for ; Mon, 30 Jul 2018 03:23:40 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 51FAD130FFB for ; Mon, 30 Jul 2018 03:23:40 -0700 (PDT) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9DFCF1B0014F for ; Mon, 30 Jul 2018 11:23:32 +0100 (BST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id F207321D6F for ; Mon, 30 Jul 2018 06:23:30 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 30 Jul 2018 06:23:30 -0400 X-ME-Proxy: X-ME-Sender: Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [137.50.17.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 7701810278 for ; Mon, 30 Jul 2018 06:23:30 -0400 (EDT) Date: Mon, 30 Jul 2018 11:23:33 +0100 From: Tom Jones To: taps@ietf.org Message-ID: <20180730102330.GA88170@tom-desk.erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: [Taps] Summary of TCP Fast Open Interfaces X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 30 Jul 2018 10:23:43 -0000 Hello TAPS, In Montreal the topic of 0RTT and idempotent interfaces came up, I remember there being interest in a summary of TCP Fast Open APIs. Michael Tuexen[1] forwarded me a TFO test program for a different reason and this seemed like a good starting point to attempt to summarise the APIs on different Operating Systems. I have included simplified APIs for Linux, FreeBSD, Mac Os and Windows[2][3]. I quickly searched for other Operating Systems none of the below had an easily googlable API for TCP Fast Open: NetBSD OpenBSD Dragonfly BSD Haiku React OS Riot OS If there are other platforms with TFO which I have missed I would appreciate a pointer to documentation. - Tom A summary of TCP Fast Open Interfaces Linux socket(IPPROTO_TCP) sendto(endpoint, MSG_FASTOPEN, data) Perform a sendto() call on the socket with a flag to indicate fast open and the idempotent data. FreeBSD socket(IPPROTO_TCP) setsockopt(TCP_FASTOPEN) sendto(endpoint, data) Call setsockopt() to enable fast open. Call sendto() with the idempotent data. Mac OS socket(IPPROTO_TCP) connectx(endpoints, data) Call to connectx() function with set of addresses and idempotent data to send. Windows socket(IPPROTO_TCP) setsockopt(TCP_FASTOPEN) bind(local_addr) ConnectEx(endpoint, data) Set the fast open options on the socket. ConnectEx() must be called bound to a local address, bind() the socket to an address Start the connection with the ConnectEx() call, pass in the idempotent data. Note: This summary is deliberately a simplification of the API to aide comparison, full details are in various platform documentation. All of these platforms support binding to a local address before the call, the ConnectEx() API on Windows requires it[2]. connectex() on Mac OS supports passing in a local addresst to bind to. [1]: https://github.com/nplab/test-programs/blob/master/tcp-fastopen.c [2]: https://docs.microsoft.com/en-us/windows/desktop/api/mswsock/nc-mswsock-lpfn_connectex [3]: https://gist.github.com/krrr/8b5fec3c93dc332bc8109641206529b5 From nobody Tue Jul 31 10:55:26 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 5269E130DF7 for ; Tue, 31 Jul 2018 10:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ja3beSs0Rsl for ; Tue, 31 Jul 2018 10:55:22 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2DB1292AD for ; Tue, 31 Jul 2018 10:55:21 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id t79-v6so10848726qke.4 for ; Tue, 31 Jul 2018 10:55:21 -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:mime-version; bh=C0/DUIT1jilyz4ec5FeBiRHmDwqJIY60n25zTdD7c4Q=; b=fbDZnF3O9fawmzrE4kG6bzOSY8RPZSRrIFjHC+OJhTIR9/ic7GuXFYjQqxJSK7oP2S ldg0+/SUCZTEN9xtYwmpl0daB+qCxDGoQ9SUKsdDIexovDAeq7yvMyUvqOpuKgj3M4vs TzU7fYpLDi1uSR15si1Sd+a6TBzyCIEqqaUhKTOMBoFY0yHILuRhz5MIOX3Qs1UDZTf0 U2WiwPzGqys3G77BVOm7rujnSuMDKkQgK9GoG1+BExPQ4W9cUxe8u0mJcMopergBukWJ z0CjbXgs/5VckrECMSo3XjWoTT8/Ifj2ON+thlwfM5aPvLiyWN37QveZFufuTBX6wjBE bVmQ== 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:mime-version; bh=C0/DUIT1jilyz4ec5FeBiRHmDwqJIY60n25zTdD7c4Q=; b=esd7/2TdBgxZlCuhoZGLaA8pqM0aaG2LQ2dUnITuEN376hOAFCfG+sX7IXu8mjgxWd fzJl0y+eY6/jLtua0ED/uBCZVkfDhqSWaC8TJN407w5tCGUjNN9KipUCO1NL9mpeZ+/E 2V607b9j/kn72GgZcq/mnk9Otnf8bnKoWmJ0fU1H/WPCyz2lUaye2v1I8NrysOA+Sj6L ExqtfyaLPXvM9TSteVsbynOU+Y8X4uqNmxLJq2BcnEg7Me2W6cuDAsBB2Y2hBUodhykP 1a1AoxI/bGaWuUdti7HO2xi+RuRi6qvIDvCvjoTnRbNHLw3h1WZu/PlDIun98ezgYDSO m0vA== X-Gm-Message-State: AOUpUlG032GzkEB6uvQibbv9uTVXNrAbRk3L4RJsxIe05JGMmlY4KsZc vB0zO6zSrnIKqY/luPFyFiEdaTsi X-Google-Smtp-Source: AAOMgpesVOzgoVuSj2RwGrBOdABt29RruBDhh2YFYXDolyGIyeULVk5/1LowUkDXWwDDeXH2MUTUcA== X-Received: by 2002:a37:9702:: with SMTP id z2-v6mr20955667qkd.183.1533059720546; Tue, 31 Jul 2018 10:55:20 -0700 (PDT) Received: from [172.19.37.172] ([2001:4878:a000:3000:567:3ac5:2b71:e3c8]) by smtp.gmail.com with ESMTPSA id 127-v6sm9031880qkn.78.2018.07.31.10.55.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 10:55:19 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Cc: "Spencer Dawkins at IETF" , "Zaheduzzaman Sarker" Date: Tue, 31 Jul 2018 13:55:18 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <4AE4D127-54E2-435F-8C41-2A025164C3EA@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_9162FFE6-5331-4144-9091-0D5B7DBEE70D_=" Archived-At: Subject: [Taps] ACTION REQUIRED: TAPS interim scheduling X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 31 Jul 2018 17:55:25 -0000 --=_MailMate_9162FFE6-5331-4144-9091-0D5B7DBEE70D_= Content-Type: text/plain; format=flowed; markup=markdown Hi Folks- Following up on our Montreal meeting we agreed to hold an online interim meeting to continue progress discussing (at a minimum): Partial Send/Receive and 0-RTT. I'm proposing two times that I think cause the least pain for PSD and CDT timezones. Please be flexible to permit the most folks to participate. Note that authors' availability will take precedence. Doodle will close on Aug 3. https://doodle.com/poll/hpdfptdn7fznviir Thanks, --aaron --=_MailMate_9162FFE6-5331-4144-9091-0D5B7DBEE70D_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Hi Folks-

Following up on our Montreal meeting we agreed to hold an= online interim meeting to continue progress discussing (at a minimum): P= artial Send/Receive and 0-RTT. I'm proposing two times that I think caus= e the least pain for PSD and CDT timezones. Please be flexible to permit= the most folks to participate. Note that authors' availability will tak= e precedence. Doodle will close on Aug 3.

https://doodle.com/poll/hpdfptdn7fznviir

Thanks,

--aaron

--=_MailMate_9162FFE6-5331-4144-9091-0D5B7DBEE70D_=-- From nobody Tue Jul 31 12:17:34 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 BDEBC130E75 for ; Tue, 31 Jul 2018 12:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvZiCSU5FMC5 for ; Tue, 31 Jul 2018 12:17:30 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5A6130E63 for ; Tue, 31 Jul 2018 12:17:30 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id a5-v6so17207992qtp.2 for ; Tue, 31 Jul 2018 12:17:30 -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; bh=Wm7VB0yhIGErEAaZb0hhoXtw1/6PH5Ub6uStgbidJs0=; b=H5bAh+Yqk43r5vVOK6O0mXLTw/Ff0sQMTkRUsKWlCdJdqU0Y28hqZNXib8ZWBNK2NZ /K1gS/sH5fVJRYwqXfZGPK3HMMmZ+VRKRJkI06T+72iPG8Z7MLTizgikQoURMdv83y8C Ki03lWTwshXlmZ/q2oJexDQerjlQqla0WUgsVHdE4gZ61J5q5lZTwPiQtSMyNmc2nDlK M22OMwp1X1dOEddMK2qZvh1rGk3VnFZebTo+7IPCX2J9R0veL3Hxh21OX7R6EuE0Dyun EuHm8B6UCb5/pL4iWYRrySAx1ZWMcO3KMREVtqVxRTnvJ7WMI3UszmZ7B/UgGG+hkIug jw4g== 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; bh=Wm7VB0yhIGErEAaZb0hhoXtw1/6PH5Ub6uStgbidJs0=; b=eumZrHWp/IPvvsF7N93s1joZoDDpFmT1CD6Q9L5bw99NONLwbcRiUBpopzdx/G/Gb/ upUbsRCIRqR6CaNdU+W7spHN8ZDKo2liV4HNN5uHiMECcjkCdEL/LxMgbF4441rft5GV P5iNzfFLVgVS/qAwFQjJYHP4aqRjfkOsgPYQw2a+XQC0uVTh+SUed+5C6+XnnvrPCGHZ C/H/0zMjH0qBBWMdCq9OPW5queIq7HwORJuG6dK0rJEq5qUnNgVXz4kG8VhSMVdrdkFg nF6cgw1VAdEsuducFaKtAoZ/tIfX5TzPGX9OTXZt6GqSRDfR65bA+WZbtgGHttSnPMRd QwrQ== X-Gm-Message-State: AOUpUlEGr0ztYrQbtbaYvT68xeviSI5dUKsZ4hKjyJWxyTLLASN0K6fA erteXAugk7C5dmnNQ0xj4RMbQ/LE X-Google-Smtp-Source: AAOMgpfgJhXllwHqJ8ILDsibzBf6u4M5AkxaAZyXElb+zcm+Ps5RaWHe2geh3G/nFB1VaRM7ZjMOAw== X-Received: by 2002:aed:2496:: with SMTP id t22-v6mr21934666qtc.44.1533064649243; Tue, 31 Jul 2018 12:17:29 -0700 (PDT) Received: from [172.19.37.172] ([2001:4878:a000:3000:45bb:75e8:2d6c:8e1e]) by smtp.gmail.com with ESMTPSA id j45-v6sm13094305qta.46.2018.07.31.12.17.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 12:17:28 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Cc: "Theresa Enghardt" , "Zaheduzzaman Sarker" Date: Tue, 31 Jul 2018 15:17:27 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <19B6D12A-B522-4836-ABDF-FCEBB6C81C47@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_33E9D309-A26D-4ED9-BE5C-F2CE04CF9728_=" Archived-At: Subject: Re: [Taps] TAPS notes X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 31 Jul 2018 19:17:33 -0000 --=_MailMate_33E9D309-A26D-4ED9-BE5C-F2CE04CF9728_= Content-Type: text/plain; format=flowed; markup=markdown I've seen a couple of minor tweaks to the notes. I'll be submitting these as the meeting minutes at the end of the week so please take a look and make any corrections. --aaron On 23 Jul 2018, at 16:42, Aaron Falk wrote: > TAPS speakers & questioners, > > Please review the Etherpad notes from the meeting. Deep thanks to > Theresa for doing such a thorough job and doing it quickly! > > --aaron > > On 23 Jul 2018, at 5:23, Theresa Enghardt wrote: > >> Hi Aaron, >> >> I had another look at the TAPS notes and double-checked some parts >> with >> the recording. >> I'd consider them done now on my part, pending corrections from the >> Working Group. >> >> See >> https://etherpad.tools.ietf.org/p/notes-ietf-102-taps?useMonospaceFont=true >> >> Best, >> Theresa --=_MailMate_33E9D309-A26D-4ED9-BE5C-F2CE04CF9728_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I've seen a couple of minor tweaks to the notes. I'll be = submitting these as the meeting minutes at the end of the week so please = take a look and make any corrections.

--aaron

On 23 Jul 2018, at 16:42, Aaron Falk wrote:

TAPS speakers & questioners,
Please review the Etherpad notes from the meeting. Deep thanks to Theres= a for doing such a thorough job and doing it quickly!

--aaron

On 23 Jul 2018, at 5:23, Theresa Enghardt wrote:

Hi Aaron,
I had another look at the TAPS notes and double-checked some parts with the recording.
I'd consider them done now on my part, pending corrections from the
Working Group.

See
https://etherpad.tools.ietf.org/p/n= otes-ietf-102-taps?useMonospaceFont=3Dtrue

Best,
Theresa

--=_MailMate_33E9D309-A26D-4ED9-BE5C-F2CE04CF9728_=--