From nobody Thu Mar 1 06:54:52 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 A628112E85E for ; Thu, 1 Mar 2018 06:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 it4hTuQb5u7l for ; Thu, 1 Mar 2018 06:54:48 -0800 (PST) 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 0901D129502 for ; Thu, 1 Mar 2018 06:54:48 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 77A88341292; Thu, 1 Mar 2018 15:54:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.6871); Thu, 1 Mar 2018 15:54:45 +0100 (CET) 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; Thu, 1 Mar 2018 15:54:45 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 46979986; Thu, 01 Mar 2018 15:54:45 +0100 From: "Brian Trammell (IETF)" Message-Id: <05C81085-2CD2-4570-92F9-A51F81F85ECB@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_FE85A299-EE3C-4855-93A4-305254A73619"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 1 Mar 2018 15:54:44 +0100 In-Reply-To: Cc: "taps@ietf.org" , Tommy Pauly To: Zaheduzzaman Sarker , Aaron Falk References: <9A9E1AC0-8916-4857-8C08-EF9C20568375@ericsson.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Taps] Call for agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 01 Mar 2018 14:54:51 -0000 --Apple-Mail=_FE85A299-EE3C-4855-93A4-305254A73619 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Zahed, Aaron, all, > On 27 Feb 2018, at 18:28, Tommy Pauly wrote: >=20 > Hi Zahed & Aaron, >=20 > We=E2=80=99ve posted the first of three new documents proposed for = milestone 3, "An Architecture for Transport Services=E2=80=9D (please go = read it, everyone!): >=20 > https://datatracker.ietf.org/doc/draft-pauly-taps-arch > https://tools.ietf.org/html/draft-pauly-taps-arch-00 >=20 > The API and Implementation documents are forthcoming, and will be = posted before the submission deadline. And now we have posted the second document (please go read it, = everyone!): https://datatracker.ietf.org/doc/draft-trammell-taps-interface. The document combines concepts of the Post Sockets, NEAT, and Socket = Intents approaches to provide an interface to the architecture in the = first document at the level of a language-independent, abstract = asynchronous interface definition. We'd like 10-15 minutes after Tommy to build on the architecture and = introduce the concepts. ISTM (though I haven't discussed with Tommy, = Anna, and Micheal, the other editors) that the discussion time for these = documents can probably be combined. Cheers, Brian > I=E2=80=99d like a slot to go over the Architecture document and = approach itself. A 15/20-minute talk with flexible discussion time would = likely be good. I imagine we=E2=80=99d also want slots to discuss the = API and Implementation documents to present them to the whole group as = well. >=20 > Thanks, > Tommy >=20 >> On Feb 27, 2018, at 1:13 AM, Zaheduzzaman Sarker = wrote: >>=20 >> Hi TAPS, >>=20 >> Your chairs are planning for the IETF 101 London Session. Please send = your proposal(s) for agenda item and also mention what points you would = like to discuss during the IETF101 meeting during your timeslot. >>=20 >> BR >>=20 >> Zahed & Aaron >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_FE85A299-EE3C-4855-93A4-305254A73619 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlqYFDQACgkQihK3vwvq RqPYeA//ZZnIaD2Iyia4g/4yVlOIWJrGooxVse4XgelunJC+G7MH7uDk4ZHyGsG5 Pk7CVJUGbBhMfGDRh9MGIpagxrIfZuGXHCQsDKR0Dx5j0KotRVVaU3QGwACnRb0T u/s6J3NQxYTZ2pSvXjzxv8NS1Bys3YkA6feEl4RfLmtJCCHBNE28bOnsr9TSgs/w +EDI9eqcJg6rAZJsmwzL1mxtb9nzPDhrmk/2COpYXvILg3ZIuexHUQbRhSDmWSWw HXOQoJKzy8C7eNpCSWC6vnUttpTHaJh73SongALR0TdNcqG98Tc49Jxc1SA2MQsW gdxEj8lOHu2dDwZsKzGBf/Slzg2bOhhC8/J2dJnpcNs98k4xKT62KD0ldj1vvAFO yfuL0brwMZEUcHuGjcSNwBafm3R4o8qGumG9WBmK4XGGeEZjlZQJImI2IpzLV975 1FNGHbOixoCfKE4qxYmymyRUk6K7q4wmhuElWlZLIVyladJCN7iC0nw12g/lrDKm Ga0cwntvugGFLHVdeHJcVB3RbAGYXsCfrMaeaPWTOnKNVYpHHhJv7HJQHoGklfol RxgXPWWGCWq4M6k78PlmTU9t17+oyz07tga1nnmit5IL445XitDkdWR7cvhIkiWF rPuTiRITWbOdGI1Tl2NlO79BxfxRWztDl3wU4r6SAMaDcxGg8Rg= =uW3+ -----END PGP SIGNATURE----- --Apple-Mail=_FE85A299-EE3C-4855-93A4-305254A73619-- From nobody Thu Mar 1 07:04:37 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 64B65126BFD for ; Thu, 1 Mar 2018 07:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ai5TkkJ23fS4 for ; Thu, 1 Mar 2018 07:04:33 -0800 (PST) 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 6A1E1129C6D for ; Thu, 1 Mar 2018 07:04:33 -0800 (PST) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1erPkz-0000o2-84; Thu, 01 Mar 2018 16:04:29 +0100 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.4]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.90_1) (envelope-from ) id 1erPkw-0001SV-Mz; Thu, 01 Mar 2018 16:04:28 +0100 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_45F16F4F-9015-4A31-B969-C657ED5A0FF8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 1 Mar 2018 16:04:03 +0100 In-Reply-To: <05C81085-2CD2-4570-92F9-A51F81F85ECB@trammell.ch> Cc: Zaheduzzaman Sarker , Aaron Falk , Tommy Pauly , "taps@ietf.org" To: "Brian Trammell (IETF)" References: <9A9E1AC0-8916-4857-8C08-EF9C20568375@ericsson.com> <05C81085-2CD2-4570-92F9-A51F81F85ECB@trammell.ch> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.4]; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.077, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B94DDA04FAFBEA634B11D6BB75C6D5425EE509E4 Archived-At: Subject: Re: [Taps] Call for agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 01 Mar 2018 15:04:36 -0000 --Apple-Mail=_45F16F4F-9015-4A31-B969-C657ED5A0FF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 1, 2018, at 3:54 PM, Brian Trammell (IETF) = wrote: >=20 > hi Zahed, Aaron, all, >=20 >> On 27 Feb 2018, at 18:28, Tommy Pauly > wrote: >>=20 >> Hi Zahed & Aaron, >>=20 >> We=E2=80=99ve posted the first of three new documents proposed for = milestone 3, "An Architecture for Transport Services=E2=80=9D (please go = read it, everyone!): >>=20 >> https://datatracker.ietf.org/doc/draft-pauly-taps-arch = >> https://tools.ietf.org/html/draft-pauly-taps-arch-00 = >>=20 >> The API and Implementation documents are forthcoming, and will be = posted before the submission deadline. >=20 > And now we have posted the second document (please go read it, = everyone!): >=20 > https://datatracker.ietf.org/doc/draft-trammell-taps-interface = . >=20 > The document combines concepts of the Post Sockets, NEAT, and Socket = Intents approaches to provide an interface to the architecture in the = first document at the level of a language-independent, abstract = asynchronous interface definition. >=20 > We'd like 10-15 minutes after Tommy to build on the architecture and = introduce the concepts. ISTM (though I haven't discussed with Tommy, = Anna, and Micheal, the other editors) that the discussion time for these = documents can probably be combined. Definitely, I say, as one of them! Cheers, Michael --Apple-Mail=_45F16F4F-9015-4A31-B969-C657ED5A0FF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 1, 2018, at 3:54 PM, Brian Trammell (IETF) <ietf@trammell.ch> = wrote:

hi Zahed, Aaron, all,
On 27 Feb 2018, at 18:28, = Tommy Pauly <tpauly@apple.com> wrote:

Hi= Zahed & Aaron,

We=E2=80=99ve posted = the first of three new documents proposed for milestone 3, "An = Architecture for Transport Services=E2=80=9D (please go read it, = everyone!):

https://datatracker.ietf.org/doc/draft-pauly-taps-arch
https://tools.ietf.org/html/draft-pauly-taps-arch-00

The API and Implementation documents are = forthcoming, and will be posted before the submission deadline.

And now we have posted the second = document (please go read it, everyone!):

https://datatracker.ietf.org/doc/draft-trammell-taps-interface<= /a>.
The document combines concepts of the Post = Sockets, NEAT, and Socket Intents approaches to provide an interface to = the architecture in the first document at the level of a = language-independent, abstract asynchronous interface = definition.

We'd like 10-15 minutes after = Tommy to build on the architecture and introduce the concepts. ISTM = (though I haven't discussed with Tommy, Anna, and Micheal, the other = editors) that the discussion time for these documents can probably be = combined.

Definitely, I say, as one of them!


= --Apple-Mail=_45F16F4F-9015-4A31-B969-C657ED5A0FF8-- From nobody Fri Mar 2 01:07:49 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 2B4E91267BB for ; Fri, 2 Mar 2018 01:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=CGmUFPs3; dkim=pass (1024-bit key) header.d=ericsson.com header.b=kjNaRl5W Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuiH0ZqIAcxH for ; Fri, 2 Mar 2018 01:07:45 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 070FC12706D for ; Fri, 2 Mar 2018 01:07:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519981662; 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=xrOIcWbR3yKftvq2hK103GxAoq8zapX02r66Yt+LQJI=; b=CGmUFPs3sGW4LX7I6599Pv66jLEgfs/QQnlyCIqDv44sjccqgbt3MxMyBXEXJw7o Zm+FL8iWRgPyTfAjN4gXZT9CmHnDjrjlj2pjgbsEvZjRbxX4UtnJcg0ESJqhf9e0 WxgYXHwJM3a9yB4bY7qqabwB1BsO2RjZizHwYPLZZVs=; X-AuditID: c1b4fb3a-347ff700000067b4-9e-5a99145e4d3e Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 08.88.26548.E54199A5; Fri, 2 Mar 2018 10:07:42 +0100 (CET) Received: from ESESBMR503.ericsson.se (153.88.183.135) by ESESSHC001.ericsson.se (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 2 Mar 2018 10:07:41 +0100 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMR503.ericsson.se (153.88.183.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Fri, 2 Mar 2018 10:07:42 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via Frontend Transport; Fri, 2 Mar 2018 10:07:42 +0100 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; bh=xrOIcWbR3yKftvq2hK103GxAoq8zapX02r66Yt+LQJI=; b=kjNaRl5WRTJlHE0FPylZ5zXVWglOBti+33lChhmOUfn14AUB7/6p7BlGcL/9sb7hgdBw8UtbgtTLANTHVWB3+pv0vm9psJ1zYfNQGTzHwBR5RqLeqrtIWm12meQa/AI1LayazA4iedZeNz0N/eQD2RPJO96MErbdytgrcaHGwAo= Received: from HE1PR07MB1660.eurprd07.prod.outlook.com (10.166.124.138) by HE1PR07MB1146.eurprd07.prod.outlook.com (10.163.178.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.548.6; Fri, 2 Mar 2018 09:07:40 +0000 Received: from HE1PR07MB1660.eurprd07.prod.outlook.com ([fe80::4cec:56ea:a3ae:b080]) by HE1PR07MB1660.eurprd07.prod.outlook.com ([fe80::4cec:56ea:a3ae:b080%5]) with mapi id 15.20.0567.006; Fri, 2 Mar 2018 09:07:40 +0000 From: Zaheduzzaman Sarker To: Michael Welzl , "Brian Trammell (IETF)" CC: Aaron Falk , Tommy Pauly , "taps@ietf.org" Thread-Topic: [Taps] Call for agenda items Thread-Index: AQHTr6su0anPZ/C89EGXobGKH/oSgKO4gWcAgAL5ugCAAAKbgIABP5EA Date: Fri, 2 Mar 2018 09:07:40 +0000 Message-ID: References: <9A9E1AC0-8916-4857-8C08-EF9C20568375@ericsson.com> <05C81085-2CD2-4570-92F9-A51F81F85ECB@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.29.0.171205 x-originating-ip: [192.176.1.82] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1146; 6:P+QOPmzUpfP8pveAMj6V9KhOXlYr7ZiN97SyPZbKqvQ31i45SrNN6AxMQV4wMsZPZl0+vosQ6EoZ2ZG4sTOBpDJKwmbuy6s20s1eKCu9i+OfZibDj7ziNgd8bHi4hthE84p+a4QiJ/Gvj3sKK9g9hgV/e9uN0PBwwBBRCwOZg6pBXrjADS5hYBBQCEAw9uK/BuA6++f0EhPog5TFtGV3ZdoRviNqYY8CN+7whfPcNUutGKXPPXR4WWsjwOY9jh/C0vK8TShztCq0j6cljXHBHRT5EjfFnMNAjA/icmMkjup12G4XDrx/7Wv22GXTL2mJPFqdRALkYIlNt3twS02S05C2akPM4QGezZsdpi0OXqxhkMZVd9kKptOWJ4WnAlbc; 5:MWa/ewjei6drpWbdZznYNT3f8HfkEx7msms7DkSHX14FeV9QArR3WVkWycKtlg+jLBkzCqyFCuZZZK8ntLVeA7ONpssKUTIsgvh+FjMFecgKEgZta50VdvZBrZcpnB+8tXLW0I3fscWQKthV1zEBis15avgxlh3fNifVogj8WQ8=; 24:sQjQkr5agpdFnUXiil7umpdpaxi2x4/mldR3rK5V4N1GvOyqrlshNiLbAFT1ebIT8Cyz3XntVEEVscXxryLK+jlRFLzj2u3L1ulnuAH7SMY=; 7:9bFemkH838JjgZYI+qsj3C1SFVDygRIy2xd0tyK+NKS92Kqcjqn3P/bNA9odXcT2iRcyFWz1n5g6vTtGb0Yaww3oXc7DcdNxaeXWhusVXcMniIqXjWPh21ESbcC6EtGvkOnCQYc1+ig7ChXfbWN5XRbSTyGVehsZvfjSqEoww5oJHiRUj3N4N930YSXzJJt1w4BHI4AqxXuf/AQaL3q7Diw7ac+5fHz8aGNhufmt4AqWbfOkYOORNbfeDBjIfXj5 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 28f7e645-33a5-4889-8aa3-08d5801d0cfd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR07MB1146; x-ms-traffictypediagnostic: HE1PR07MB1146: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(80524489315369)(120809045254105)(21748063052155)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231220)(944501237)(52105095)(3002001)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:HE1PR07MB1146; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1146; x-forefront-prvs: 05991796DF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(39380400002)(376002)(366004)(189003)(199004)(377424004)(33656002)(229853002)(2950100002)(26005)(14454004)(25786009)(186003)(110136005)(39060400002)(6512007)(54896002)(58126008)(6246003)(4326008)(6306002)(54906003)(93886005)(99286004)(2906002)(5250100002)(8666007)(86362001)(236005)(966005)(5660300001)(83716003)(606006)(478600001)(53936002)(36756003)(3280700002)(3660700001)(6436002)(8676002)(105586002)(7736002)(6346003)(81156014)(81166006)(316002)(66066001)(2900100001)(97736004)(6486002)(53546011)(102836004)(82746002)(6116002)(6506007)(3846002)(68736007)(76176011)(106356001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1146; H:HE1PR07MB1660.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-microsoft-antispam-message-info: besth4Nz9fCnBn4a5SnWxPikEwfiVgY6Drsi3ZdgfpsAOQ85tJQXv8kxpIw4A+Gq8Yqw39nEN4s9EMr+58sefQdtljoiHmkzeJr46PRmfIRWrXIUUt2foIws7r4NcN1W/KAHhTsvrXV4WHpbXEBpU7ay/VzQWAtL+5923PWG0RY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B4160F527C71494EB46F3F8B4A6FAE15ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 28f7e645-33a5-4889-8aa3-08d5801d0cfd X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2018 09:07:40.2011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1146 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHO7v37l7FwWlt+cOQakWWke9wlGhJyAp6UUEMK5feVJxb7Jql BS1dCatmgpWT3o3wVaK5rOihM0RrohWsQl2t2ctX9jLNkrbdBf33+Z3fh/P9nR+HIcTdVAiT rcljdRqVWiYMJM3bm6XLdkrMyijn5eXyY1NnKHmDYVQon+i6Q8n7UuVlHa3UKkph7ZwQKu5U 9tMKi2VSoKitdRGKgYdmchOlDEzIYNXZ+awuMjEtMMvoOELv7dl4wDk9IdSjm+uNiGEAx8G3 h/FGFMiIcRuC5oYemi9uIqiosVN8MY5gzKxHfGERwI36W4S3IPFXARgaTQIjCvB0ygQw+iKZ t1wIho4W094QIU4A99UNXkeCt8Lnn6WklwmcBU0XnhJenoWXwGTRfZJ3wqG0eJjiOQWaOhqQ l0m8EN5UjfiyRDgJLANV/ll7PePVV/uyAnAi3G9b53UQng0/H9cJ+KxgKPpe7bsTMAbLvW6C Zyl8ck/7zqU4Aj7aHTS/l3nQNijilVB4dvG47/GAHTQ4TS7/PRFgLRtBPK8HwxUnyUsdCH61 vPUHhMPzEwa/lAOvf/fSPB8E06P31CkUXfnffDynw0mT28ciPBM6zQNkpWcmwrOj+ruRvDIf yo+7aJ4Xw9Fz5/2sgMGzT6j/nUuIqUFSjuW43MyYmAhWl53OcVpNhIbNa0Seb9baNLXiNmr9 sNqGMINkQaLGALNSTKnyuYJcGwKGkElEhrEKpViUoSooZHXaXbp9apazoTkMKQsWJe+RK8U4 U5XH5rDsXlb3rytgAkL0aEGna+Nm+ZeaqNOFau0+e9q12HMP6haUlww3OG8NrLWWdO8PO1F8 WJ+6xLy089WZ7f272xfNtM8KHaqna9+1/LGmxm4Yy7W2H7GvmeGKW1ih3TY5otV0rUsZmlp2 /XKY3r1jJY5qcZFJir5Q5fih1vi5W+K0o8M7kuN/tCsctiDJSxnJZamiwwkdp/oL4ceMd2ID AAA= Archived-At: Subject: Re: [Taps] Call for agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 02 Mar 2018 09:07:47 -0000 --_000_B4160F527C71494EB46F3F8B4A6FAE15ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmVyeSBnb29kLiBXZSBjYW4gYWxsb2NhdGUgYSBnb29kIHBvcnRpb24gb2YgdGltZSBmb3IgdGhp cyBkaXNjdXNzaW9uLg0KDQpCUg0KDQpaYWhlZA0KDQpPbiAyMDE4LTAzLTAxLCAxNjowNSwgIk1p Y2hhZWwgV2VsemwiIDxtaWNoYXdlQGlmaS51aW8ubm88bWFpbHRvOm1pY2hhd2VAaWZpLnVpby5u bz4+IHdyb3RlOg0KDQoNCk9uIE1hciAxLCAyMDE4LCBhdCAzOjU0IFBNLCBCcmlhbiBUcmFtbWVs bCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g8bWFpbHRvOmlldGZAdHJhbW1lbGwuY2g+PiB3cm90 ZToNCg0KaGkgWmFoZWQsIEFhcm9uLCBhbGwsDQoNCg0KT24gMjcgRmViIDIwMTgsIGF0IDE4OjI4 LCBUb21teSBQYXVseSA8dHBhdWx5QGFwcGxlLmNvbTxtYWlsdG86dHBhdWx5QGFwcGxlLmNvbT4+ IHdyb3RlOg0KDQpIaSBaYWhlZCAmIEFhcm9uLA0KDQpXZeKAmXZlIHBvc3RlZCB0aGUgZmlyc3Qg b2YgdGhyZWUgbmV3IGRvY3VtZW50cyBwcm9wb3NlZCBmb3IgbWlsZXN0b25lIDMsICJBbiBBcmNo aXRlY3R1cmUgZm9yIFRyYW5zcG9ydCBTZXJ2aWNlc+KAnSAocGxlYXNlIGdvIHJlYWQgaXQsIGV2 ZXJ5b25lISk6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBhdWx5 LXRhcHMtYXJjaA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhdWx5LXRhcHMt YXJjaC0wMA0KDQpUaGUgQVBJIGFuZCBJbXBsZW1lbnRhdGlvbiBkb2N1bWVudHMgYXJlIGZvcnRo Y29taW5nLCBhbmQgd2lsbCBiZSBwb3N0ZWQgYmVmb3JlIHRoZSBzdWJtaXNzaW9uIGRlYWRsaW5l Lg0KDQpBbmQgbm93IHdlIGhhdmUgcG9zdGVkIHRoZSBzZWNvbmQgZG9jdW1lbnQgKHBsZWFzZSBn byByZWFkIGl0LCBldmVyeW9uZSEpOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC10cmFtbWVsbC10YXBzLWludGVyZmFjZS4NCg0KVGhlIGRvY3VtZW50IGNvbWJpbmVz IGNvbmNlcHRzIG9mIHRoZSBQb3N0IFNvY2tldHMsIE5FQVQsIGFuZCBTb2NrZXQgSW50ZW50cyBh cHByb2FjaGVzIHRvIHByb3ZpZGUgYW4gaW50ZXJmYWNlIHRvIHRoZSBhcmNoaXRlY3R1cmUgaW4g dGhlIGZpcnN0IGRvY3VtZW50IGF0IHRoZSBsZXZlbCBvZiBhIGxhbmd1YWdlLWluZGVwZW5kZW50 LCBhYnN0cmFjdCBhc3luY2hyb25vdXMgaW50ZXJmYWNlIGRlZmluaXRpb24uDQoNCldlJ2QgbGlr ZSAxMC0xNSBtaW51dGVzIGFmdGVyIFRvbW15IHRvIGJ1aWxkIG9uIHRoZSBhcmNoaXRlY3R1cmUg YW5kIGludHJvZHVjZSB0aGUgY29uY2VwdHMuIElTVE0gKHRob3VnaCBJIGhhdmVuJ3QgZGlzY3Vz c2VkIHdpdGggVG9tbXksIEFubmEsIGFuZCBNaWNoZWFsLCB0aGUgb3RoZXIgZWRpdG9ycykgdGhh dCB0aGUgZGlzY3Vzc2lvbiB0aW1lIGZvciB0aGVzZSBkb2N1bWVudHMgY2FuIHByb2JhYmx5IGJl IGNvbWJpbmVkLg0KDQpEZWZpbml0ZWx5LCBJIHNheSwgYXMgb25lIG9mIHRoZW0hDQoNCkNoZWVy cywNCk1pY2hhZWwNCg0K --_000_B4160F527C71494EB46F3F8B4A6FAE15ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <43E19ACFE9972C4398F54DD4EBF8B9A0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJn aW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VmVyeSBnb29kLiBXZSBjYW4gYWxsb2NhdGUgYSBn b29kIHBvcnRpb24gb2YgdGltZSBmb3IgdGhpcyBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CUjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5a YWhlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5PbiAyMDE4LTAzLTAxLCAxNjowNSwgJnF1b3Q7TWljaGFlbCBXZWx6bCZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pY2hhd2VAaWZpLnVpby5ubyI+bWljaGF3ZUBpZmkudWlv Lm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBNYXIgMSwgMjAx OCwgYXQgMzo1NCBQTSwgQnJpYW4gVHJhbW1lbGwgKElFVEYpICZsdDs8YSBocmVmPSJtYWlsdG86 aWV0ZkB0cmFtbWVsbC5jaCI+aWV0ZkB0cmFtbWVsbC5jaDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5oaSBaYWhlZCwg QWFyb24sIGFsbCw8YnI+DQo8YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n OjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDI3IEZl YiAyMDE4LCBhdCAxODoyOCwgVG9tbXkgUGF1bHkgJmx0OzxhIGhyZWY9Im1haWx0bzp0cGF1bHlA YXBwbGUuY29tIj50cGF1bHlAYXBwbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KSGkg WmFoZWQgJmFtcDsgQWFyb24sPGJyPg0KPGJyPg0KV2XigJl2ZSBwb3N0ZWQgdGhlIGZpcnN0IG9m IHRocmVlIG5ldyBkb2N1bWVudHMgcHJvcG9zZWQgZm9yIG1pbGVzdG9uZSAzLCAmcXVvdDtBbiBB cmNoaXRlY3R1cmUgZm9yIFRyYW5zcG9ydCBTZXJ2aWNlc+KAnSAocGxlYXNlIGdvIHJlYWQgaXQs IGV2ZXJ5b25lISk6PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtcGF1bHktdGFwcy1hcmNoIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1wYXVseS10YXBzLWFyY2g8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhdWx5LXRhcHMtYXJjaC0wMCI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhdWx5LXRhcHMtYXJjaC0wMDwvYT48YnI+DQo8YnI+DQpU aGUgQVBJIGFuZCBJbXBsZW1lbnRhdGlvbiBkb2N1bWVudHMgYXJlIGZvcnRoY29taW5nLCBhbmQg d2lsbCBiZSBwb3N0ZWQgYmVmb3JlIHRoZSBzdWJtaXNzaW9uIGRlYWRsaW5lLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkFuZCBub3cgd2UgaGF2 ZSBwb3N0ZWQgdGhlIHNlY29uZCBkb2N1bWVudCAocGxlYXNlIGdvIHJlYWQgaXQsIGV2ZXJ5b25l ISk6PGJyPg0KPGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXRyYW1tZWxsLXRhcHMtaW50ZXJmYWNlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10cmFtbWVsbC10YXBzLWludGVy ZmFjZTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Ljxicj4NCjxicj4NClRoZSBkb2N1bWVu dCBjb21iaW5lcyBjb25jZXB0cyBvZiB0aGUgUG9zdCBTb2NrZXRzLCBORUFULCBhbmQgU29ja2V0 IEludGVudHMgYXBwcm9hY2hlcyB0byBwcm92aWRlIGFuIGludGVyZmFjZSB0byB0aGUgYXJjaGl0 ZWN0dXJlIGluIHRoZSBmaXJzdCBkb2N1bWVudCBhdCB0aGUgbGV2ZWwgb2YgYSBsYW5ndWFnZS1p bmRlcGVuZGVudCwgYWJzdHJhY3QgYXN5bmNocm9ub3VzIGludGVyZmFjZSBkZWZpbml0aW9uLjxi cj4NCjxicj4NCldlJ2QgbGlrZSAxMC0xNSBtaW51dGVzIGFmdGVyIFRvbW15IHRvIGJ1aWxkIG9u IHRoZSBhcmNoaXRlY3R1cmUgYW5kIGludHJvZHVjZSB0aGUgY29uY2VwdHMuIElTVE0gKHRob3Vn aCBJIGhhdmVuJ3QgZGlzY3Vzc2VkIHdpdGggVG9tbXksIEFubmEsIGFuZCBNaWNoZWFsLCB0aGUg b3RoZXIgZWRpdG9ycykgdGhhdCB0aGUgZGlzY3Vzc2lvbiB0aW1lIGZvciB0aGVzZSBkb2N1bWVu dHMgY2FuIHByb2JhYmx5IGJlIGNvbWJpbmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5EZWZpbml0ZWx5LCBJIHNheSwg YXMgb25lIG9mIHRoZW0hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk1pY2hhZWw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_B4160F527C71494EB46F3F8B4A6FAE15ericssoncom_-- From nobody Mon Mar 5 05:18: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 09CFE1270AE for ; Mon, 5 Mar 2018 05:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=E6xHCHPE; dkim=pass (1024-bit key) header.d=ericsson.com header.b=eNJBUpCc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvoN7VDvnM5M for ; Mon, 5 Mar 2018 05:18:25 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383BD120454 for ; Mon, 5 Mar 2018 05:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520255903; 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=NGpKP2362SeHNAcDNCgAh7c9HMtJdBMUV98MndxkqIw=; b=E6xHCHPEilLUi4vQkHb2aZ2ISygu321DxJJqUDOIx06+SF8AhZJBqa8dhzTZPS7s PLhtNSkaLD/zLSJz8rprSTtv/gcrqk+8HR6n2OG/3EBCfpGpt57IhaZxScOCKDZj P7anQPCRRoUstlq1Bl4LV4uMaHZ1+QDtNC9FEECtOMM=; X-AuditID: c1b4fb25-06bff70000002d5f-56-5a9d439f4803 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A3.B0.11615.F934D9A5; Mon, 5 Mar 2018 14:18:23 +0100 (CET) Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESSHC014.ericsson.se (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 5 Mar 2018 14:18:22 +0100 Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Mon, 5 Mar 2018 14:18:22 +0100 Received: from EUR02-AM5-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.1034.26 via Frontend Transport; Mon, 5 Mar 2018 14:18:22 +0100 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; bh=NGpKP2362SeHNAcDNCgAh7c9HMtJdBMUV98MndxkqIw=; b=eNJBUpCc3SCeH1Q78e1i1aU8NVCfY+OD3DKttXkW+kSdKBnuw9GuejViA5gTsU6pbmINyE1JHxi5Qq5W6Ry11mO99w/9UDa7yMZKCwyB9k/UKvoXfYTyrbFCPBdySJZTu1pFKcbJAdzqbVYLMOMDNBlKNlSGU4q17bdvnwHuL68= Received: from HE1PR07MB1660.eurprd07.prod.outlook.com (10.166.124.138) by HE1PR07MB3500.eurprd07.prod.outlook.com (10.170.247.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.6; Mon, 5 Mar 2018 13:18:21 +0000 Received: from HE1PR07MB1660.eurprd07.prod.outlook.com ([fe80::4cec:56ea:a3ae:b080]) by HE1PR07MB1660.eurprd07.prod.outlook.com ([fe80::4cec:56ea:a3ae:b080%5]) with mapi id 15.20.0567.011; Mon, 5 Mar 2018 13:18:21 +0000 From: Zaheduzzaman Sarker To: "taps@ietf.org" Thread-Topic: Draft agenda for TAPS session at IETF101 Thread-Index: AQHTtIRudUK0JND2WUGGUvUz9GJTyg== Date: Mon, 5 Mar 2018 13:18:21 +0000 Message-ID: <94369D78-64F0-4074-84FC-511C05DE21E9@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.29.0.171205 x-originating-ip: [192.176.1.82] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3500; 7:NnIMJFvg3NybByJ2AlRUWesfT0hx6vSZAUMIJDq+0BWVdyJ2kzpyGlzghKJkgBR/LyhomVtUO/5Q9A8xYpp4VIYd1izwflN95kpCe6PYMHSokTEfNU2L6htbu87dcqyEh1A5JWHvcYXbETCWKr4edXBpJtzB0HFTjV1XS9KsUt+58gH4kigrF9I7Wwh4zdum8vjWHVSJzxbs9upM/Gn2UipH6XlFFvD9RgZzs2ytejkh0jA5PFIcOoHt8xxRXXwp x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 39bf3df4-f0b3-48e9-14eb-08d5829b9185 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:HE1PR07MB3500; x-ms-traffictypediagnostic: HE1PR07MB3500: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(3002001)(6041288)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:HE1PR07MB3500; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3500; x-forefront-prvs: 06022AA85F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(39860400002)(39380400002)(366004)(53754006)(199004)(189003)(2351001)(6116002)(5640700003)(8676002)(1730700003)(81156014)(66066001)(68736007)(6486002)(478600001)(82746002)(6436002)(53936002)(106356001)(3846002)(236005)(5660300001)(316002)(3660700001)(81166006)(966005)(2906002)(6306002)(58126008)(54896002)(2900100001)(6512007)(105586002)(7736002)(26005)(102836004)(6506007)(97736004)(186003)(25786009)(14454004)(5250100002)(8936002)(558084003)(99286004)(86362001)(2501003)(33656002)(6916009)(606006)(36756003)(83716003)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3500; H:HE1PR07MB1660.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: NOnsEyAkc1yZrZAG1Iz1IIT7OJ17SLUqnrwPQ8sb6mmLzaserWva3aafnrP1vWqN0U/wzK+BbIwll4xDrL9L8S/gcYBcAu0P18bWWhvhIpGXaBNTwf2kFNU1kzZI56WN7rDx3c8tgPLqqGpY/dLGNO4UqEJZxAcMfuyoV8Nv+fKy0nyvQOxvDP66WRSCHjq5rZjzLPnwmtnipuRZcGdDluCC1Dbi/s7GgfeCFKJmCmGg1UrRKM30zd+hoELtdIsxjg79sbbwtnlveTe3oxE7+5uNq7hjBfSGaRJoHOAEu2XvFeb/epl9B4Ym2SGPxDMo2/xjU/TOIMy4orRDVU4mcw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_94369D7864F0407484FC511C05DE21E9ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 39bf3df4-f0b3-48e9-14eb-08d5829b9185 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2018 13:18:21.5022 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3500 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+c45246r1dfUfDNFWxdNcNOKLiBpmCJEZgUVM7ClBzWvbSbZ H2XiLYdMzVEuL8mmpCimSVoJkqucpZgaoRmYaLGaiaR5yay2fQb+9zzP+zvP975wWFr8gOfK xienccpkRaKEL2TKzrUF+FYFV8j99NOSgx/PB6Ewg2GJikByYUAMlxifzillhy8I40wveqjU ac+rvYV5vExk8ShADizgfWCuXEQFSMiKsRHB7fFpPjGPEHw2NfGImUdQ3W9miDFQ8OzvisBm GPyDguF37asFJRR0j5j4tmYxHkcw8mpdAWJZPg6ACX24LXbC22Gos9mOOGJ/6NOM0iTfD3MP q3lESyG/ssTOMHgHaPI19lyEA0FtVNs1wpth4XUDZdM0doGsuToeOQiDoaOfJtoZvk78sefO 1k5z73uBbR3AnmD8JiKIOwxWqe3rA26lYHbFhMjAF2a02tWe42Bs0vEJZEIwqaljyMAH7mZP UWShaND+zOGTPAEG+iop8lgkNNafIN/W0GDRjwkI4wZ531voIiTVrbmB6Gj4ra+mdfabN0FP 2SSjs1bReDc0PZURZBuUqscFRHtDTnnFqg6DmrE79FrmPmLrkbOKU11Mit2zV8op46NVqpRk aTKX1oKs/8/z1uWd7Who6kgXwiySrBdtkFXIxTxFuiojqQsBS0ucRK5brJEoRpFxjVOmRCmv JHKqLrSVZSQuonLHPLkYxyrSuASOS+WU/6cU6+CaiUKzBFGo41K2Nsk5UlQ8+9b9pF9bY1hc aveN0UAXwUbqdO+uEFOwJe5J9ql7M8X8Ks/LRr33oNEc1OlVu9Qx/7hI2vjLoDA5xMoaLMPy 5kMVhWfKal0cX77x8g9pBxmzOBjxIVd4Ew+Ibx39snysdMHcE557YPT6J3XMWQ+3nFAJo4pT +PvQSpXiH4cdC3Y7AwAA Archived-At: Subject: [Taps] Draft agenda for TAPS session at IETF101 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 05 Mar 2018 13:18:28 -0000 --_000_94369D7864F0407484FC511C05DE21E9ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpBIGRyYWZ0IGFnZW5kYSBmb3IgVEFQUyBzZXNzaW9uIGhhcyBiZWVuIHVwbG9h ZGVkIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDEvbWF0ZXJpYWxzL2Fn ZW5kYS0xMDEtdGFwcy50eHQNCg0KSGF2ZSBhIGxvb2sgYW5kIHN1Z2dlc3QgY2hhbmdlcywgaWYg YW55Lg0KDQpCUg0KDQpaYWhlZA0K --_000_94369D7864F0407484FC511C05DE21E9ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <007FC48C7EE66B49BF63BD3A1653FDB3@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1 cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2 M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpIGFsbCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkEgZHJhZnQgYWdlbmRhIGZv ciBUQVBTIHNlc3Npb24gaGFzIGJlZW4gdXBsb2FkZWQNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDEvbWF0ZXJpYWxzL2FnZW5kYS0xMDEtdGFwcy50eHQi Pg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMS9tYXRlcmlhbHMvYWdl bmRhLTEwMS10YXBzLnR4dDwvYT4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5IYXZlIGEgbG9vayBhbmQgc3VnZ2VzdCBjaGFuZ2VzLCBpZiBhbnkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CUjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+WmFoZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_94369D7864F0407484FC511C05DE21E9ericssoncom_-- From nobody Mon Mar 5 11:14: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 BFCF312DA6B for ; Mon, 5 Mar 2018 11:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 6bXhhZy_sPKX for ; Mon, 5 Mar 2018 11:14:08 -0800 (PST) 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 6EE7912D779 for ; Mon, 5 Mar 2018 11:14:08 -0800 (PST) From: Anna Brunstrom To: "taps@ietf.org" References: <1055e2d0-50da-08c7-28ac-4a4df9f11f13@kau.se> Message-ID: <98d0c72b-2cc6-a768-64b8-8fe42e59d61d@kau.se> Date: Mon, 5 Mar 2018 20:14:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1055e2d0-50da-08c7-28ac-4a4df9f11f13@kau.se> Content-Type: multipart/alternative; boundary="------------1AE8895D41C403D1CF72866A" Content-Language: en-US X-ClientProxiedBy: Exch-A3.personal.kau (130.243.19.84) To Exch-A2.personal.kau (130.243.19.83) Archived-At: Subject: Re: [Taps] [TAPS] Call for agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 05 Mar 2018 19:14:12 -0000 --------------1AE8895D41C403D1CF72866A Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Zahed, Aaron, all, On 2018-03-01 15:54, Brian Trammell wrote: > hi Zahed, Aaron, all, > > > On 27 Feb 2018, at 18:28, Tommy Pauly ; wrote: > > > > Hi Zahed & Aaron, > > > > We’ve posted the first of three new documents proposed for milestone 3, "An Architecture for Transport Services” (please go read it, everyone!): > > > > https://datatracker.ietf.org/doc/draft-pauly-taps-arch > > https://tools.ietf.org/html/draft-pauly-taps-arch-00 > > > > The API and Implementation documents are forthcoming, and will be posted before the submission deadline. > > And now we have posted the second document (please go read it, everyone!): Now also the Implementation document is posted (please have a look at that one as well!): https://datatracker.ietf.org/doc/draft-brunstrom-taps-impl/ This document provides implementation guidance on how to build a system that provides a Transport Services API as described in the API document. If we could have 10-15 minutes to also introduce implementation aspects after the API presentation this would be great. Discussion for all three documents go together. Cheers, Anna > https://datatracker.ietf.org/doc/draft-trammell-taps-interface. > > The document combines concepts of the Post Sockets, NEAT, and Socket Intents approaches to provide an interface to the architecture in the first document at the level of a language-independent, abstract asynchronous interface definition. > > We'd like 10-15 minutes after Tommy to build on the architecture and introduce the concepts. ISTM (though I haven't discussed with Tommy, Anna, and Micheal, the other editors) that the discussion time for these documents can probably be combined. > > Cheers, > > Brian > > > I’d like a slot to go over the Architecture document and approach itself. A 15/20-minute talk with flexible discussion time would likely be good. I imagine we’d also want slots to discuss the API and Implementation documents to present them to the whole group as well. > > > > Thanks, > > Tommy > > > >> On Feb 27, 2018, at 1:13 AM, Zaheduzzaman Sarker > ; wrote: > >> > >> Hi TAPS, > >> > >> Your chairs are planning for the IETF 101 London Session. Please send your proposal(s) for agenda item and also mention what points you would like to discuss during the IETF101 meeting during your timeslot. > >> > >> BR > >> > >> Zahed & Aaron > >> _______________________________________________ > >> 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 > --------------1AE8895D41C403D1CF72866A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi Zahed, Aaron, all,

On 2018-03-01 15:54, Brian Trammell wrote:
hi Zahed, Aaron, all,

> On 27 Feb 2018, at 18:28, Tommy Pauly <tpauly@apple.com>; wrote:
> 
> Hi Zahed & Aaron,
> 
> We’ve posted the first of three new documents proposed for milestone 3, "An Architecture for Transport Services” (please go read it, everyone!):
> 
> https://datatracker.ietf.org/doc/draft-pauly-taps-arch
> https://tools.ietf.org/html/draft-pauly-taps-arch-00
> 
> The API and Implementation documents are forthcoming, and will be posted before the submission deadline.

And now we have posted the second document (please go read it, everyone!):

Now also the Implementation document is posted (please have a look at that one as well!):

https://datatracker.ietf.org/doc/draft-brunstrom-taps-impl/

This document provides implementation guidance on how to build a system that provides a Transport Services API as described in the API document.

If we could have 10-15 minutes to also introduce implementation aspects after the API presentation this would be great. Discussion for all three documents go together.

Cheers,
Anna

https://datatracker.ietf.org/doc/draft-trammell-taps-interface.

The document combines concepts of the Post Sockets, NEAT, and Socket Intents approaches to provide an interface to the architecture in the first document at the level of a language-independent, abstract asynchronous interface definition.

We'd like 10-15 minutes after Tommy to build on the architecture and introduce the concepts. ISTM (though I haven't discussed with Tommy, Anna, and Micheal, the other editors) that the discussion time for these documents can probably be combined.

Cheers,

Brian

> I’d like a slot to go over the Architecture document and approach itself. A 15/20-minute talk with flexible discussion time would likely be good. I imagine we’d also want slots to discuss the API and Implementation documents to present them to the whole group as well.
> 
> Thanks,
> Tommy
> 
>> On Feb 27, 2018, at 1:13 AM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>; wrote:
>> 
>> Hi TAPS,
>> 
>> Your chairs are planning for the IETF 101 London Session. Please send your proposal(s) for agenda item and also mention what points you would like to discuss during the IETF101 meeting during your timeslot.
>> 
>> BR
>> 
>> Zahed & Aaron
>> _______________________________________________
>> 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


--------------1AE8895D41C403D1CF72866A-- From nobody Mon Mar 5 11:28: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 F36C812D7F9 for ; Mon, 5 Mar 2018 11:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_RP_MATCHES_RCVD=-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 98UkoTuuZJ1j for ; Mon, 5 Mar 2018 11:28:24 -0800 (PST) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 700C812D7F6 for ; Mon, 5 Mar 2018 11:28:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1520278103; x=2384191703; 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=3l7IPm4S/Up9l/bwliy101nH6yp7HBNm5PFb5Z85bqU=; b=tZFIYwHCXOc0OvTasQLon3bsi2vpuGrp5B77WXB8JhLDniqZycUzoh1pPbNm1oFS lzmgCXGiZm4pu4WoVP3TdojV2aNk4C0oCjaTOO+2rVCC/au0qp7k4vldJmuyVjfi GbdIiK5RKlfjfzTme/rUeNwy50xJaiKVKpLkq6DpgKPJRFDXO3Sf3KYIj5O6ooBO Dn3P9vTPk3dLiOm4oYP9xbyiunCVch7vQjEWp1c5I4O+TzdTmE5/6N60WEnJtlni n2idd9WfYR9GrKWPuEVgRv9Uvxch4G7d2wxffxZQROwf45VtTxEPY1gF1B8DuxiN b4x+L17M8LIDZ9IQIFJL6Q==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 14.40.11907.75A9D9A5; Mon, 5 Mar 2018 11:28:23 -0800 (PST) X-AuditID: 11ab0216-e0dff70000002e83-c6-5a9d9a56e972 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay8.apple.com (Apple SCV relay) with SMTP id 62.65.10701.65A9D9A5; Mon, 5 Mar 2018 11:28:22 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_1HNe8/3osgArKd/exiniJQ)" Received: from [17.230.0.178] (unknown [17.230.0.178]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P54006QEU3A4160@nwk-mmpp-sz11.apple.com>; Mon, 05 Mar 2018 11:28:22 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Date: Mon, 05 Mar 2018 11:28:21 -0800 References: <1055e2d0-50da-08c7-28ac-4a4df9f11f13@kau.se> <98d0c72b-2cc6-a768-64b8-8fe42e59d61d@kau.se> To: Anna Brunstrom , "taps@ietf.org" , Aaron Falk , Zaheduzzaman Sarker In-reply-to: <98d0c72b-2cc6-a768-64b8-8fe42e59d61d@kau.se> Message-id: <8C1C552C-B4A7-43D2-93DE-AD78E75B71DF@apple.com> X-Mailer: Apple Mail (2.3458) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FCYphs+a26UwflTqhZtv6exWpz4cZnZ 4k6MxZFT75gdWDx+fb3K5rFz1l12jyVLfjJ5/L3QyhbAEsVlk5Kak1mWWqRvl8CV0Td5C3NB Q3bFr5+rmRsYl0V3MXJwSAiYSFw/rNXFyMUhJLCWSaKzaTZLFyMnWHzGnjtsEIlDjBJfFk1i BEnwCghK/Jh8D6yIWSBMYu3Xs4wQRf1MEmsPfWIFmSosICGxeU8iSA2bgIrE8W8bmEFsYQED iZU7boLZLAKqEg1HprKC2EICmRKvN7cxg8wREVjFKLH/5Xx2kASngJXE6u7LLBCLbYAWX2OE uE5WYuXsu6wgDRICa9gkZm3pZZzAKDgLyYGzkBw4C+gmZgF1iSlTciHC2hJP3l1ghbDVJBb+ XsSELL6AkW0Vo3BuYmaObmaekZFeYkFBTqpecn7uJkZQZKxmEtvBeO+14SFGAQ5GJR7eDR5z o4RYE8uKK3MPMUpzsCiJ81573hglJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbFwz6mwecad z029Nrw/zd9785lTVMnVd3vXTFLwOJTtlcw/pyVbav6MSY8lc2r8E4Q+drSsaLQq2rlGoyWl tnuy88mYdW3tl20l+3kPCTgVaacrzzX2Ph3vfstz5jTHKJ5alucPOTZt2Prcct6MVcodefNU 2byEDkvmXcrbnqP/Xt1t/pNv6kosxRmJhlrMRcWJAE2WS+VtAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUi2FA8Wzds1twog65JShZtv6exWpz4cZnZ 4k6MxZFT75gdWDx+fb3K5rFz1l12jyVLfjJ5/L3QyhbAEsVlk5Kak1mWWqRvl8CV0Td5C3NB Q3bFr5+rmRsYl0V3MXJySAiYSMzYc4eti5GLQ0jgEKPEl0WTGEESvAKCEj8m32MBsZkFwiTW fj3LCFHUzySx9tAn1i5GDg5hAQmJzXsSQWrYBFQkjn/bwAxiCwsYSKzccRPMZhFQlWg4MpUV xBYSyJR4vbmNGWSOiMAqRon9L+ezgyQ4BawkVndfZoFYbAO0+BojxHWyEitn32WdwMg3C8lN s5DcNAvoDGYBdYkpU3IhwtoST95dYIWw1SQW/l7EhCy+gJFtFaNAUWpOYqWFXmJBQU6qXnJ+ 7iZGcCAXpu1gbFpudYhRgINRiYeXw3tulBBrYllxZS4wYDiYlUR4rzcAhXhTEiurUovy44tK c1KLDzFKc7AoifM2/5wZJSSQnliSmp2aWpBaBJNl4uCUamBkiIrYulR/yYu5GsbfWj9KPWXZ fZ4hU0DzyavAdd2tkW22hTf+vpTNX6PDkXvGfw7nSYnMc3WT50/QvFvhfDRA+k/c7fSlcjPP 69heMKmd+nGG5D+fLxu8106OTHovEMv95XlLlnYnzwfJ9tvRFbZ/Pvo0ZQVwPTtrtv2NVNjF xWe9fK6riUcrsRRnJBpqMRcVJwIAkvHBr2ACAAA= Archived-At: Subject: Re: [Taps] [TAPS] Call for agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 05 Mar 2018 19:28:27 -0000 --Boundary_(ID_1HNe8/3osgArKd/exiniJQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Mar 5, 2018, at 11:14 AM, Anna Brunstrom = wrote: >=20 > Hi Zahed, Aaron, all, > On 2018-03-01 15:54, Brian Trammell wrote: >> hi Zahed, Aaron, all, >>=20 >> > On 27 Feb 2018, at 18:28, Tommy Pauly = ; wrote: >> >=20 >> > Hi Zahed & Aaron, >> >=20 >> > We=E2=80=99ve posted the first of three new documents proposed for = milestone 3, "An Architecture for Transport Services=E2=80=9D (please go = read it, everyone!): >> >=20 >> > https://datatracker.ietf.org/doc/draft-pauly-taps-arch = >> > https://tools.ietf.org/html/draft-pauly-taps-arch-00 = >> >=20 >> > The API and Implementation documents are forthcoming, and will be = posted before the submission deadline. >>=20 >> And now we have posted the second document (please go read it, = everyone!): >=20 > Now also the Implementation document is posted (please have a look at = that one as well!): >=20 > https://datatracker.ietf.org/doc/draft-brunstrom-taps-impl/ = >=20 > This document provides implementation guidance on how to build a = system that provides a Transport Services API as described in the API = document. >=20 > If we could have 10-15 minutes to also introduce implementation = aspects after the API presentation this would be great. Discussion for = all three documents go together. + 1 to adding implementation to the list for the three new drafts. I think we can reduce the time for the transport security survey a bit = to make room! ~15 minutes for that. Best, Tommy >=20 > Cheers, > Anna >=20 >> https://datatracker.ietf.org/doc/draft-trammell-taps-interface = . >>=20 >> The document combines concepts of the Post Sockets, NEAT, and Socket = Intents approaches to provide an interface to the architecture in the = first document at the level of a language-independent, abstract = asynchronous interface definition. >>=20 >> We'd like 10-15 minutes after Tommy to build on the architecture and = introduce the concepts. ISTM (though I haven't discussed with Tommy, = Anna, and Micheal, the other editors) that the discussion time for these = documents can probably be combined. >>=20 >> Cheers, >>=20 >> Brian >>=20 >> > I=E2=80=99d like a slot to go over the Architecture document and = approach itself. A 15/20-minute talk with flexible discussion time would = likely be good. I imagine we=E2=80=99d also want slots to discuss the = API and Implementation documents to present them to the whole group as = well. >> >=20 >> > Thanks, >> > Tommy >> >=20 >> >> On Feb 27, 2018, at 1:13 AM, Zaheduzzaman Sarker = = ; wrote: >> >>=20 >> >> Hi TAPS, >> >>=20 >> >> Your chairs are planning for the IETF 101 London Session. Please = send your proposal(s) for agenda item and also mention what points you = would like to discuss during the IETF101 meeting during your timeslot. >> >>=20 >> >> BR >> >>=20 >> >> Zahed & Aaron >> >> _______________________________________________ >> >> Taps mailing list >> >> Taps@ietf.org >> >> https://www.ietf.org/mailman/listinfo/taps = >> >=20 >> > _______________________________________________ >> > Taps mailing list >> > Taps@ietf.org >> > https://www.ietf.org/mailman/listinfo/taps = >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_1HNe8/3osgArKd/exiniJQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On Mar 5, 2018, at 11:14 AM, Anna Brunstrom <anna.brunstrom@kau.se> wrote:

=20 =20

Hi = Zahed, Aaron, all,

On 2018-03-01 15:54, Brian Trammell wrote:
hi Zahed, Aaron, all,

> On 27 Feb 2018, at 18:28, Tommy Pauly <tpauly@apple.com>; wrote:
>=20
> Hi Zahed & Aaron,
>=20
> We=E2=80=99ve posted the first of three new documents proposed for =
milestone 3, "An Architecture for Transport Services=E2=80=9D (please go =
read it, everyone!):
>=20
> https://datatracker.ietf.org/doc/draft-pauly-taps-arch
> https://tools.ietf.org/html/draft-pauly-taps-arch-00
>=20
> The API and Implementation documents are forthcoming, and will be =
posted before the submission deadline.

And now we have posted the second document (please go read it, =
everyone!):

Now also the Implementation document is posted (please have a look at that one as well!):

https://datatracker.ietf.org/doc/draft-brunstrom-taps-impl/=

This document provides implementation guidance on how to build a system that provides a Transport Services API as described in the API document.

If we could have 10-15 minutes to also introduce implementation aspects after the API presentation this would be great. Discussion for all three documents go together.

+ 1 = to adding implementation to the list for the three new = drafts.

I think we can reduce the = time for the transport security survey a bit to make room! ~15 minutes = for that.

Best,
Tommy


Cheers,
Anna

https://datatracker.ietf.org/doc/draft-trammell-taps-interface<=
/a>.

The document combines concepts of the Post Sockets, NEAT, and Socket =
Intents approaches to provide an interface to the architecture in the =
first document at the level of a language-independent, abstract =
asynchronous interface definition.

We'd like 10-15 minutes after Tommy to build on the architecture and =
introduce the concepts. ISTM (though I haven't discussed with Tommy, =
Anna, and Micheal, the other editors) that the discussion time for these =
documents can probably be combined.

Cheers,

Brian

> I=E2=80=99d like a slot to go over the Architecture document and =
approach itself. A 15/20-minute talk with flexible discussion time would =
likely be good. I imagine we=E2=80=99d also want slots to discuss the =
API and Implementation documents to present them to the whole group as =
well.
>=20
> Thanks,
> Tommy
>=20
>> On Feb 27, 2018, at 1:13 AM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>; wrote:
>>=20
>> Hi TAPS,
>>=20
>> Your chairs are planning for the IETF 101 London Session. =
Please send your proposal(s) for agenda item and also mention what =
points you would like to discuss during the IETF101 meeting during your =
timeslot.
>>=20
>> BR
>>=20
>> Zahed & Aaron
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>=20
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps


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

= --Boundary_(ID_1HNe8/3osgArKd/exiniJQ)-- From nobody Mon Mar 5 11:35: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 1B4F712D7F6 for ; Mon, 5 Mar 2018 11:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=N25Kk7EY; dkim=pass (1024-bit key) header.d=ericsson.com header.b=aASRwVUR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8nNVnbA8WZG for ; Mon, 5 Mar 2018 11:35:54 -0800 (PST) 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 06B7012D7E4 for ; Mon, 5 Mar 2018 11:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520278552; 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=wsQf5zK5X5KIo5QR7gJkaa21q1yqIguJ7XZB2NZHjg8=; b=N25Kk7EYV8Cnm5rhpSLH2K8pVPHWwviiV1iu6eWGcy9Xwva9KgcJeAR7jGYBkFZU O7SFYfrS2VYIb/YFUQjQ0ReQsbA19O6cSNjyc1Q/YGzZGBKW1yOXnBwTawrQV7Pe y06xDAX6APs3hHXQEGHJpLYD0BYMdm67V8HfkzfmVeU=; X-AuditID: c1b4fb30-3b1ff70000004778-cf-5a9d9c18d98a Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 93.99.18296.81C9D9A5; Mon, 5 Mar 2018 20:35:52 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSHC008.ericsson.se (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 5 Mar 2018 20:35:51 +0100 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Mon, 5 Mar 2018 20:35:51 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via Frontend Transport; Mon, 5 Mar 2018 20:35:51 +0100 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; bh=wsQf5zK5X5KIo5QR7gJkaa21q1yqIguJ7XZB2NZHjg8=; b=aASRwVUR+RY+3VNlrEJKKHKxCSD1GQ1RuHDxIfIPD6ZAIY0itT2USg2UzpRPfDMu/BnyBgj5vpU8P40m54DMonwQjysBygpMOBBKZKHQmiFWgl5phf/C935D4cbH9SIBCu0gacnj6CK7/+dBTMUjGcNwJaQys0JGb1kJI1lBciI= Received: from HE1PR07MB1660.eurprd07.prod.outlook.com (10.166.124.138) by HE1PR07MB1065.eurprd07.prod.outlook.com (10.163.177.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.6; Mon, 5 Mar 2018 19:35:50 +0000 Received: from HE1PR07MB1660.eurprd07.prod.outlook.com ([fe80::4cec:56ea:a3ae:b080]) by HE1PR07MB1660.eurprd07.prod.outlook.com ([fe80::4cec:56ea:a3ae:b080%5]) with mapi id 15.20.0567.011; Mon, 5 Mar 2018 19:35:50 +0000 From: Zaheduzzaman Sarker To: "taps@ietf.org" Thread-Topic: [Taps] Draft agenda for TAPS session at IETF101 Thread-Index: AQHTtLkqukQmh7QpDkC4MTAPoFDabA== Date: Mon, 5 Mar 2018 19:35:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.29.0.171205 authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-originating-ip: [85.238.211.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1065; 7:KbyfUOAjr29wV7xzGp+FyVZ14ed5b2VnB/SHP4JiNOl3A3vBzC6TQcc77vX8lbGH/a7YVu7m+MxHjqqujNq+UT34wYTpJPjkeie1MHvbksB6Ds2x4PirfodmAwW/hVZxJjpZLC9LsbIqbNonS3lqTUFB/Gmw08Dj/n0AfIKe9iCoiFMwUjwRSbTYI3blBxm+zbIPQCFffNDLGAwIbwup5zx+9pAYf4LzjFOMntBS6Kxa76Xdzzg3GZBAmwwi/Ygo x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 203537cd-fa31-49a4-8009-08d582d04d30 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:HE1PR07MB1065; x-ms-traffictypediagnostic: HE1PR07MB1065: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(3231220)(944501244)(52105095)(10201501046)(3002001)(93006095)(93001095)(6041288)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR07MB1065; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1065; x-forefront-prvs: 06022AA85F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(366004)(39380400002)(39860400002)(377424004)(199004)(189003)(53754006)(2351001)(6916009)(8936002)(66066001)(3846002)(9326002)(8676002)(83716003)(1730700003)(81166006)(5660300001)(25786009)(99286004)(2906002)(106356001)(7736002)(33656002)(81156014)(2501003)(3660700001)(316002)(5250100002)(58126008)(6116002)(82746002)(86362001)(3280700002)(478600001)(105586002)(6506007)(186003)(5640700003)(6306002)(54896002)(6512007)(68736007)(53936002)(966005)(36756003)(229853002)(236005)(102836004)(6486002)(6436002)(6246003)(26005)(2900100001)(606006)(14454004)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1065; H:HE1PR07MB1660.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: jQwFsbcSprnRjHMyuJfkdFdSZ324t9g1KzHNszyaDCYOIJBFS8jmBQRyCxpJrp4/FE8J/oeCkxco9WN5eR7s6cLYRQjGI21sqROK4U9owdT9lZRC8BbzyC9FNDGawIuoBC5Ml1OG1zuF0VdWdGoqVTofH4trq1drY1aaCvbxGjgg5RvLPXyyzcic1GIL8C1xtTTMqP3U1+WGJy3EiuCFVNM72KbyyCMiZPCyOpNCshYJVh4tYkM4yNLZDUhIZeuZ29+q+EWIQxvjM2CvI9g0lc+a2laTaha4ztZFCnoheRGxgYU34p6kTLKWQutT2NHdo6iaXNRKLDkq+h7Nsavu0g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_EC4C97B817B54541AF4D36FA9564463Aericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 203537cd-fa31-49a4-8009-08d582d04d30 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2018 19:35:50.0443 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1065 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUyM2K7lq7EnLlRBr+milrciXFg9Fiy5CdT AGMUl01Kak5mWWqRvl0CV8b/4y+ZCrrMK1Z2/GJqYNxv2sXIySEhYCLRunMhaxcjF4eQwGFG iUPHZjNBOJsZJSZdewKV+cYocX3eXyhnCZPE40sr2UEcFoFPTBJPPv9gAxkmJDCJSWLGhFCI qoeMEk/7LjB2MXJwsAnYSDxe7AdSIyKgLHF5/0awemGg8JRN59hBSkQEbCXe/JOEKNGTODNj N1gJi4CKxNN/V8BKeAXsJVq+W4KEGQXEJL6fWsMEYjMLiEs0fVnJCvGOgMSSPeeZIWxRiZeP /4HFRYFGvjhzjR2iN1li6tdWNogaRYnljUeYIGxZiUvzuxkh7C1MEttmuELYuhIfpk5lBjlB QsBXYv9cL5AHJQROMEos+NAENUdLon/mZzaImmyJd99SYMxt+4sgKpYyS9ztzoKwZSTa325i nsCoNwvJAxB2skTn3RZ2EJtXQFDi5MwnLLOAJjELaEqs36UPUaIoMaX7ITuErSHROmculO0h sXvrOWZkNQsYOVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBCadg1t+G+xgfPnc8RCjAAej Eg/vsklzo4RYE8uKK3MPMUpwMCuJ8F5vAArxpiRWVqUW5ccXleakFh9ilOZgURLnPenJGyUk kJ5YkpqdmlqQWgSTZeLglGpgbErmX6lt+Yf/DlPouncOR+snPr4a8XH6MaUf/t9Dj24yUSs0 vdj8aivX17Jjq8OOl3Q/U1r3v1ptq2xfU+OimAROx4Z10hq6F/34+t/LrTxpnC/4u+GU/U+G XdIdf+c/+1r8S/kLywze5GXJdrUTO6+bplXuiLmxaXq0q+6+h33vFuxZ++F4shJLcUaioRZz UXEiAAVFMqY2AwAA Archived-At: Subject: Re: [Taps] Draft agenda for TAPS session at IETF101 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 05 Mar 2018 19:35:56 -0000 --_000_EC4C97B817B54541AF4D36FA9564463Aericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBub3cgdXBkYXRlZCB0aGUgYWdlbmRhLCBoYXZlIGEgbG9vayBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAxL21hdGVyaWFscy9hZ2VuZGEtMTAxLXRh cHMudHh0DQoNCkJSDQoNClphaGVkDQoNCg0KT24gMjAxOC0wMy0wNSwgMTQ6MTksICJUYXBzIG9u IGJlaGFsZiBvZiBaYWhlZHV6emFtYW4gU2Fya2VyIiA8dGFwcy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzp0YXBzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiB6YWhlZHV6emFtYW4uc2Fy a2VyQGVyaWNzc29uLmNvbTxtYWlsdG86emFoZWR1enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb20+ PiB3cm90ZToNCg0KSGkgYWxsLA0KDQpBIGRyYWZ0IGFnZW5kYSBmb3IgVEFQUyBzZXNzaW9uIGhh cyBiZWVuIHVwbG9hZGVkIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDEv bWF0ZXJpYWxzL2FnZW5kYS0xMDEtdGFwcy50eHQNCg0KSGF2ZSBhIGxvb2sgYW5kIHN1Z2dlc3Qg Y2hhbmdlcywgaWYgYW55Lg0KDQpCUg0KDQpaYWhlZA0K --_000_EC4C97B817B54541AF4D36FA9564463Aericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <145ABFF140CFA445903C4FF7D179C8EA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYz QzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGhhdmUgbm93IHVwZGF0ZWQgdGhl IGFnZW5kYSwgaGF2ZSBhIGxvb2sNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvbWVldGluZy8xMDEvbWF0ZXJpYWxzL2FnZW5kYS0xMDEtdGFwcy50eHQiPg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMS9tYXRlcmlhbHMvYWdlbmRhLTEwMS10YXBz LnR4dDwvYT4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CUjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+WmFoZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+T24gMjAxOC0wMy0wNSwgMTQ6MTksICZxdW90O1RhcHMgb24gYmVoYWxmIG9m IFphaGVkdXp6YW1hbiBTYXJrZXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXBzLWJvdW5j ZXNAaWV0Zi5vcmciPnRhcHMtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBo cmVmPSJtYWlsdG86emFoZWR1enphbWFuLnNhcmtlckBlcmljc3Nvbi5jb20iPnphaGVkdXp6YW1h bi5zYXJrZXJAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5IaSBhbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5BIGRyYWZ0IGFnZW5kYSBmb3IgVEFQUyBzZXNzaW9uIGhhcyBiZWVuIHVwbG9hZGVkDQo8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAxL21hdGVyaWFs cy9hZ2VuZGEtMTAxLXRhcHMudHh0Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVl dGluZy8xMDEvbWF0ZXJpYWxzL2FnZW5kYS0xMDEtdGFwcy50eHQ8L2E+IDwvc3Bhbj4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IYXZlIGEgbG9vayBhbmQgc3VnZ2VzdCBjaGFu Z2VzLCBpZiBhbnkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CUjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+WmFoZWQ8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_EC4C97B817B54541AF4D36FA9564463Aericssoncom_-- From nobody Mon Mar 5 12:03:35 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 A1A7A12E043 for ; Mon, 5 Mar 2018 12:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8njXsK7svsa for ; Mon, 5 Mar 2018 12:03:29 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8760112DB6D for ; Mon, 5 Mar 2018 12:03:23 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id y186so6094054ywf.7 for ; Mon, 05 Mar 2018 12:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qj3WcjLOtpAhdeZC2wFLGsqnAPVjkumICrUsapL/E/Q=; b=WPx0QrHTgSanl3Sj+7jW+TLRU932R8MRmmygMvixSZoWgMzbQIb9xfTYhECX1Cskk0 /O2jqXDBYKndqkWq5C4ieGDHYjg2HvI4aSRboCSkgI9B4rI9ympm8L4VrPKu0jZnMyc5 MQ0shpx5t4kovwAwMcLHJyOfGrB6iad3KC8z8G6H7DTkNsenU2fEdgKGCYc7VIxnrgFj Ax03qAc0Nn01Z+TCDxRkrF97ICmb029vuoB99RrKRTa4PchuI0z4s8yHYct134DuM0Ih kEPOhkE3VEtI+Wtkg9sIMNfV7PzVtkju55lu98Unrip7Zc0936xPIali2ZRRVrfJTGNR zg6A== 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:content-transfer-encoding; bh=qj3WcjLOtpAhdeZC2wFLGsqnAPVjkumICrUsapL/E/Q=; b=iC/Mmg3y743mmuxbNMH094GxXN/ZC2tb0juJXkN2XItlsvWpFQVlJjadOqbgQZ6e09 HfhTFYyz80xzXtnDhtcKsVHmBOBVEkuTp9xUtyR+UYH1C/zOfFTFKlU66Nf73QVI81// S8B9KM4c/MrFYFNFEVzgH7k3JqNX1GfPBk1nAPfahBiMlzFaZrf5KHyvTPTKUo8Zi8+g uWDtw4HfaQo4l+/vheo34Npq5h/oAcOwEPZnfXDfy0fNTyUhH2lXTHpvDQtqRRJ9+z6K rBO7PRnhusbsQwMKHG8DdSAPKDGtMqBYFI5CBzaLpORiKkLf2X7I+YOCTt/tb3t1Dgl/ VwMw== X-Gm-Message-State: APf1xPBOs2a1OwLmJpnM7AfWtxC0I2x1iv2JjJ3DIzR31OwPRCYpZ9/M n1trLg8G7DQALZCKIfH44w3pOQWpZ/gX+OGK1U4= X-Google-Smtp-Source: AG47ELtr9NKJ2/t7JB9u2TzCvO70tzpXhR4DdTzpz/HWB4J/Q+9dZgSXJvmdaYiwqdr1hxMixnj/KCCXavuWZUfyCGE= X-Received: by 10.129.208.12 with SMTP id v12mr10071854ywi.304.1520280202532; Mon, 05 Mar 2018 12:03:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.181.81 with HTTP; Mon, 5 Mar 2018 12:03:22 -0800 (PST) In-Reply-To: <8C1C552C-B4A7-43D2-93DE-AD78E75B71DF@apple.com> References: <1055e2d0-50da-08c7-28ac-4a4df9f11f13@kau.se> <98d0c72b-2cc6-a768-64b8-8fe42e59d61d@kau.se> <8C1C552C-B4A7-43D2-93DE-AD78E75B71DF@apple.com> From: Christopher Wood Date: Mon, 5 Mar 2018 12:03:22 -0800 Message-ID: To: Tommy Pauly Cc: Anna Brunstrom , "taps@ietf.org" , Aaron Falk , Zaheduzzaman Sarker Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] [TAPS] Call for agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 05 Mar 2018 20:03:33 -0000 +1 to the reduction in time for the security survey. I think we ought to spend more time on the big three. Best, Chris On Mon, Mar 5, 2018 at 11:28 AM, Tommy Pauly wrote: > > > On Mar 5, 2018, at 11:14 AM, Anna Brunstrom wrote= : > > Hi Zahed, Aaron, all, > > On 2018-03-01 15:54, Brian Trammell wrote: > > hi Zahed, Aaron, all, > >> On 27 Feb 2018, at 18:28, Tommy Pauly ; wrote: >> >> Hi Zahed & Aaron, >> >> We=E2=80=99ve posted the first of three new documents proposed for miles= tone 3, >> "An Architecture for Transport Services=E2=80=9D (please go read it, eve= ryone!): >> >> https://datatracker.ietf.org/doc/draft-pauly-taps-arch >> https://tools.ietf.org/html/draft-pauly-taps-arch-00 >> >> The API and Implementation documents are forthcoming, and will be posted >> before the submission deadline. > > And now we have posted the second document (please go read it, everyone!)= : > > > Now also the Implementation document is posted (please have a look at tha= t > one as well!): > > https://datatracker.ietf.org/doc/draft-brunstrom-taps-impl/ > > This document provides implementation guidance on how to build a system t= hat > provides a Transport Services API as described in the API document. > > If we could have 10-15 minutes to also introduce implementation aspects > after the API presentation this would be great. Discussion for all three > documents go together. > > > + 1 to adding implementation to the list for the three new drafts. > > I think we can reduce the time for the transport security survey a bit to > make room! ~15 minutes for that. > > Best, > Tommy > > > Cheers, > Anna > > https://datatracker.ietf.org/doc/draft-trammell-taps-interface. > > The document combines concepts of the Post Sockets, NEAT, and Socket Inte= nts > approaches to provide an interface to the architecture in the first docum= ent > at the level of a language-independent, abstract asynchronous interface > definition. > > We'd like 10-15 minutes after Tommy to build on the architecture and > introduce the concepts. ISTM (though I haven't discussed with Tommy, Anna= , > and Micheal, the other editors) that the discussion time for these docume= nts > can probably be combined. > > Cheers, > > Brian > >> I=E2=80=99d like a slot to go over the Architecture document and approac= h itself. >> A 15/20-minute talk with flexible discussion time would likely be good. = I >> imagine we=E2=80=99d also want slots to discuss the API and Implementati= on documents >> to present them to the whole group as well. >> >> Thanks, >> Tommy >> >>> On Feb 27, 2018, at 1:13 AM, Zaheduzzaman Sarker >>> ; wrote: >>> >>> Hi TAPS, >>> >>> Your chairs are planning for the IETF 101 London Session. Please send >>> your proposal(s) for agenda item and also mention what points you would= like >>> to discuss during the IETF101 meeting during your timeslot. >>> >>> BR >>> >>> Zahed & Aaron >>> _______________________________________________ >>> 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 > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Tue Mar 6 08:32: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 4D6EA12762F for ; Tue, 6 Mar 2018 08:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FxTtDTpfrUe7 for ; Tue, 6 Mar 2018 08:32:20 -0800 (PST) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (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 CF4A2127076 for ; Tue, 6 Mar 2018 08:32:17 -0800 (PST) To: References: From: Anna Brunstrom Message-ID: <2c19e596-7e30-ed1c-03f7-50c74a588bf3@kau.se> Date: Tue, 6 Mar 2018 17:32:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5BC30C4C92B3E04C8369CA47" 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] Draft agenda for TAPS session at IETF101 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 06 Mar 2018 16:32:29 -0000 --------------5BC30C4C92B3E04C8369CA47 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Thanks Zahed! Looks good I think. BR, Anna On 2018-03-05 20:35, Zaheduzzaman Sarker wrote: > > Hi, > > I have now updated the agenda, have a look > https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt > > BR > > Zahed > > On 2018-03-05, 14:19, "Taps on behalf of Zaheduzzaman Sarker" > on behalf of > zaheduzzaman.sarker@ericsson.com > > wrote: > > Hi all, > > A draft agenda for TAPS session has been uploaded > https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt > > Have a look and suggest changes, if any. > > BR > > Zahed > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --------------5BC30C4C92B3E04C8369CA47 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Thanks Zahed! 

Looks good I think.

BR,
Anna


On 2018-03-05 20:35, Zaheduzzaman Sarker wrote:

Hi,

 

I have now updated the agenda, have a look https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt

 

BR

 

Zahed

 

 

On 2018-03-05, 14:19, "Taps on behalf of Zaheduzzaman Sarker" <taps-bounces@ietf.org on behalf of zaheduzzaman.sarker@ericsson.com> wrote:

 

Hi all,

 

A draft agenda for TAPS session has been uploaded https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt

 

Have a look and suggest changes, if any.

 

BR

 

Zahed



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

--------------5BC30C4C92B3E04C8369CA47-- From nobody Mon Mar 12 01:05:28 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 ED2E91270A0 for ; Mon, 12 Mar 2018 01:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 oHev-THeJLCI for ; Mon, 12 Mar 2018 01:05:24 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id B252412706D for ; Mon, 12 Mar 2018 01:05:24 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 9E6871B001AA; Mon, 12 Mar 2018 08:04:43 +0000 (GMT) Message-ID: <5AA6349A.1080202@erg.abdn.ac.uk> Date: Mon, 12 Mar 2018 08:04:42 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen 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: RFC Errata System CC: ietf@trammell.ch, mirja.kuehlewind@tik.ee.ethz.ch, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, aaron.falk@gmail.com, Zaheduzzaman.Sarker@ericsson.com, wes@mti-systems.com, taps@ietf.org References: <20180312035439.34DD1B81A5D@rfc-editor.org> In-Reply-To: <20180312035439.34DD1B81A5D@rfc-editor.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] [Editorial Errata Reported] RFC8095 (5285) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 12 Mar 2018 08:05:27 -0000 This Errata seems valid. Sorry that was not spotted. Gorry On 12/03/2018, 03:54, RFC Errata System wrote: > The following errata report has been submitted for RFC8095, > "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5285 > > -------------------------------------- > Type: Editorial > Reported by: Wesley Eddy > > Section: section 3.1 > > Original Text > ------------- > 3.1 Transport Control Protocol (TCP) > > Corrected Text > -------------- > 3.1 Transmission Control Protocol (TCP) > > Notes > ----- > The acronym-expansion for TCP is incorrect in the section title, but is correct in other text within the document. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8095 (draft-ietf-taps-transports-14) > -------------------------------------- > Title : Services Provided by IETF Transport Protocols and Congestion Control Mechanisms > Publication Date : March 2017 > Author(s) : G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed. > Category : INFORMATIONAL > Source : Transport Services > Area : Transport > Stream : IETF > Verifying Party : IESG From nobody Mon Mar 12 07:53: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 7FFF01201FA for ; Mon, 12 Mar 2018 07:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0F0TihnztAmh for ; Mon, 12 Mar 2018 07:53:36 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 914E0124217 for ; Mon, 12 Mar 2018 07:53:36 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id x17so1535567ywj.1 for ; Mon, 12 Mar 2018 07:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wAi9hk46TUKMFukqf71+W5ZPTmuTg5jitIJkbz9/wtM=; b=I58oMkKUEN3eBlZ8zUlUsOhJeeSQseNl2Akhbxz9zsMzW3QQCm/jD3R2wVJgA0EuUm QnigoktuEA3usxdWEzpCk6fdcv02i48tMdqCusYYn8Ag2eqDnGDq/F+P4jqKRq2NW7oF 0pIneUjz3gVvN/SooUGKvqM+14X8rTUkAMaG3yvEyxmhu93heNFZKh231yVtFxuA3r2x 7ngdS21064ceG43bFQGj8FdX4rdNGJ+FViGAVFTpR65fBP/p38xIHqazHMq0PnILZ9WH V/hz7glPJ2gvhh4PoalH0F6dnK/H8z61zLEOhtJL6lcOqS+tbkDEptgfBTBmuPfp2Axi VrTw== 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=wAi9hk46TUKMFukqf71+W5ZPTmuTg5jitIJkbz9/wtM=; b=Obi501hnpmYAZK4UbIcMQS6hn0EwV+9+SlJMtDspslfmMkFfzxcs6rc3sLQ1T+yMj+ vxtpalcZPo4yRPFh7hoxYjc+zR7xsEqA+ydjHK0GL1Sd580F/iORf1p7tPNNSdrUTHnb nXGadFeoKC6Qtggxzv2l+WS2UOr3a0cfFYr97GGVIkPPwCP1UNxwxExUc7BDJixbp2Do leuSTwfFeyhwCUfp9PqZ2qZz4li5pqprvl8xneR1igslKbCORE9cc+B8sYwo2IIpzI9Y G3iJT60n5/6NdPbDJ4vi+EzqLG986tha9eBP9wYqb0jx8sDyBav43Dl4zFOjwRQGJeTL GwOw== X-Gm-Message-State: AElRT7GaldmBnqQxxYxR7XzUR64UQVJ2BAx4NjjLU8byVNdy5ztZtF6S WTA9Th+Hr5/UJcxNiOZ9Dz3cgoGpygvya1DKcMw= X-Google-Smtp-Source: AG47ELt0x8ZKCQ60h4PpVAsNvmaJKtRaEx0jliiv6BV1QTYH4HfQ1zuL5xHylYdCbiGkDT0ULxI6s1gTmri1s42A1s0= X-Received: by 2002:a25:b98e:: with SMTP id r14-v6mr4582734ybg.173.1520866415513; Mon, 12 Mar 2018 07:53:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.181.81 with HTTP; Mon, 12 Mar 2018 07:53:35 -0700 (PDT) In-Reply-To: <2c19e596-7e30-ed1c-03f7-50c74a588bf3@kau.se> References: <2c19e596-7e30-ed1c-03f7-50c74a588bf3@kau.se> From: Christopher Wood Date: Mon, 12 Mar 2018 07:53:35 -0700 Message-ID: To: Anna Brunstrom , Zaheduzzaman Sarker , Aaron Falk Cc: taps WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Taps] Draft agenda for TAPS session at IETF101 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 12 Mar 2018 14:53:38 -0000 Hi Zahed, Aaron, Would it be possible to move the talk for draft-pauly-taps-transport-security to the start of Wednesday's meeting? There are talks in the tail end of the conflicting TLS session that I need to attend. Thanks, Chris On Tue, Mar 6, 2018 at 8:32 AM, Anna Brunstrom wrote: > Thanks Zahed! > > Looks good I think. > > BR, > Anna > > > On 2018-03-05 20:35, Zaheduzzaman Sarker wrote: > > Hi, > > > > I have now updated the agenda, have a look > https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt > > > > BR > > > > Zahed > > > > > > On 2018-03-05, 14:19, "Taps on behalf of Zaheduzzaman Sarker" > wrote: > > > > Hi all, > > > > A draft agenda for TAPS session has been uploaded > https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt > > > > Have a look and suggest changes, if any. > > > > 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 > From nobody Mon Mar 12 08:05:56 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 BAFEF126DED for ; Mon, 12 Mar 2018 08:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJrh1--JkQWa for ; Mon, 12 Mar 2018 08:05:53 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87582126D05 for ; Mon, 12 Mar 2018 08:05:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=e2J5Y6IEigyb2+oB7UIHY6Byy8fQXGCNXMroMXttq3bxdnKX4h1xdQuz7OLV/MEx+bS0veoV4ib774wna/EFgaq5Dy/BHnlVBtKw4gHSTpZoQJuK42c4WfxtXVy63QZaf85M5xeauD4eX+Vi4EJVGHz6MBakfaS1kdMqkJ5lVqk=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 25113 invoked from network); 12 Mar 2018 16:04:50 +0100 Received: from public-docking-pat-etx-mapped-0007.ethz.ch (HELO ?10.2.118.177?) (195.176.110.232) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Mar 2018 16:04:50 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <5AA6349A.1080202@erg.abdn.ac.uk> Date: Mon, 12 Mar 2018 16:04:49 +0100 Cc: RFC Errata System , ietf@trammell.ch, spencerdawkins.ietf@gmail.com, aaron.falk@gmail.com, Zaheduzzaman.Sarker@ericsson.com, wes@mti-systems.com, taps@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180312035439.34DD1B81A5D@rfc-editor.org> <5AA6349A.1080202@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180312150450.25102.83625@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Taps] [Editorial Errata Reported] RFC8095 (5285) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 12 Mar 2018 15:05:55 -0000 Ups=E2=80=A6 I=E2=80=99ll go ahead and verify this one! > Am 12.03.2018 um 09:04 schrieb Gorry Fairhurst : >=20 > This Errata seems valid. Sorry that was not spotted. >=20 > Gorry >=20 > On 12/03/2018, 03:54, RFC Errata System wrote: >> The following errata report has been submitted for RFC8095, >> "Services Provided by IETF Transport Protocols and Congestion Control = Mechanisms". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5285 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Wesley Eddy >>=20 >> Section: section 3.1 >>=20 >> Original Text >> ------------- >> 3.1 Transport Control Protocol (TCP) >>=20 >> Corrected Text >> -------------- >> 3.1 Transmission Control Protocol (TCP) >>=20 >> Notes >> ----- >> The acronym-expansion for TCP is incorrect in the section title, but = is correct in other text within the document. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC8095 (draft-ietf-taps-transports-14) >> -------------------------------------- >> Title : Services Provided by IETF Transport Protocols = and Congestion Control Mechanisms >> Publication Date : March 2017 >> Author(s) : G. Fairhurst, Ed., B. Trammell, Ed., M. = Kuehlewind, Ed. >> Category : INFORMATIONAL >> Source : Transport Services >> Area : Transport >> Stream : IETF >> Verifying Party : IESG >=20 From nobody Mon Mar 12 08:06: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 3E901126D05; Mon, 12 Mar 2018 08:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 pyL8OTCHeBFv; Mon, 12 Mar 2018 08:06:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025391205F0; Mon, 12 Mar 2018 08:06:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 29279B81659; Mon, 12 Mar 2018 08:06:21 -0700 (PDT) To: wes@mti-systems.com, gorry@erg.abdn.ac.uk, ietf@trammell.ch, mirja.kuehlewind@tik.ee.ethz.ch X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ietf@kuehlewind.net, iesg@ietf.org, taps@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180312150621.29279B81659@rfc-editor.org> Date: Mon, 12 Mar 2018 08:06:21 -0700 (PDT) Archived-At: Subject: [Taps] [Errata Verified] RFC8095 (5285) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 12 Mar 2018 15:06:44 -0000 The following errata report has been verified for RFC8095, "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5285 -------------------------------------- Status: Verified Type: Editorial Reported by: Wesley Eddy Date Reported: 2018-03-12 Verified by: Mirja Kühlewind (IESG) Section: section 3.1 Original Text ------------- 3.1 Transport Control Protocol (TCP) Corrected Text -------------- 3.1 Transmission Control Protocol (TCP) Notes ----- The acronym-expansion for TCP is incorrect in the section title, but is correct in other text within the document. -------------------------------------- RFC8095 (draft-ietf-taps-transports-14) -------------------------------------- Title : Services Provided by IETF Transport Protocols and Congestion Control Mechanisms Publication Date : March 2017 Author(s) : G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed. Category : INFORMATIONAL Source : Transport Services Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Mar 12 08:12:12 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 8DBE7124217 for ; Mon, 12 Mar 2018 08:12:06 -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 g0XVxGFxtyBF for ; Mon, 12 Mar 2018 08:12:02 -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 B436F127863 for ; Mon, 12 Mar 2018 08:12:01 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id t6so19153470qtn.9 for ; Mon, 12 Mar 2018 08:12:01 -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=jaevvQtYaYirdCxlFoPaAooX2pXZsrTMiDMkXprg93g=; b=J7hKIaTg0/YhRE+WO0asc6jTa9+Q6fJIHWd7aMyRZ5RprTpRK1r9yIRr7v5VGaAJfD jRS9PAlAaqfA1kjfxCMAlSYJNj7lK/odDcVFwTCOsh6OFSL9szWUKuA//ayDhOgbsj25 Eq3R/CMXop7fAbl3pP4CVKf3JPYVDGrHlTIiE= 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=jaevvQtYaYirdCxlFoPaAooX2pXZsrTMiDMkXprg93g=; b=tCYPOxlKM6Cjupr32R/OL4QXKYwIr/bJxJyb1Bgh6wyEp3xtSkT6cvTbaql+R3FrFy f6b48Jcrq+c0816ba68UG4Sj29LP3ieQBIRS/K4FDVcUchgeE5auGOWOWH8WVlQehxab NxL8FFH34vGbQoHwrv+ZDOyPkYkCT3sUOKh24IMZPDwYrKq5NMtLLreOjm+VzU++cuzi 5H6Nig5/bkIpE8sZu4rCANL0guQR9rURzpAidhZtHe8FJ4gZ3kScDrT4/dPhtG0wOuAB 1TkoDwRN9xT3LvudTXL3OQCTuMHBbAEYgkHWJR0R8Oib0K9uk7uqCl0WlGgOTum4Yhfc Jong== X-Gm-Message-State: AElRT7EA6XFJA26o5dFiAse1+8v+WeL+qGwHD61DTW6+lxf/uRkE3YKU SMdQAi1tdS0eeaSrXRtVvB9lcfGdG3xDM+BQw0n2Ww== X-Google-Smtp-Source: AG47ELtNTFfR4VkAK3VN3rBGgpYNK/4cSYxTr+Y6hdFbSSPlT4RAeFRo6+1rxVgaD9NXcmFslUCGmWsgiZ4dCVthto8= X-Received: by 10.237.42.198 with SMTP id t64mr12404181qtd.274.1520867520688; Mon, 12 Mar 2018 08:12:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.215.204 with HTTP; Mon, 12 Mar 2018 08:12:00 -0700 (PDT) X-Originating-IP: [2001:4878:a000:3000:c04a:6e5d:6c14:df87] In-Reply-To: References: <2c19e596-7e30-ed1c-03f7-50c74a588bf3@kau.se> From: Kyle Rose Date: Mon, 12 Mar 2018 11:12:00 -0400 Message-ID: To: Christopher Wood Cc: Anna Brunstrom , Zaheduzzaman Sarker , Aaron Falk , taps WG Content-Type: multipart/alternative; boundary="94eb2c1235465271d10567389014" Archived-At: Subject: Re: [Taps] Draft agenda for TAPS session at IETF101 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 12 Mar 2018 15:12:06 -0000 --94eb2c1235465271d10567389014 Content-Type: text/plain; charset="UTF-8" In the future, can we add TLS as a P1 conflict for TAPS? There are a lot of folks who want to be in both, maybe especially now that our charter has expanded. Kyle On Mon, Mar 12, 2018 at 10:53 AM, Christopher Wood < christopherwood07@gmail.com> wrote: > Hi Zahed, Aaron, > > Would it be possible to move the talk for > draft-pauly-taps-transport-security to the start of Wednesday's > meeting? There are talks in the tail end of the conflicting TLS > session that I need to attend. > > Thanks, > Chris > > On Tue, Mar 6, 2018 at 8:32 AM, Anna Brunstrom > wrote: > > Thanks Zahed! > > > > Looks good I think. > > > > BR, > > Anna > > > > > > On 2018-03-05 20:35, Zaheduzzaman Sarker wrote: > > > > Hi, > > > > > > > > I have now updated the agenda, have a look > > https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt > > > > > > > > BR > > > > > > > > Zahed > > > > > > > > > > > > On 2018-03-05, 14:19, "Taps on behalf of Zaheduzzaman Sarker" > > > wrote: > > > > > > > > Hi all, > > > > > > > > A draft agenda for TAPS session has been uploaded > > https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt > > > > > > > > Have a look and suggest changes, if any. > > > > > > > > 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 > --94eb2c1235465271d10567389014 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the future, can we add TLS as a P1 conflict for TA= PS? There are a lot of folks who want to be in both, maybe especially now t= hat our charter has expanded.

Kyle


On Mon, Mar 12, 2018 at 10:53 A= M, Christopher Wood <christopherwood07@gmail.com> = wrote:
Hi Zahed, Aaron,

Would it be possible to move the talk for
draft-pauly-taps-transport-security to the start of Wednesday's meeting? There are talks in the tail end of the conflicting TLS
session that I need to attend.

Thanks,
Chris

On Tue, Mar 6, 2018 at 8:32 AM, Anna Brunstrom <anna.brunstrom@kau.se> wrote:
> Thanks Zahed!
>
> Looks good I think.
>
> BR,
> Anna
>
>
> On 2018-03-05 20:35, Zaheduzzaman Sarker wrote:
>
> Hi,
>
>
>
> I have now updated the agenda, have a look
> https://datatracker.ietf.= org/meeting/101/materials/agenda-101-taps.txt
>
>
>
> BR
>
>
>
> Zahed
>
>
>
>
>
> On 2018-03-05, 14:19, "Taps on behalf of Zaheduzzaman Sarker"= ;
> <taps-bounces@ietf.org= on behalf of zaheduzza= man.sarker@ericsson.com> wrote:
>
>
>
> Hi all,
>
>
>
> A draft agenda for TAPS session has been uploaded
> https://datatracker.ietf.= org/meeting/101/materials/agenda-101-taps.txt
>
>
>
> Have a look and suggest changes, if any.
>
>
>
> 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

--94eb2c1235465271d10567389014-- From nobody Mon Mar 12 08:12:51 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 7739C1205F0 for ; Mon, 12 Mar 2018 08:12:50 -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, HTML_MESSAGE=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 nrsqGknwike0 for ; Mon, 12 Mar 2018 08:12:49 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271F41201FA for ; Mon, 12 Mar 2018 08:12:49 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id u5so4456328pfh.6 for ; Mon, 12 Mar 2018 08:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=pMG8mFYXNcNQcOSa++1yexG/dfEKk5j69AJWdnlGQuQ=; b=pbjofqe4U941kr832npav1JG2ZIxOengZEiYBTSO/us49AYl9Z/rnEMzK770Xl4hGn jlfjU23J42fAJ2Q3nbtUlOsgURRo1jFAsaSShYGEGVWit19Hb8AZE8g4kG2Ga0yPEvMu NYNEovec/hrH3RvKx5PNXDm5N7TCAGS907lIkVIL9X79s1P9rm3xt41x2pN9Jb3xo8PV 3ye3lmxmzS5PRhNzdAPuha3qHsMkXphtQkRuPPdPqoEmo8NlI2BqoEbsXkzm9TrJIXBm 6IBwAXolIugxAu8gCj2YHjrJznJ++nB2D9Rk3wYEaprqAD4PI5OEj0Ds2ocnxBW9NXQ4 UieA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=pMG8mFYXNcNQcOSa++1yexG/dfEKk5j69AJWdnlGQuQ=; b=b2y8BbRqOcHkQ/JIDQj/pg+hF6oNdG+ejegh6xsGyBCThon2fMYILF76avvUjEydbD cyUWUR13sXjz0OQvW6D+yXAOqVfwDuwZXUT69/7jQAOJBsL6jwqrG2FTGF0cN/FnyEU+ SuXTb0cyWXmHZcLyrMnIgNsuMN9JrUewpWcX9K+BcorOdS0E/Yk6dj3sdessubDGxmkz 37WvU+LI9gePCW1hogjY1kV7d7urLa+DMa5pafGt4OBLUl8lte9V1yzFC4lJehVaatiO pq27NKe5z6nlHfuVWm2Wqen4GH1TJC3rLiW/xPuiA8JgBb3yBpXRiYJOw9F/Or26proK m87g== X-Gm-Message-State: AElRT7E6kxEw/MICcSdmyXRLaXMIuiKMvZDwCjFLMfJx6bbhI7jEoyZd +vZNa2aPAKhMcvDQBA6vYWo= X-Google-Smtp-Source: AG47ELur5oPTUdW2zFXXoq5+ix23MSbRYxiJj5YJWBCVLfAaaaUgblpi3W80YFeBClkB0qDOntnPLQ== X-Received: by 10.98.35.195 with SMTP id q64mr8262233pfj.161.1520867568564; Mon, 12 Mar 2018 08:12:48 -0700 (PDT) Received: from [17.192.192.12] ([17.192.192.12]) by smtp.gmail.com with ESMTPSA id h69sm17489445pfe.97.2018.03.12.08.12.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 08:12:48 -0700 (PDT) Date: Mon, 12 Mar 2018 08:12:33 -0700 From: Christopher Wood To: Kyle Rose Cc: Anna Brunstrom , Zaheduzzaman Sarker , Aaron Falk , taps WG Message-ID: <56218722-e3e0-4a3b-8004-c6aca23b697f@Spark> In-Reply-To: References: <2c19e596-7e30-ed1c-03f7-50c74a588bf3@kau.se> X-Readdle-Message-ID: 56218722-e3e0-4a3b-8004-c6aca23b697f@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5aa698ef_721da317_db4" Archived-At: Subject: Re: [Taps] Draft agenda for TAPS session at IETF101 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 12 Mar 2018 15:12:50 -0000 --5aa698ef_721da317_db4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline +1 On Mar 12, 2018, 8:12 AM -0700, Kyle Rose , wrote: > In the future, can we add TLS as a P1 conflict for TAPS? There are a lot of folks who want to be in both, maybe especially now that our charter has expanded. > > Kyle > > > > On Mon, Mar 12, 2018 at 10:53 AM, Christopher Wood wrote: > > > Hi Zahed, Aaron, > > > > > > Would it be possible to move the talk for > > > draft-pauly-taps-transport-security to the start of Wednesday's > > > meeting? There are talks in the tail end of the conflicting TLS > > > session that I need to attend. > > > > > > Thanks, > > > Chris > > > > > > On Tue, Mar 6, 2018 at 8:32 AM, Anna Brunstrom wrote: > > > > Thanks Zahed! > > > > > > > > Looks good I think. > > > > > > > > BR, > > > > Anna > > > > > > > > > > > > On 2018-03-05 20:35, Zaheduzzaman Sarker wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I have now updated the agenda, have a look > > > > https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt > > > > > > > > > > > > > > > > BR > > > > > > > > > > > > > > > > Zahed > > > > > > > > > > > > > > > > > > > > > > > > On 2018-03-05, 14:19, "Taps on behalf of Zaheduzzaman Sarker" > > > > wrote: > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > A draft agenda for TAPS session has been uploaded > > > > https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt > > > > > > > > > > > > > > > > Have a look and suggest changes, if any. > > > > > > > > > > > > > > > > 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 > --5aa698ef_721da317_db4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
+1

On Mar 12, 2018, 8:12 AM -0700, Kyle Rose <krose=40krose.org>, wrot= e:
In the future, can we add TLS as a P1 conflict for TAPS=3F There are= a lot of folks who want to be in both, maybe especially now that our cha= rter has expanded.

Kyle


On Mon, Mar 12, 2018 at 10:53 AM, Christ= opher Wood <christopherwood07=40gmail.com> wrote:
Hi Zahed, Aaron,

Would it be possible to move the talk for
draft-pauly-taps-transport-security to the start of Wednesday's meeting=3F There are talks in the tail end of the conflicting TLS
session that I need to attend.

Thanks,
Chris

On Tue, Mar 6, 2018 at 8:32 AM, Anna Brunstrom <anna.brunstrom=40kau.se> wrote:
> Thanks Zahed=21
>
> Looks good I think.
>
> BR,
> Anna
>
>
> On 2018-03-05 20:35, Zaheduzzaman Sarker wrote:
>
> Hi,
>
>
>
> I have now updated the agenda, have a look
> https:/= /datatracker.ietf.org/meeting/101/materials/agenda-101-taps= .txt
>
>
>
> BR
>
>
>
> Zahed
>
>
>
>
>
> On 2018-03-05, 14:19, =22Taps on behalf of Zaheduzzaman Sarker=22 > <taps-bounces=40ie= tf.org on behalf of zaheduzzaman.sarker=40ericsson.com> wrote:
>
>
>
> Hi all,
>
>
>
> A draft agenda for TAPS session has been uploaded
> https:/= /datatracker.ietf.org/meeting/101/materials/agenda-101-taps= .txt
>
>
>
> Have a look and suggest changes, if any.
>
>
>
> BR
>
>
>
> Zahed
>
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> Taps mailing list
> Taps=40ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> Taps mailing list
> Taps=40ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
Taps mailing list
Taps=40ietf.org
https://www.ietf.org/mailman/list= info/taps

--5aa698ef_721da317_db4-- From nobody Mon Mar 12 09:08: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 F1721126C0F for ; Sun, 11 Mar 2018 20:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 O-OZ3qK4LZ-1 for ; Sun, 11 Mar 2018 20:55:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3AD21243FE for ; Sun, 11 Mar 2018 20:55:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 34DD1B81A5D; Sun, 11 Mar 2018 20:54:39 -0700 (PDT) To: gorry@erg.abdn.ac.uk, ietf@trammell.ch, mirja.kuehlewind@tik.ee.ethz.ch, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, aaron.falk@gmail.com, Zaheduzzaman.Sarker@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: wes@mti-systems.com, taps@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180312035439.34DD1B81A5D@rfc-editor.org> Date: Sun, 11 Mar 2018 20:54:39 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 12 Mar 2018 09:08:40 -0700 Subject: [Taps] [Editorial Errata Reported] RFC8095 (5285) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 12 Mar 2018 03:55:02 -0000 The following errata report has been submitted for RFC8095, "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5285 -------------------------------------- Type: Editorial Reported by: Wesley Eddy Section: section 3.1 Original Text ------------- 3.1 Transport Control Protocol (TCP) Corrected Text -------------- 3.1 Transmission Control Protocol (TCP) Notes ----- The acronym-expansion for TCP is incorrect in the section title, but is correct in other text within the document. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8095 (draft-ietf-taps-transports-14) -------------------------------------- Title : Services Provided by IETF Transport Protocols and Congestion Control Mechanisms Publication Date : March 2017 Author(s) : G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed. Category : INFORMATIONAL Source : Transport Services Area : Transport Stream : IETF Verifying Party : IESG From nobody Tue Mar 13 08:48:12 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 0EAF7127419 for ; Tue, 13 Mar 2018 08:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY7VMc5v4jzH for ; Tue, 13 Mar 2018 08:48:08 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD49126C22 for ; Tue, 13 Mar 2018 08:48:08 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id 132so70839qkd.5 for ; Tue, 13 Mar 2018 08:48:08 -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=Xl0EdkfPrdkB8lj3x9Jct7w+yNpGZSDDIzkH1TfcQxo=; b=NdGFnkGm/ebWhn83BVLnNJotI15YDmiIG6GyEibsiEihrSROtDL+QYZCtSZ5PYT8Id VHnTlst8GWr2MlubvG9yZclL04ZoJpykpfeFdZsXDEicxmD4uVngNU05iKNB6Mo8w9ok A5ZjlNRRsXt60TuUfBDw1ExzziiZl1KqPPJiXHmgiJCgxFTGMwAohECMEoObyJrW95vU hz1gPKhNNtPWy0gnlrSq+gCHoZqWUYjcpMPmEA0wgSQLPvGbXKzk9UrUEgGNzJixDsAz 3ff6Hiv/uNxqTYrPNdfqacirL6+QF/+TAo5lyEJSjR2FA5NlTeen4DvLbkivqiExcO8P aO+w== 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=Xl0EdkfPrdkB8lj3x9Jct7w+yNpGZSDDIzkH1TfcQxo=; b=MC4ujInWhO5rLCVLiE59eiixMUzk2qBKRzTAdCiYgsfUTOjqln9KRAQ78G74pi+vDA EuQiBUevjX/RDonOx/FcDp0RUJ5z/6QCg1f8RD5J9P3K5Wdurol/kVjCvNNd57/OSCfl +VZqMvumNFJbpla0ccpZnXYRKvZPjnbNYo4dhBP6A9YIN5R6ye9sPGNJcfSAXBQbvBCO GXazjzAN2H0V6AfCm0Skzi4/UBG5aE1hwdQWCfBkErYY6V3W3t239XbvdJZIckZvBYvV 83VDAf6YovkxTGV/6hT5wrnpW5SXQt7BLI68tMj3mMCK9d4o+bXmGh5fyuJBOla6b2Bi zYjQ== X-Gm-Message-State: AElRT7GkAQkZjLncVYxdOKomMS3Zs5A2XvMSobq5KTG5M1KsOX8nOlcN OAqV62YOlTc8vfgkTW2E2k0= X-Google-Smtp-Source: AG47ELsBwHLkbc0taobnsGixr1Avmtk4qCDkqd/Tfv6pXYOw6lR4WvHOw5jsOJWixhyLdhYVusC5xA== X-Received: by 10.55.23.101 with SMTP id i98mr1684934qkh.91.1520956087389; Tue, 13 Mar 2018 08:48:07 -0700 (PDT) Received: from [172.19.34.199] ([2601:184:4980:a321:3563:84ed:5adb:2f97]) by smtp.gmail.com with ESMTPSA id t68sm351731qkf.62.2018.03.13.08.48.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 08:48:06 -0700 (PDT) From: "Aaron Falk" To: "Christopher Wood" Cc: "Kyle Rose" , "Anna Brunstrom" , "Zaheduzzaman Sarker" , "taps WG" Date: Tue, 13 Mar 2018 11:48:04 -0400 X-Mailer: MailMate (1.11r5462) Message-ID: <983DB471-C638-4726-BDCD-B103E990FA99@gmail.com> In-Reply-To: <56218722-e3e0-4a3b-8004-c6aca23b697f@Spark> References: <2c19e596-7e30-ed1c-03f7-50c74a588bf3@kau.se> <56218722-e3e0-4a3b-8004-c6aca23b697f@Spark> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_E82D4487-69FF-4A66-90C5-0B6967B9D452_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[876, 4067], "plain":[455, 2045], "uuid":"18249977-DFF1-48B2-A9F6-A12010AD654B"}] Archived-At: Subject: Re: [Taps] Draft agenda for TAPS session at IETF101 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 13 Mar 2018 15:48:11 -0000 --=_MailMate_E82D4487-69FF-4A66-90C5-0B6967B9D452_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Great point. It’s probably time to review the conflict list: First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic Second Priority: tcpinc nvo3 mptcp icnrg httpbis dots i2nsf saag Third Priority: mmusic tram sacm mile ipwave cfrg Other than adding TLS to 1st priority, any other changes? Would be great if we can delete some and make the scheduler’s life easier. --aaron On 12 Mar 2018, at 11:12, Christopher Wood wrote: > +1 > > On Mar 12, 2018, 8:12 AM -0700, Kyle Rose , wrote: >> In the future, can we add TLS as a P1 conflict for TAPS? There are a >> lot of folks who want to be in both, maybe especially now that our >> charter has expanded. >> >> Kyle >> >> >>> On Mon, Mar 12, 2018 at 10:53 AM, Christopher Wood >>> wrote: >>>> Hi Zahed, Aaron, >>>> >>>> Would it be possible to move the talk for >>>> draft-pauly-taps-transport-security to the start of Wednesday's >>>> meeting? There are talks in the tail end of the conflicting TLS >>>> session that I need to attend. >>>> >>>> Thanks, >>>> Chris >>>> >>>> On Tue, Mar 6, 2018 at 8:32 AM, Anna Brunstrom >>>> wrote: >>>>> Thanks Zahed! >>>>> >>>>> Looks good I think. >>>>> >>>>> BR, >>>>> Anna >>>>> >>>>> >>>>> On 2018-03-05 20:35, Zaheduzzaman Sarker wrote: >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I have now updated the agenda, have a look >>>>> https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt >>>>> >>>>> >>>>> >>>>> BR >>>>> >>>>> >>>>> >>>>> Zahed >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2018-03-05, 14:19, "Taps on behalf of Zaheduzzaman Sarker" >>>>> >>>> zaheduzzaman.sarker@ericsson.com> wrote: >>>>> >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> A draft agenda for TAPS session has been uploaded >>>>> https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt >>>>> >>>>> >>>>> >>>>> Have a look and suggest changes, if any. >>>>> >>>>> >>>>> >>>>> 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_E82D4487-69FF-4A66-90C5-0B6967B9D452_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Great point. It=E2=80=99s probably time to review the con= flict list:

First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmc= at tsvarea quic
Second Priority: tcpinc nvo3 mptcp icnrg httpbis dots i2nsf saag
Third Priority: mmusic tram sacm mile ipwave cfrg

Other than adding TLS to 1st priority, any other changes?= Would be great if we can delete some and make the scheduler=E2=80=99s l= ife easier.

--aaron

On 12 Mar 2018, at 11:12, Christopher Wood wrote:

+1

On Mar 12, 2018, 8:12 AM -0700, Kyle Rose <krose@krose.org>, wrote:=
In the future, can we add TLS as a P1 conflict for TAPS? There are a= lot of folks who want to be in both, maybe especially now that our chart= er has expanded.

Kyle


On Mon, Mar 12, 2018 at 10:53 AM, Christopher = Wood <christopherwood07@gmail.com> wrote:
Hi Zahed, Aaron,

Would it be possible to move the talk for
draft-pauly-taps-transport-security to the start of Wednesday's meeting? There are talks in the tail end of the conflicting TLS
session that I need to attend.

Thanks,
Chris

On Tue, Mar 6, 2018 at 8:32 AM, Anna Brunstrom <anna.brunstrom@kau.se> wrote:
> Thanks Zahed!
>
> Looks good I think.
>
> BR,
> Anna
>
>
> On 2018-03-05 20:35, Zaheduzzaman Sarker wrote:
>
> Hi,
>
>
>
> I have now updated the agenda, have a look
> https://datatracker.i= etf.org/meeting/101/materials/agenda-101-taps.txt
= >
>
>
> BR
>
>
>
> Zahed
>
>
>
>
>
> On 2018-03-05, 14:19, "Taps on behalf of Zaheduzzaman Sarker"
> <taps-bounces@ietf.org on behalf of zahed= uzzaman.sarker@ericsson.com> wrote:
>
>
>
> Hi all,
>
>
>
> A draft agenda for TAPS session has been uploaded
> https://datatracker.i= etf.org/meeting/101/materials/agenda-101-taps.txt
= >
>
>
> Have a look and suggest changes, if any.
>
>
>
> 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<= br />

--=_MailMate_E82D4487-69FF-4A66-90C5-0B6967B9D452_=-- From nobody Tue Mar 13 08:56:14 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 2E45F126DC2 for ; Tue, 13 Mar 2018 08:56:13 -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 xAixPXCfYcZf for ; Tue, 13 Mar 2018 08:56:11 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BBE2126C22 for ; Tue, 13 Mar 2018 08:56:11 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id m13so74631qtg.13 for ; Tue, 13 Mar 2018 08:56:11 -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=x2xfsi95IiZem41Bzz/VlHodyc24V7sH9pnzbMqmig0=; b=BWtjH3bF3SVREVsQ7zHi7y68kZdhgHxdEXOD63YxNtqqfjLiVrqjpVhhLDTdlQEdP9 3CeMx/pItuC9DXBPda5c+OylVIkRO82sBmjgchkpvpmBOC7FpE3ghWVipg5MSzscZVGJ i/oGYd0sLyf91SoHCouFlkPD8pHHHGoQYwbr9f+0Yhq3szcBZ0U0E4j/bLotA4+WJVO1 i+T1uT7/LyDmbOOIvtKsMzXTOHpSYpYQpWQPgYLbXS8DKjxc6YzonLudqJPpTKhh7F+h 1zTqCmyXviOR3XGW98aVwdBb1B7rpnnHesgxq3TNakD6gCeEANZE3x8SHkazrCspO6SJ J1cw== 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=x2xfsi95IiZem41Bzz/VlHodyc24V7sH9pnzbMqmig0=; b=GfijxFRU0LkEb/+dfCfEUK6YNh5fS/nqtEGEhkhaiOkPZallRsVwu8gYEEa8XiJEEY bfvFtmn44ZEXOVNs/2i7KNB6+gG/vyV3JIZmo25fczJJ+za1QLBEArpShiW3jz20B9+K +j5MNygaWVZ5702SzQTkgpPsWI3yVz5HFSBKOhM75Ue1NR4bshUIjagI6v6AFU/1/GSH gTBIgFyvtrdDst9iuiT/YdsJxpVvAEOAhkZNQhi9V+Y2XFzjjUGmc8PSq5llTrZcP82R 6sD6RZulY2Iq5zmfKLm54cRM6Y3vapFV41CZxPEj3r6L1aLxeHBnAg7ofgm8IKtPq2b0 mLmw== X-Gm-Message-State: AElRT7GzAvSQY6/STU4BjomE6FV/QYocP8VuXXPR4jlf4jUIAJfuWxHi RlZkFVHBab1GORfKVPXi8KQ= X-Google-Smtp-Source: AG47ELs1TtuPvZEKkMdjnLBzySVPcO8D7UVGplIN7eRUz779wULsZ3HQMm4mp/9KrSPv48mUfi7ATw== X-Received: by 10.237.52.103 with SMTP id w94mr1757470qtd.218.1520956570193; Tue, 13 Mar 2018 08:56:10 -0700 (PDT) Received: from [172.19.34.199] ([2601:184:4980:a321:3563:84ed:5adb:2f97]) by smtp.gmail.com with ESMTPSA id 10sm187095qkl.65.2018.03.13.08.56.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 08:56:09 -0700 (PDT) From: "Aaron Falk" To: "Christopher Wood" Cc: "Anna Brunstrom" , "Zaheduzzaman Sarker" , "taps WG" Date: Tue, 13 Mar 2018 11:56:08 -0400 X-Mailer: MailMate (1.11r5462) Message-ID: In-Reply-To: References: <2c19e596-7e30-ed1c-03f7-50c74a588bf3@kau.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_D7268163-EFCA-49AD-AA20-0EC6235E8738_=" Archived-At: Subject: Re: [Taps] Draft agenda for TAPS session at IETF101 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 13 Mar 2018 15:56:13 -0000 --=_MailMate_D7268163-EFCA-49AD-AA20-0EC6235E8738_= Content-Type: text/plain; format=flowed Hey Chris- I moved up your talk to the start of the session: https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps --aaron On 12 Mar 2018, at 10:53, Christopher Wood wrote: > Hi Zahed, Aaron, > > Would it be possible to move the talk for > draft-pauly-taps-transport-security to the start of Wednesday's > meeting? There are talks in the tail end of the conflicting TLS > session that I need to attend. > > Thanks, > Chris > > On Tue, Mar 6, 2018 at 8:32 AM, Anna Brunstrom > wrote: >> Thanks Zahed! >> >> Looks good I think. >> >> BR, >> Anna >> >> >> On 2018-03-05 20:35, Zaheduzzaman Sarker wrote: >> >> Hi, >> >> >> >> I have now updated the agenda, have a look >> https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt >> >> >> >> BR >> >> >> >> Zahed >> >> >> >> >> >> On 2018-03-05, 14:19, "Taps on behalf of Zaheduzzaman Sarker" >> >> wrote: >> >> >> >> Hi all, >> >> >> >> A draft agenda for TAPS session has been uploaded >> https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt >> >> >> >> Have a look and suggest changes, if any. >> >> >> >> 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 >> --=_MailMate_D7268163-EFCA-49AD-AA20-0EC6235E8738_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Hey Chris-

I moved up your talk to the start of the session: https://datatracker.ietf.org/meeting/101/materials= /agenda-101-taps

--aaron

On 12 Mar 2018, at 10:53, Christopher Wood wrote:

Hi Zahed, Aaron,

Would it be possible to move the talk for
draft-pauly-taps-transport-security to the start of Wednesday's
meeting? There are talks in the tail end of the conflicting TLS
session that I need to attend.

Thanks,
Chris

On Tue, Mar 6, 2018 at 8:32 AM, Anna Brunstrom <anna.brunstrom@kau.se&= gt; wrote:

Thanks Zahe= d!

Looks good I think.

BR,
Anna


On 2018-03-05 20:35, Zaheduzzaman Sarker wrote:

Hi,



I have now updated the agenda, have a look
https://datatracker.ietf.org/meeting/101/m= aterials/agenda-101-taps.txt



BR



Zahed





On 2018-03-05, 14:19, "Taps on behalf of Zaheduzzaman Sarker"
<taps-bounces@ietf.org on behalf of zaheduzzaman.sarker@ericsson.com&g= t; wrote:



Hi all,



A draft agenda for TAPS session has been uploaded
https://datatracker.ietf.org/meeting/101/m= aterials/agenda-101-taps.txt



Have a look and suggest changes, if any.



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

--=_MailMate_D7268163-EFCA-49AD-AA20-0EC6235E8738_=-- From nobody Tue Mar 13 12:02: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 9DA9A1200F1 for ; Tue, 13 Mar 2018 12:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 5J5cbIAGnxMu for ; Tue, 13 Mar 2018 12:02:45 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::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 4600F12D7F4 for ; Tue, 13 Mar 2018 12:02:44 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id w15-v6so343545plq.9 for ; Tue, 13 Mar 2018 12:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=QjMDWY5RUGctZTu3PM4hhjXZlod/R+hoaJ+5A2204OE=; b=EM5JZ802Zz/nw3DMsH2ejRf1rjyGapPOCGTtVIlMM79xi1SzyaeIrXT7mERSUr4CAy L1pLszWM6TTZhYAvfuzSeFoPkjRqxFJbrvY/R1NpHvYeH7Y4j2zw8MwEbCT0NGzHhtBD wAJgEOeaZmg35qZYb60Eois5kfm6hughEfB7l6x7ERFnEbsj0NgYv4Dn9slPRHHC+ucZ bbXy7hZUAgwNBk6YPCYpeB7nX0wAo3TgozA/00u/3GKoIhT0+cQeSibv2Rcd0pmY0+YJ jl4QCUNZs4RpPhL52DFRqbI2IGv2amTBOEwkFzKnBoqJvElP7C6oun5qTfXDaNk1vK/n 90KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=QjMDWY5RUGctZTu3PM4hhjXZlod/R+hoaJ+5A2204OE=; b=qXp+pBQr/pY7a17XhQdNujAkHHQ2qHSwtW0QtpbpC0e1+4BZfXIhE0kPCMa0SRGabp hVeMBoR4tdsiTD3I+cyTav2FktBVEkrh6mpbppN9I1roOFymLzFhQGT35Pg3cKPnm+Nh /7sIwUuebAPbKgjogS/i4kyQ6KjXHFeEGRX3rgBuu1C/Z2df8FXAMOfiPvLExiiMGQ0d nRgAD9t+sTAhkN16udykSHtu7TMuFbggDlAjVkrwTYNsw3oGldtcf671Bea5XA3wJx99 mZ3KlXnbwf3VcTAqZr2SvMfSeVpBC2cQLzgJThNDAjmIwULyMGS2OkWs6dhMOFMJquEA W3tA== X-Gm-Message-State: AElRT7EVb9HfVe7ROMvKuQ3kY2+HJ3obi7Rqj5QoUKpeV80DV+/9QhBa gOLUVY6+77WhdCOHYMnB6z8= X-Google-Smtp-Source: AG47ELubl+mVajZCoTEW5geyHCNJve1Lh/EZAFJstJ/J2nsxRyGTcr7iiVx7dTPubI8qKXqGcpGP2g== X-Received: by 2002:a17:902:8214:: with SMTP id x20-v6mr1535599pln.182.1520967763660; Tue, 13 Mar 2018 12:02:43 -0700 (PDT) Received: from [172.16.63.9] ([144.178.28.9]) by smtp.gmail.com with ESMTPSA id i4sm1798367pfa.40.2018.03.13.12.02.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 12:02:43 -0700 (PDT) Date: Tue, 13 Mar 2018 11:58:16 -0700 From: Christopher Wood To: Aaron Falk Cc: Anna Brunstrom , Zaheduzzaman Sarker , taps WG Message-ID: <3f600fe4-5489-4d36-828a-5533d3272677@Spark> In-Reply-To: References: <2c19e596-7e30-ed1c-03f7-50c74a588bf3@kau.se> X-Readdle-Message-ID: 3f600fe4-5489-4d36-828a-5533d3272677@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5aa82051_6b8b4567_4454" Archived-At: Subject: Re: [Taps] Draft agenda for TAPS session at IETF101 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 13 Mar 2018 19:02:47 -0000 --5aa82051_6b8b4567_4454 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks! On Mar 13, 2018, 8:56 AM -0700, Aaron Falk , wrote: > Hey Chris- > I moved up your talk to the start of the session: https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps > --aaron > On 12 Mar 2018, at 10:53, Christopher Wood wrote: > > Hi Zahed, Aaron, > > > > Would it be possible to move the talk for > > draft-pauly-taps-transport-security to the start of Wednesday's > > meeting? There are talks in the tail end of the conflicting TLS > > session that I need to attend. > > > > Thanks, > > Chris > > > > On Tue, Mar 6, 2018 at 8:32 AM, Anna Brunstrom wrote: > > > Thanks Zahed! > > > > > > Looks good I think. > > > > > > BR, > > > Anna > > > > > > > > > On 2018-03-05 20:35, Zaheduzzaman Sarker wrote: > > > > > > Hi, > > > > > > > > > > > > I have now updated the agenda, have a look > > > https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt > > > > > > > > > > > > BR > > > > > > > > > > > > Zahed > > > > > > > > > > > > > > > > > > On 2018-03-05, 14:19, "Taps on behalf of Zaheduzzaman Sarker" > > > wrote: > > > > > > > > > > > > Hi all, > > > > > > > > > > > > A draft agenda for TAPS session has been uploaded > > > https://datatracker.ietf.org/meeting/101/materials/agenda-101-taps.txt > > > > > > > > > > > > Have a look and suggest changes, if any. > > > > > > > > > > > > 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 --5aa82051_6b8b4567_4454 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thanks=21

On Mar 13, 2018, 8:56 AM -0700, Aaron =46alk <aaron.falk=40gmail.com&g= t;, wrote:

Hey Chris-

I moved up your talk to the start of the session: https://datatracker.ietf.org/meeting= /101/materials/agenda-101-taps

--aaron

On 12 Mar 2018, at 10:53, Christopher Wood wrote:

=

Hi Zahed, Aaron,

Would it be possible to move the talk for
draft-pauly-taps-transport-security to the start of Wednesday's
meeting=3F There are talks in the tail end of the conflicting TLS
session that I need to attend.

Thanks,
Chris

On Tue, Mar 6, 2018 at 8:32 AM, Anna Brunstrom <anna.brunstrom=40kau.s= e> wrote:

Thanks Zahed=21

Looks good I think.

BR,
Anna


On 2018-03-05 20:35, Zaheduzzaman Sarker wrote:

Hi,



I have now updated the agenda, have a look
https://datatracker.ietf.org/mee= ting/101/materials/agenda-101-taps.txt



BR



Zahed





On 2018-03-05, 14:19, =22Taps on behalf of Zaheduzzaman Sarker=22
<taps-bounces=40ietf.org on behalf of zaheduzzaman.sarker=40ericsson.c= om> wrote:



Hi all,



A draft agenda for TAPS session has been uploaded
https://datatracker.ietf.org/mee= ting/101/materials/agenda-101-taps.txt



Have a look and suggest changes, if any.



BR



Zahed



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Taps mailing list
Taps=40ietf.org
https://www.ietf.org/mailman/listinfo/taps



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Taps mailing list
Taps=40ietf.org
https://www.ietf.org/mailman/listinfo/taps

--5aa82051_6b8b4567_4454-- From nobody Sat Mar 17 07:53:51 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 B7788127978 for ; Sat, 17 Mar 2018 07:53:49 -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 YjL2axpDFZup for ; Sat, 17 Mar 2018 07:53:48 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387671242EA for ; Sat, 17 Mar 2018 07:53:48 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id u46so329483wrc.11 for ; Sat, 17 Mar 2018 07:53:48 -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 :content-transfer-encoding; bh=Lp0LhcLGvszu8PPj1zSm/M/B68OTyP2P2YUYN3xaM0o=; b=oSPPRdrudrkChab1NhT1/Skzh5lqOjeNJPADfeZt+OUSjwU6lz7C/13jcfTUY23RFV 0CLBGgfsRvrN5PEZeMRGqBZ//JXfuqxXXuNLDQo65H8D/UForETj/duxx5rKw6xXRlL9 V2LeZ0LRNRqpuJiuAm0M1V2nOc3ci27dPPuyGApB7iV0+22LdAZx+RaA1t3tFadgCsMG y+xAPO1blfe35xIsxyaMEVylfwnvZKR9ZNMkDDKZagWC5qG7npg9DQapbFNFJHtzgL8T DcvcyEpLoydV8Vn97dwF0uageipYlSxFVIIZJFy2xOoayI47oDuAb2s7Ju+Py+GpgWW+ 1kdg== 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 :content-transfer-encoding; bh=Lp0LhcLGvszu8PPj1zSm/M/B68OTyP2P2YUYN3xaM0o=; b=IDyWnYAymz05FZ+lYbiCz9KUQ5HJlGrGbEqeM051ug3nWt888ppPa9Kb2bindVWTrB h9FnAmSYkPUfsTbK/RrJ99OPdhgE9gaKzablKpKMDZcXXX0kFj9vT2RN3p08RaE5LtBo pT5unU2AulT11wV5ydwQkilDaRvoqmNROSkjlEjquhdx4WL0vVYyygqPqEQ1Xrje73EF EUL6PYU0L4CnImuRDjGuNkoBnt7XTt1mh30vxYolezWjsKNiwWTGo8CAopE6xj5ov1CW m2B6s9rXW56Uo/1L3W/2vrPAw7A1v1tlCLZTSOhjUCZS8GeBRj7yYgA5WC1CaRpCaTQW rJEQ== X-Gm-Message-State: AElRT7Gbnvn3EAwb25t10jPpMqGPyEQDCAu6KMkavnp2WpDIzMznTger +PqvwB/JS/Zt5coBp1D2BP4= X-Google-Smtp-Source: AG47ELtbW5GqF/HNi6CU6CEOAPlk8aF5kKpW8rZ4bgJB3EXmNxvHLAacCCbwN/R/HMuAKar5uJFFkg== X-Received: by 10.223.195.116 with SMTP id e49mr4540557wrg.5.1521298426524; Sat, 17 Mar 2018 07:53:46 -0700 (PDT) Received: from [172.19.152.112] ([2001:67c:1232:144:adee:22ea:9c7e:d589]) by smtp.gmail.com with ESMTPSA id k44sm358499wrk.6.2018.03.17.07.53.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Mar 2018 07:53:45 -0700 (PDT) From: "Aaron Falk" To: "Christopher Wood" , "Tommy Pauly" , "Colin Perkins" , "Kyle Rose" Cc: "taps WG" Date: Sat, 17 Mar 2018 14:53:44 +0000 X-Mailer: MailMate (1.11r5462) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_6E74F880-3E4A-4D94-849C-7EC5AB598526_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] comments on draft-pauly-taps-transport-security-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 14:53:50 -0000 --=_MailMate_6E74F880-3E4A-4D94-849C-7EC5AB598526_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit A few comments on the draft below. --aaron ---- Introduction (sec 1): * I think it’s missing a statement describing why you chose this set of protocols. You point out why you don’t include auth-only protocols but why (only) these? Are you including all of the IETF transport security protocols? If not, why not? For the non-IETF protocols, why these? The intro to Sec 3 says they are “security protocols that are currently used to protect data”. Terminology (sec 2): * Is ‘network security layer’ a well-defined term? Does it mean something like “a security service provided by the network layer to the transport layer”? Maybe worth including a definition. * Can security features exist above the transport layer? gQUIC (sec 3.4) * RFCs take a long time to publish and live forever. Given that, does documenting gQUIC make sense in that context? Do you expect it to be around for a long time? Are there functional differences from QUIC w/ TLS that distinguish it? MinimalT (sec 3.5) * I confess I’ve never heard of it. The draft doesn’t include a citation. Is there no RFC? Seems odd to me that it is “built on top of a widespread directory service” but the directory service isn’t identified. --=_MailMate_6E74F880-3E4A-4D94-849C-7EC5AB598526_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

A few comments on the draft below.

--aaron

Introduction (sec 1):

  • I think it=E2=80=99s missing a statement describing why you chose thi= s set of protocols. You point out why you don=E2=80=99t include auth-onl= y protocols but why (only) these? Are you including all of the IETF tran= sport security protocols? If not, why not? For the non-IETF protocols, = why these? The intro to Sec 3 says they are =E2=80=9Csecurity protocols = that are currently used to protect data=E2=80=9D.

Terminology (sec 2):

  • Is =E2=80=98network security layer=E2=80=99 a well-de= fined term? Does it mean something like =E2=80=9Ca security service prov= ided by the network layer to the transport layer=E2=80=9D? Maybe worth i= ncluding a definition.

  • Can security features exist above the transport layer= ?

gQUIC (sec 3.4)

  • RFCs take a long time to publish and live forever. Given that, does = documenting gQUIC make sense in that context? Do you expect it to be aro= und for a long time? Are there functional differences from QUIC w/ TLS t= hat distinguish it?

MinimalT (sec 3.5)

  • I confess I=E2=80=99ve never heard of it. The draft doesn=E2=80=99t = include a citation. Is there no RFC? Seems odd to me that it is =E2=80=9C= built on top of a widespread directory service=E2=80=9D but the directory= service isn=E2=80=99t identified.
--=_MailMate_6E74F880-3E4A-4D94-849C-7EC5AB598526_=-- From nobody Sun Mar 18 04:36: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 C47FE124B17 for ; Sun, 18 Mar 2018 04:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 bORix8RwzAVg for ; Sun, 18 Mar 2018 04:36:22 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 A5A711242F5 for ; Sun, 18 Mar 2018 04:36:21 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id s206so8754096wme.0 for ; Sun, 18 Mar 2018 04:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=9vEPqTdeIgeWW7i4Rb1SVjfH/Y/SYGubgHPY1kg+QYw=; b=bMYBP43CPnhCTGeg7zjrNQP93yQQTOXP9MvNUxyZ1DhSuyH/zHHUY63yWu4zgB/maT CJmzq1oQiWJBLKO82b3sTogxt5Lh02wm8JWvaMQ+ARMX1H5XD/dfCmW/M0CmVC0lOtrE lj5ov8b5KHMgsOOpe/Mjir3BCfcCapVHjoPred7VIAyjQQ7EIUpWidhpfrq1hGMpmkAx 0ClqqJh/UHS9uLbpVmt6cdle3PgJdswJ2FQer+XWVocHQj6sMsBP4Zb7dxTZP5DJ4W1I YPM/xWPSinryQcgrNmh4IYJVvVnO34nPtA0gzh/7m82OE+myNXSPDIk0/xxO2VLC1Omf gF3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=9vEPqTdeIgeWW7i4Rb1SVjfH/Y/SYGubgHPY1kg+QYw=; b=elX97R7RW7IQe4dcfyWtu3rAPDXgAyjfP3J/9zpm8rkgxyvQfPKFI/hixhXlO1Yved O9V83BtMnXDECSwaSoZcV8LxzdHVci2y0w0lWXmcLU91I8nCbeE1nqcYRwLEBCm4/Tgc U41MX1u1spBpsoy3NmhZ19Gasfy6XiLskSA9Pg+v7JVR0zwow32QERVZP/2TkTSn1pFT mu53DE8wn4kBwq1W/R+3fB4O9hDCSrAtAkTKwI9ksbCZR8qNmzLWmRrQ8qNZgRSsq6eR wf6fBLzSLDO/WjkOb4eXd+YeZck+LDgjWOSLDf6xlGFdwSADypwmFlBJ+NqkF/ee0m3+ iwWg== X-Gm-Message-State: AElRT7Hkada4jbepMVbT3QKY4X66o7yj6aCeFmUIMLGPTn81aR84mTUc FaCxz81bIjeub2sw65Dnn5A= X-Google-Smtp-Source: AG47ELuXWXDhzGd86WrWaiDKMD5RSzujBBtezihb5WfE7BCBK6isFOlev+rFDhqcWJAPnbSWhyigtw== X-Received: by 10.28.174.80 with SMTP id x77mr6363401wme.130.1521372979873; Sun, 18 Mar 2018 04:36:19 -0700 (PDT) Received: from [2001:67c:1232:144:e859:c914:70:0] ([2001:67c:1232:144:598f:ad08:3f4f:e1c4]) by smtp.gmail.com with ESMTPSA id w74sm10342813wmd.27.2018.03.18.04.36.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 04:36:19 -0700 (PDT) Date: Sun, 18 Mar 2018 11:36:04 +0000 From: Christopher Wood To: Tommy Pauly , Colin Perkins , Kyle Rose , Aaron Falk Cc: taps WG Message-ID: <5e97ce34-abb6-499c-a5b4-f86ba41ab15d@Spark> In-Reply-To: References: X-Readdle-Message-ID: 5e97ce34-abb6-499c-a5b4-f86ba41ab15d@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5aae4f32_431bd7b7_4a38" Archived-At: Subject: Re: [Taps] comments on draft-pauly-taps-transport-security-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 11:36:24 -0000 --5aae4f32_431bd7b7_4a38 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Aarron, Thanks for the feedback. Please see inline for responses. Best, Chris On Mar 17, 2018, 2:53 PM +0000, Aaron =46alk , wr= ote: > A few comments on the draft below. > --aaron > Introduction (sec 1): > I think it=E2=80=99s missing a statement describing why you chose this = set of protocols. You point out why you don=E2=80=99t include auth-only p= rotocols but why (only) these=3F No particular reason. Are there ones you think we should add=3F > Are you including all of the IET=46 transport security protocols=3F If = not, why not=3F =46or the non-IET=46 protocols, why these=3F The intro to= Sec 3 says they are =E2=80=9Csecurity protocols that are currently used = to protect data=E2=80=9D. As discussed a while back, we are including any and all transport securit= y protocols, inside and out of the IET=46. We could probably clean up the= rationale a bit to make that necessary condition more clear. > > > Terminology (sec 2): > > =E2=80=A2 > Is =E2=80=98network security layer=E2=80=99 a well-defined = term=3F Does it mean something like =E2=80=9Ca security service provided = by the network layer to the transport layer=E2=80=9D=3F Maybe worth inclu= ding a definition. > Agreed. I filed=C2=A0https://github.com/mami-project/draft-pauly-transpor= t-security/issues/24. > > =E2=80=A2 Can security features exist above the transport layer=3F > Yes =E2=80=94 see=C2=A0https://tools.ietf.org/html/draft-friel-tls-over-h= ttp-00=C2=A0as an example. > > =E2=80=A2 > gQUIC (sec 3.4) > R=46Cs take a long time to publish and live forever. Given that, does d= ocumenting gQUIC make sense in that context=3F Do you expect it to be aro= und for a long time=3F Are there functional differences from QUIC w/ TLS = that distinguish it=3F > In my opinion, it makes sense to document gQUIC. The crypto core and inte= gration are fundamentally different and deserving of their own section. > > > MinimalT (sec 3.5) > I confess I=E2=80=99ve never heard of it. The draft doesn=E2=80=99t inc= lude a citation. There is a citation, though the formatting is borked. I=E2=80=99ll fix th= is. > Is there no R=46C=3F No. > Seems odd to me that it is =E2=80=9Cbuilt on top of a widespread direct= ory service=E2=80=9D but the directory service isn=E2=80=99t identified. We can certainly go into more details here. I filed=C2=A0https://github.c= om/mami-project/draft-pauly-transport-security/issues/23. > > --5aae4f32_431bd7b7_4a38 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Aarron,

Thanks for the feedback. Please see inline for responses.

Best,
Chris

On Mar 17, 2018, 2:53 PM +0000, Aaron =46alk <aaron.falk=40gmail.com&g= t;, wrote:

A few comments on the draft below.

--aaron

Introduction (sec 1):

I think it=E2=80=99s missing a statement describing why you chose this se= t of protocols. You point out why you don=E2=80=99t include auth-only pro= tocols but why (only) these=3F &=23160;&=23160;

No particular reason. Are there ones you think we should add=3F

Are you including all of the IET=46= transport security protocols=3F If not, why not=3F =46or the non-IET=46 = protocols, why these=3F The intro to Sec 3 says they are =E2=80=9Csecurit= y protocols that are currently used to protect data=E2=80=9D.&=23160;

As discussed a while back, we are including any and all transport se= curity protocols, inside and out of the IET=46. We could probably clean u= p the rationale a bit to make that necessary condition more clear.&=23160= ;

    Terminology (sec 2):

    • Is =E2=80=98network security layer=E2=80=99 a well-de= fined term=3F Does it mean something like =E2=80=9Ca security service pro= vided by the network layer to the transport layer=E2=80=9D=3F Maybe worth= including a definition. &=23160;

    • Can security features exist above the transport layer=3F&=23160;
    Yes =E2=80=94 see&=23160;https://tools.ietf.org/html/draft-friel-tls= -over-http-00&=23160;as an example.

    gQUIC (sec 3.4)

    R=46Cs take a long time to publish and live forever. Given that, does doc= umenting gQUIC make sense in that context=3F Do you expect it to be aroun= d for a long time=3F Are there functional differences from QUIC w/ TLS th= at distinguish it=3F&=23160;
    &=23160;
    In my opinion, it makes sense to document gQUIC. The crypto core and= integration are fundamentally different and deserving of their own secti= on. &=23160;

      MinimalT (sec 3.5)

      I confess I=E2=80=99ve never heard of it. The draft doesn=E2=80=99t inclu= de a citation. &=23160;

      There is a citation, though the formatting is borked. I=E2=80=99ll f= ix this.

      Is there no R=46C=3F &=23160;
      =

      No.

      Seems odd to me that it is =E2=80=9C= built on top of a widespread directory service=E2=80=9D but the directory= service isn=E2=80=99t identified. &=23160;

      We can certainly go into more details here. I filed&=23160;https://github.com/mami-project/draft-pauly-transport-security/issu= es/23.
        --5aae4f32_431bd7b7_4a38-- From nobody Sun Mar 18 04:42:19 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608B81270A7 for ; Sun, 18 Mar 2018 04:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 b5j7obGoGq3L for ; Sun, 18 Mar 2018 04:42:15 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124931242F5 for ; Sun, 18 Mar 2018 04:42:15 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id h76so10493342wme.4 for ; Sun, 18 Mar 2018 04:42:14 -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=tSd3atE0cWEGHJwMGssB5U7qn+oDyEQKm3WopxhdC9c=; b=KBcHbslnWcDLYpb5caKpwL2ipDAoM2EWdzi+fG2zBD+525YMN4sompWfsxw5bWeedw VAknvFAoUYApP5tLEVm6ET9aiIBZ5xgzZPup0yjFMugzD3Dc06L80xRAlDOxbBY2zm68 hRcWMTDRbKU55WHZwlR4NDp83h4QJ59r1NtshS8Lx8bjuMOStFMoK7zi1f5jOAd3j1LN wkChxsA2vkELDmv+M4rFJWp+TZxpSaYS3zV3YG2ijU+4fcWSZMAS6te8T0IISM2N9/qZ HFvNyWvAfDflQ5UFErM3ozKfWDyNVY/lfbnVQPkhMA+ZSR6IPqB9Oo4X9/08Y1Hdu3Hr f5aA== 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=tSd3atE0cWEGHJwMGssB5U7qn+oDyEQKm3WopxhdC9c=; b=c9JpM9xdK9IDuf3J6j9nTB3wq0RyYWKjiFABhLLtSYqp2e1/DS88G35Oqws7C0Wjb3 15Nn4TVtoUMiaKLRpea8v8GqqJUBY67nZCKNq5MJmFxR4QKwSGM6bOGH6DMW9/wiDaWX HhV5jRtIfQGC28BUtXGmy+aju1szCiLDc1qGh4XvlAdOp0KrnS4PIKZYiza4aojA+HkD uG6R//tscpEdA9g6J5eXnDgtaTLpZrzLsHcNxsALtATmUM6DDrweByQ5n78m3emNeb0u 2YdlLl25c3aMqdCocMNXMnTcRFm9hZyjtpayf2lTVxHlHOkKIk69zn+wHMIVikWHFD4z A5Ew== X-Gm-Message-State: AElRT7FsutN7gkdfJFKvSOSFyh5+7Q/LbgddFjUeshi0dzKC9BDLQPm4 s9la/fXgAFXngjpDMHK2JrU= X-Google-Smtp-Source: AG47ELs3b3BfHuRUMeaJ3bcOzhn810PkoktDeAkTdvgBxUhcDaVGvNfxpADUCapDq5l1K4bfIH8tAw== X-Received: by 10.28.109.78 with SMTP id i75mr6467281wmc.61.1521373333449; Sun, 18 Mar 2018 04:42:13 -0700 (PDT) Received: from [172.19.153.183] ([2001:67c:1232:144:4105:9b81:25f8:ed57]) by smtp.gmail.com with ESMTPSA id 124sm11169005wms.25.2018.03.18.04.42.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 04:42:12 -0700 (PDT) From: "Aaron Falk" To: "Christopher Wood" Cc: "Tommy Pauly" , "Colin Perkins" , "Kyle Rose" , "taps WG" Date: Sun, 18 Mar 2018 11:42:13 +0000 X-Mailer: MailMate (1.11r5462) Message-ID: <1AEE2CB3-F040-4B06-9AE4-FA644EB367FF@gmail.com> In-Reply-To: <5e97ce34-abb6-499c-a5b4-f86ba41ab15d@Spark> References: <5e97ce34-abb6-499c-a5b4-f86ba41ab15d@Spark> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_BFD5CEB8-2B01-4A0C-814B-3C04413638C0_=" Archived-At: Subject: Re: [Taps] comments on draft-pauly-taps-transport-security-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 11:42:17 -0000 --=_MailMate_BFD5CEB8-2B01-4A0C-814B-3C04413638C0_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Thanks, Chris. One reply inline. --aaron On 18 Mar 2018, at 11:36, Christopher Wood wrote: > Hi Aarron, > > Thanks for the feedback. Please see inline for responses. > > Best, > Chris > > On Mar 17, 2018, 2:53 PM +0000, Aaron Falk , = > wrote: >> A few comments on the draft below. >> --aaron >> Introduction (sec 1): >> I think it=E2=80=99s missing a statement describing why you chose this= set = >> of protocols. You point out why you don=E2=80=99t include auth-only = >> protocols but why (only) these? > > No particular reason. Are there ones you think we should add? The set looks a little random but I=E2=80=99m not knowledgable and perhap= s = that=E2=80=99s a misimpression. Like, why include MinimalT? Does anyone= use = it? > >> Are you including all of the IETF transport security protocols? If = >> not, why not? For the non-IETF protocols, why these? The intro to Sec = >> 3 says they are =E2=80=9Csecurity protocols that are currently used to= = >> protect data=E2=80=9D. > > As discussed a while back, we are including any and all transport = > security protocols, inside and out of the IETF. We could probably = > clean up the rationale a bit to make that necessary condition more = > clear. >> >> >> Terminology (sec 2): >> >> =E2=80=A2 > Is =E2=80=98network security layer=E2=80=99 a well-defined= term? Does it = >> mean something like =E2=80=9Ca security service provided by the networ= k = >> layer to the transport layer=E2=80=9D? Maybe worth including a definit= ion. >> > Agreed. I = > filed=C2=A0https://github.com/mami-project/draft-pauly-transport-securi= ty/issues/24. >> >> =E2=80=A2 Can security features exist above the transport layer? >> > Yes =E2=80=94 = > see=C2=A0https://tools.ietf.org/html/draft-friel-tls-over-http-00=C2=A0= as an = > example. >> >> =E2=80=A2 >> gQUIC (sec 3.4) >> RFCs take a long time to publish and live forever. Given that, does = >> documenting gQUIC make sense in that context? Do you expect it to be = >> around for a long time? Are there functional differences from QUIC w/ = >> TLS that distinguish it? >> > In my opinion, it makes sense to document gQUIC. The crypto core and = > integration are fundamentally different and deserving of their own = > section. >> >> >> MinimalT (sec 3.5) >> I confess I=E2=80=99ve never heard of it. The draft doesn=E2=80=99t in= clude a = >> citation. > > There is a citation, though the formatting is borked. I=E2=80=99ll fix = this. > >> Is there no RFC? > > No. > >> Seems odd to me that it is =E2=80=9Cbuilt on top of a widespread direc= tory = >> service=E2=80=9D but the directory service isn=E2=80=99t identified. > > We can certainly go into more details here. I = > filed=C2=A0https://github.com/mami-project/draft-pauly-transport-securi= ty/issues/23. >> >> --=_MailMate_BFD5CEB8-2B01-4A0C-814B-3C04413638C0_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
        <= p dir=3D"auto">Thanks, Chris. One reply inline.

        --aaron

        On 18 Mar 2018, at 11:36, Christopher Wood wrote:

        Hi Aarron,

        Thanks for the feedback. Please see inline for responses.

        Best,
        Chris

        On Mar 17, 2018, 2:53 PM +0000, Aaron Falk <aaron.falk@gmail.com>, = wrote:

        A few comme= nts on the draft below.
        --aaron
        Introduction (sec 1):
        I think it=E2=80=99s missing a statement describing why you chose this se= t of protocols. You point out why you don=E2=80=99t include auth-only pro= tocols but why (only) these?

        No particular reason. Are there ones you thi= nk we should add?

        The set looks a little random but I=E2=80=99= m not knowledgable and perhaps that=E2=80=99s a misimpression. Like, why= include MinimalT? Does anyone use it?

        Are you including all of the IETF transport security protocols= ? If not, why not? For the non-IETF protocols, why these? The intro to Se= c 3 says they are =E2=80=9Csecurity protocols that are currently used to = protect data=E2=80=9D.

        As discussed a while back, we are including = any and all transport security protocols, inside and out of the IETF. We = could probably clean up the rationale a bit to make that necessary condit= ion more clear.

        Terminology= (sec 2):

        =E2=80=A2 > Is =E2=80=98network security layer=E2=80=99 a well-defined= term? Does it mean something like =E2=80=9Ca security service provided b= y the network layer to the transport layer=E2=80=9D? Maybe worth includin= g a definition.

        Agreed. I filed=C2=A0https://github.com/mami-project/draft-pauly-transport-security/= issues/24.

        =E2=80=A2 C= an security features exist above the transport layer?

        Yes =E2=80=94 see=C2=A0http= s://tools.ietf.org/html/draft-friel-tls-over-http-00=C2=A0as an examp= le.

        =E2=80=A2 gQUIC (sec 3.4)
        RFCs take a long time to publish and live forever. Given that, does docum= enting gQUIC make sense in that context? Do you expect it to be around fo= r a long time? Are there functional differences from QUIC w/ TLS that dis= tinguish it?

        In my opinion, it makes sense to document gQ= UIC. The crypto core and integration are fundamentally different and dese= rving of their own section.

        MinimalT (s= ec 3.5)
        I confess I=E2=80=99ve never heard of it. The draft doesn=E2=80=99t inclu= de a citation.

        There is a citation, though the formatting i= s borked. I=E2=80=99ll fix this.

        Is there no= RFC?

        No.

        Seems odd t= o me that it is =E2=80=9Cbuilt on top of a widespread directory service=E2= =80=9D but the directory service isn=E2=80=99t identified.

        We can certainly go into more details here. = I filed=C2=A0https://github.com/mami-pro= ject/draft-pauly-transport-security/issues/23.



        --=_MailMate_BFD5CEB8-2B01-4A0C-814B-3C04413638C0_=-- From nobody Sun Mar 18 04:46: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 133891270A7 for ; Sun, 18 Mar 2018 04:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 i2HsJaCy7Iz0 for ; Sun, 18 Mar 2018 04:46:27 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 2EF671275FD for ; Sun, 18 Mar 2018 04:46:27 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id l16so1128848wmh.3 for ; Sun, 18 Mar 2018 04:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=nxyHEGUrb0t/GILqbO6TZn1nPB/MZBJBiNR5tP2Zv4A=; b=WREIrbUC1YTMshyPbvfMxO4+Zx69+AW22cpYQCSDTHT4BxQkt37SqyBkgkdq50Qk4j MbYDEkAzmdsCvNuiznsuSzO98ZolrclFhN+oVG419xVXaeshWTOCj7LCrruJxom3ZDiL DWYAtV2FAujx1QeZGFQaWZWGYRBtoK+/Lz13mRlXsTADNWju4H+tc59uGPYYpUzLJ80W 1EUW6QIzJQ+HPnqho0GnGbPoZLzHwJFi/JjbgvaLL9YcmTUBylRE8foWPh0/GvzKEB5J f4mkLT545cpFTJdkDC6nrhgwCaHg37vdGWgBtH8FcnZyaxxBMbzvKjm6JxPKwfYq6AJt oBVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=nxyHEGUrb0t/GILqbO6TZn1nPB/MZBJBiNR5tP2Zv4A=; b=H50G4awFVe3UvRM9FrPvG844ds+Z0Yg2OGZDsJq7v01TI4nr7NeNAe+qTxzq473BMb Y+e4um6VoZ4SJuv4H5H4TUUTq7tC8eS8idWpj+fkAhMZllMZzIPJG+P/kLEtOFgKxxUK kfSwFzCO+bNYo7xYI1uGqk/k9EWob9/kPe3SgKHMWTpeEJa2JTbzTEXfeC1jysVoUsDv cPT08DCbsn+HX0zvUnn9ro1f5xUNHvBOLsgoCZofnM6yYqk26i+ou/ZOHsfJ+D+BmDpO Q8Hxzqh3cS4uaLsKhsExjNWAq6SNWe3jcMxS1SlszX0d9xxcaz1ZK2ac171kOr3IMlYS L2/g== X-Gm-Message-State: AElRT7HA8jsh1Twh/UEDV+qOVnMgxLBPZfhQ7PUkaNa7mQbYFkpBjSky 0f8gNVXbfEzTPBSKn+5yFw8= X-Google-Smtp-Source: AG47ELtZ41G8ApVmCggtJ95HLncl0p9x127LRv0MLThgbM7qKVSEwMp68r92EXmdWi1vTq+nMe4oEQ== X-Received: by 10.28.196.143 with SMTP id u137mr5559679wmf.74.1521373585608; Sun, 18 Mar 2018 04:46:25 -0700 (PDT) Received: from [2001:67c:1232:144:e8d9:1c18:70:0] ([2001:67c:1232:144:598f:ad08:3f4f:e1c4]) by smtp.gmail.com with ESMTPSA id e10sm12124840wrh.38.2018.03.18.04.46.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 04:46:25 -0700 (PDT) Date: Sun, 18 Mar 2018 11:46:13 +0000 From: Christopher Wood To: Aaron Falk Cc: Tommy Pauly , Colin Perkins , Kyle Rose , taps WG Message-ID: In-Reply-To: <1AEE2CB3-F040-4B06-9AE4-FA644EB367FF@gmail.com> References: <5e97ce34-abb6-499c-a5b4-f86ba41ab15d@Spark> <1AEE2CB3-F040-4B06-9AE4-FA644EB367FF@gmail.com> X-Readdle-Message-ID: c8da3620-69cb-4f10-a60e-1eadcc046daf@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5aae5190_b03e0c6_4a38" Archived-At: Subject: Re: [Taps] comments on draft-pauly-taps-transport-security-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 11:46:29 -0000 --5aae5190_b03e0c6_4a38 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mar 18, 2018, 11:42 AM +0000, Aaron =46alk , w= rote: > Thanks, Chris. One reply inline. > --aaron > On 18 Mar 2018, at 11:36, Christopher Wood wrote: > > Hi Aarron, > > > > Thanks for the feedback. Please see inline for responses. > > > > Best, > > Chris > > > > On Mar 17, 2018, 2:53 PM +0000, Aaron =46alk = , wrote: > > > A few comments on the draft below. > > > --aaron > > > Introduction (sec 1): > > > I think it=E2=80=99s missing a statement describing why you chose t= his set of protocols. You point out why you don=E2=80=99t include auth-on= ly protocols but why (only) these=3F > > No particular reason. Are there ones you think we should add=3F > The set looks a little random but I=E2=80=99m not knowledgable and perh= aps that=E2=80=99s a misimpression. Like, why include MinimalT=3F Does an= yone use it=3F As far as I know, no. Though the design is sufficiently unique that we fe= lt it best to include. Also, it shares features and inspired designs of n= ewer ((more) widely used) protocols. (I=E2=80=99m speaking of 0-RTT hands= hakes here.) Best, Chris --5aae5190_b03e0c6_4a38 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

        On Mar 18, 2018, 11:42 AM +0000, Aaron =46alk <aaron.falk=40gmail.com&= gt;, wrote:

        Thanks, Chris. One reply inline.

        --aaron

        On 18 Mar 2018, at 11:36, Christopher Wood wrote:

        =

        Hi Aarron,

        Thanks for the feedback. Please see inline for responses.

        Best,
        Chris

        On Mar 17, 2018, 2:53 PM +0000, Aaron =46alk <aaron.falk=40gmail.com&g= t;, wrote:

        A few comments on the draft below.
        --aaron
        Introduction (sec 1):
        I think it=E2=80=99s missing a statement describing why you chose this se= t of protocols. You point out why you don=E2=80=99t include auth-only pro= tocols but why (only) these=3F

        No particular reason. Are there ones you think we sho= uld add=3F

        The set looks a little random but I=E2=80=99m not kno= wledgable and perhaps that=E2=80=99s a misimpression. Like, why include M= inimalT=3F Does anyone use it=3F &=23160;

        As far as I know, no. Though the design is sufficiently unique that = we felt it best to include. Also, it shares features and inspired designs= of newer ((more) widely used) protocols. (I=E2=80=99m speaking of 0-RTT = handshakes here.)

        Best,
        Chris
        --5aae5190_b03e0c6_4a38-- From nobody Tue Mar 20 10:57:01 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 ADEE3127201 for ; Tue, 20 Mar 2018 10:56:59 -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 5ignpixMQrE3 for ; Tue, 20 Mar 2018 10:56:57 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 9890A126BF7 for ; Tue, 20 Mar 2018 10:56:57 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id z8so2628423wrh.7 for ; Tue, 20 Mar 2018 10:56: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:mime-version; bh=l8mkongp1w1jHGgD7Bu4pZLIdJ2CAj0XW2Z31z3N47M=; b=ClIWh1vnspoXIg+d6ysF1G78jlRiDgZn5nkRtmgRKzeGBQFhqUAQA7zGg5quB33zkQ eGLRsD+m8FLY7CA4OObFp2C5/CzDUZ/6C+lR00gF0zOL00+QNLYYVh8X2214DqNcye5P k80c9+yyHQ8L40Y1PLR8NLZHb1GBBwRbxucn01GpvxQoVvaUchLgXPfry1SkYci1FQLy lGkcsWxzXBjEOGjRjtqUC0oNAoItrGKsyQpivrJltLH2LaWkPWIMWI10jJDMvLf5IvXS 6vRZLcgmu1QIUmNmWFp9y4d5DqmUZzyOJcXQg4m41CjSpGTswuBboDPtH/OubzJo3/b3 RFOw== 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=l8mkongp1w1jHGgD7Bu4pZLIdJ2CAj0XW2Z31z3N47M=; b=o8Q4jO0LXRiLdQY7PKNlvluXqdrT2eCECGNsFYs2UQNjwYr10ckCrPUYlDjxsHkeXj 1vnbZMlqhFH3/gGhZF5WDWQPsuLCJEroDSBra9CpTYHF0mZ4E80yTduRWA+oDCuz2Lig N87Bghl3h2nD3uxEqOoPjg3JInDJs4RovQwz7LIr+48ZDKGy0Ec9rcdvpFZdwZNAgNpT jASCp4xWXHTsuqlvWtLYICTLdWZT2kNyWa0wekiZmdu/k5fYIA6j1OqMeD5kNNjvOotz 9RlfysDd0EuCrzb/qQXjAQUF1/rEfiSFCISG7H6Mym2d1fRbRg4c+RcE1mpbbPcuv9qu Cgwg== X-Gm-Message-State: AElRT7Ftm/38tmbctGZ/2E1zGtvpr9Dp4sHF1NYHH3mhXIMTOvTWMODW II5E77kvgirT7pagnhR/OLfynVfg X-Google-Smtp-Source: AG47ELtxWlRM0l7dJQzstfgYhrz8bF0xB0sxLQzi0bVBoMOwRB53G6aniZmDZZSNp+z71SiobMCKLA== X-Received: by 10.223.198.70 with SMTP id u6mr13284784wrg.216.1521568615988; Tue, 20 Mar 2018 10:56:55 -0700 (PDT) Received: from [172.19.153.223] ([2001:67c:1232:144:4d66:65c7:25ad:d8dd]) by smtp.gmail.com with ESMTPSA id 124sm319335wmv.19.2018.03.20.10.56.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 10:56:53 -0700 (PDT) From: "Aaron Falk" To: "Anna Brunstrom" , "Tommy Pauly" , "Theresa Enghardt" , "Karl-Johan Grinnemo" , "Tom Jones" , "Philipp S. Tiesel" , "Colin Perkins" , "Michael Welzl" Cc: "taps WG" Date: Tue, 20 Mar 2018 17:56:53 +0000 X-Mailer: MailMate (1.11r5462) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_31680782-9F0F-4BDB-9991-7F2B919FD0DE_=" Archived-At: Subject: [Taps] comments on draft-brunstrom-taps-impl-00 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2018 17:57:00 -0000 --=_MailMate_31680782-9F0F-4BDB-9991-7F2B919FD0DE_= Content-Type: text/plain; format=flowed; markup=markdown Comments on the draft. HTH. --aaron ---- General Should the draft address the issue of applications that want to go directly to a specific transport protocol and bypass TAPS? For example, this may affect capacity profiles predictions. > 4.2. Branching Order-of-Operations ... > usable DNS results on one network may > not necessarily be the same as DNS results on another network due > to > local network entities, supported address families, or enterprise > network configurations. CDN cache assignment is another reason DNS results may vary by network interface. > 4.5. Completing Establishment ... > an implementation may choose to hold > onto fully established leaf nodes that were not the first to > establish for use in future connections, but this approach is not > recommended since those attempts were slower to connect and may > exhibit less desirable properties. Seems like there are other good reasons not to encourage holding duplicate connections open such as consuming valuable server resources. > 6.2. Handling Path Changes Is there a realistic case where, say, a routing change causes a protocol to stop working. Should TAPS deal with this? > 10. Rendezvous and Environment Discovery ... > o Gathering Remote Endpoint Candidates As in sec 4, I think it may be worth mentioning that DNS resolutions may vary by interface (e.g., with CDNS). Perhaps there should be a recommendation to perform DNS lookups separately for each interface to get the remote IP address. --=_MailMate_31680782-9F0F-4BDB-9991-7F2B919FD0DE_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

        Comments on the draft. HTH.

        --aaron

        General

        Should the draft address the issue of applications that w= ant to go directly to a specific transport protocol and bypass TAPS? For= example, this may affect capacity profiles predictions.

        4.2. Branching Order-of-Operations

        ...

        usable DNS results on one network may
        not necessarily be the same as DNS results on another network due to local network entities, supported address families, or enterprise
        network configurations.

        CDN cache assignment is another reason DNS results may va= ry by network interface.

        4.5. Completing Establishment

        ...

        an implementation may choose to hold
        onto fully established leaf nodes that were not the first to
        establish for use in future connections, but this approach is not
        recommended since those attempts were slower to connect and may
        exhibit less desirable properties.

        Seems like there are other good reasons not to encourage = holding duplicate connections open such as consuming valuable server reso= urces.

        6.2. Handling Path Changes

        Is there a realistic case where, say, a routing change ca= uses a protocol to stop working. Should TAPS deal with this?

        1. Rendezvous and Environment Discovery

        ...

        o Gathering Remote Endpoint Candidates

        As in sec 4, I think it may be worth mentioning that DNS = resolutions may vary by interface (e.g., with CDNS). Perhaps there shoul= d be a recommendation to perform DNS lookups separately for each interfac= e to get the remote IP address.

        --=_MailMate_31680782-9F0F-4BDB-9991-7F2B919FD0DE_=-- From nobody Wed Mar 21 04:34:54 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55882126B6D for ; Wed, 21 Mar 2018 04:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 wlCq9ay9MA_j for ; Wed, 21 Mar 2018 04:34:51 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 E885D124207 for ; Wed, 21 Mar 2018 04:34:50 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id F3BFA8C4F299D for ; Wed, 21 Mar 2018 11:34:46 +0000 (GMT) Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 21 Mar 2018 11:34:48 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0361.001; Wed, 21 Mar 2018 19:34:44 +0800 From: "Roni Even (A)" To: "taps@ietf.org" Thread-Topic: conflicting policies Thread-Index: AdPBB/k45S2Yjuu3QGSMn3yUBHGnNA== Date: Wed, 21 Mar 2018 11:34:44 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD86DE4C@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.44] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD86DE4CDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Taps] conflicting policies X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 11:34:52 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD86DE4CDGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I made this comment in the past in QUIC when discussing migration. One policy may be prefer wifi over cellular network, Second policy prefers quic cove TCP Now I walk into my house and my cellphone has HTTP over QUIC. At home will switch to wifi but quic is not supported on the wifi so will f= all back to TCP. This contradicts the second policy. So two options wifi TC= P or cellular QUIC , how to decide? Roni Even --_000_6E58094ECC8D8344914996DAD28F1CCD86DE4CDGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        Hi,

        I made this comment in the past in QUIC when discuss= ing migration.

         

        One policy may be prefer wifi over cellular network,=

        Second policy prefers quic cove TCP

         

        Now I walk into my house and my cellphone has HTTP o= ver QUIC.

        At home will switch to wifi but quic is not supporte= d on the wifi so will fall back to TCP. This contradicts the second policy.= So two options wifi TCP or cellular QUIC , how to decide?

         

        Roni Even

        --_000_6E58094ECC8D8344914996DAD28F1CCD86DE4CDGGEMM506MBXchina_-- From nobody Wed Mar 21 04:57:37 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 9C043126CD6 for ; Wed, 21 Mar 2018 04:57:35 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, 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 RkB8e1d2VIN7 for ; Wed, 21 Mar 2018 04:57:33 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA24C124207 for ; Wed, 21 Mar 2018 04:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4340; q=dns/txt; s=iport; t=1521633453; x=1522843053; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=q6ET9W2Zn2C4HHTrVGVKKgZuW6yzsSY0S/Z1JtGzqos=; b=gpftBhZlmx6X9w3ijOfbg2dmbXCGk1sCh4MqJw9TJzNlmFxJ6qg/ZDcv 6ElRHVXvgAA9OucBcJfrYpL2gv18EfyJEZOEy1VA0ACHTxF7ZYhkrPaPd 0kQYZ34DpNNb2+qWdHhOzZBKJsfoH1miynTxXodBbrPwTd36D6gvcVap+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AQDjR7Ja/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9YXAoCoNSh3+NDIFxgRCGcYw3FIF1CxgNhGACGoM4ITQYAQI?= =?us-ascii?q?BAQEBAQECayiFJQEBAQQBASEROgkSAgEIDgMDAQIDAh8HAgICHwYLFQgIAgQBE?= =?us-ascii?q?huEWwMVD6ozgiCHEA2BLIIOgQmFSHKBU0CBDiKCOi6CUUIBAQIBAYFFGBeCajC?= =?us-ascii?q?CJAOMPYUChk0vCQKGDIYHgx+BRUCDPodtiTM7hiECERMBgSUBHDiBIBkEDQhwF?= =?us-ascii?q?RkhKgGCGAmCQo4EcAGOV4EWAQE?= X-IronPort-AV: E=Sophos;i="5.48,340,1517875200"; d="scan'208";a="87515413" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2018 11:57:32 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w2LBvWxH018680 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Mar 2018 11:57:32 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 21 Mar 2018 07:57:31 -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, 21 Mar 2018 07:57:31 -0400 From: "Eric Vyncke (evyncke)" To: Fernando Gont , taps WG Thread-Topic: [Taps] Problem Statement Regarding IPv6 Address Usage (Fwd: New Version Notification for draft-gont-taps-address-usage-problem-statement-00.txt) Thread-Index: AQHTsJSc/1x7mhbuH0O6lc5hB2k5IKPa+XgA Date: Wed, 21 Mar 2018 11:57:31 +0000 Message-ID: <963E6E0B-6DB3-4F18-A4B7-34B19D9536AB@cisco.com> References: <151981841061.5233.1390739876555645192.idtracker@ietfa.amsl.com> <87117012-dc08-d83c-2dcb-11347b6e5e63@si6networks.com> In-Reply-To: <87117012-dc08-d83c-2dcb-11347b6e5e63@si6networks.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.71.158] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Taps] Problem Statement Regarding IPv6 Address Usage (Fwd: New Version Notification for draft-gont-taps-address-usage-problem-statement-00.txt) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 11:57:36 -0000 RmVybmFuZG8NCg0KSnVzdCBicm93c2VkIHRvZGF5IChhdCBUQVBTIDotTyApIHlvdXIgZHJhZnQg YW5kIGludGVyZXN0aW5nIDstKQ0KDQpZb3UgbWF5IG1ha2UgY2xlYXIgaW4gNy4xIChpbmNvbWlu ZyBjb25uZWN0aW9ucykgdGhhdCB0aGVyZSBhcmUgc29tZSBhcHBsaWNhdGlvbnMgbGlzdGVuaW5n IHRvIGEgcHJlZml4LCBzdWNoIGFzIGEgLzY0DQoNCi3DqXJpYw0KDQpPbiAyOC8wMi8xOCAxMjoy OSwgIlRhcHMgb24gYmVoYWxmIG9mIEZlcm5hbmRvIEdvbnQiIDx0YXBzLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIGZnb250QHNpNm5ldHdvcmtzLmNvbT4gd3JvdGU6DQoNCiAgICBGb2xr cywNCiAgICANCiAgICBXZSBoYXZlIHJlcG9zdGVkIG91ciBJLUQgb24gdGhlIHByb2JsZW0gc3Rh dGVtZW50IHJlZ2FyZGluZyBhZGRyZXNzDQogICAgdXNhZ2UsIHRoaXMgdGltZSB0YXJnZXRpbmcg dGhpcyB3b3JraW5nIGdyb3VwLg0KICAgIA0KICAgIEl0IGlzIGF2YWlsYWJsZSBhdDoNCiAgICA8 aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdvbnQtdGFwcy1hZGRy ZXNzLXVzYWdlLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dD4NCiAgICANCiAgICBUaGUgY2hhbmdl cyBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uICh0YXJnZXRlZCBhdCA2bWFuKSBib2lscyBkb3du IHR3bzoNCiAgICANCiAgICAqIFR3byBwYXJhZ3JhcGhzIHN1Z2dlc3RpbmcgZnVydGhlciB3b3Jr IG9yIHNvbHV0aW9ucyBoYXZlIGJlZW4gcmVtb3ZlZA0KICAgIChpbiByZXNwb25zZSB0byBFcmlr IEtsaW5lJ3MgY29tbWVudHMpDQogICAgDQogICAgKiBBIG5vdGUvZGlzY2xhaW1lciB3YXMgYWRk ZWQgbm90aW5nIHRoYXQgdGhlIGN1cnJlbnQgdmVyc2lvbiBmb2N1c2VzIG9uDQogICAgSVB2NiBh ZGRyZXNzZXMsIGJ1dCBhIHN1YnNlcXVlbnQgcmV2aXNpb24gb2YgdGhlIEktRCBtaWdodCBkaXNj dXNzIElQdjQNCiAgICBhZGRyZXNzZXMgdG9vLg0KICAgIA0KICAgIEFueSBjb21tZW50cyB3aWxs IGJlIGFwcHJlY2lhdGVkLg0KICAgIA0KICAgIFRoYW5rcyENCiAgICANCiAgICBCZXN0IHJlZ2Fy ZHMsDQogICAgRmVybmFuZG8NCiAgICANCiAgICANCiAgICANCiAgICANCiAgICAtLS0tLS0tLSBG b3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KICAgIFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3INCiAgICBkcmFmdC1nb250LXRhcHMtYWRkcmVzcy11c2FnZS1wcm9ibGVtLXN0 YXRlbWVudC0wMC50eHQNCiAgICBEYXRlOiBXZWQsIDI4IEZlYiAyMDE4IDAzOjQ2OjUwIC0wODAw DQogICAgRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQogICAgVG86IEZlcm5hbmRvIEdv bnQgPGZnb250QHNpNm5ldHdvcmtzLmNvbT4sIE1hZGVsZWluZSBHYXJjaWEgQ29yYm8NCiAgICA8 bWFkZWxlbi5nYXJjaWExNkBnbWFpbC5jb20+LCBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBo dWl0ZW1hLm5ldD4sDQogICAgTWFkZWxlbiBDb3JibyA8bWFkZWxlbi5nYXJjaWExNkBnbWFpbC5j b20+LCBHdWlsbGVybW8gR29udA0KICAgIDxnZ29udEBzaTZuZXR3b3Jrcy5jb20+DQogICAgDQog ICAgDQogICAgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdvbnQtdGFwcy1hZGRyZXNzLXVz YWdlLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dA0KICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgRmVybmFuZG8gR29udCBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgIElFVEYgcmVw b3NpdG9yeS4NCiAgICANCiAgICBOYW1lOgkJZHJhZnQtZ29udC10YXBzLWFkZHJlc3MtdXNhZ2Ut cHJvYmxlbS1zdGF0ZW1lbnQNCiAgICBSZXZpc2lvbjoJMDANCiAgICBUaXRsZToJCVByb2JsZW0g U3RhdGVtZW50IFJlZ2FyZGluZyBJUHY2IEFkZHJlc3MgVXNhZ2UNCiAgICBEb2N1bWVudCBkYXRl OgkyMDE4LTAyLTI3DQogICAgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICBQYWdl czoJCTE3DQogICAgVVJMOg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1nb250LXRhcHMtYWRkcmVzcy11c2FnZS1wcm9ibGVtLXN0YXRlbWVudC0wMC50eHQN CiAgICBTdGF0dXM6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt Z29udC10YXBzLWFkZHJlc3MtdXNhZ2UtcHJvYmxlbS1zdGF0ZW1lbnQvDQogICAgSHRtbGl6ZWQ6 DQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdvbnQtdGFwcy1hZGRyZXNz LXVzYWdlLXByb2JsZW0tc3RhdGVtZW50LTAwDQogICAgSHRtbGl6ZWQ6DQogICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1nb250LXRhcHMtYWRkcmVzcy11c2Fn ZS1wcm9ibGVtLXN0YXRlbWVudC0wMA0KICAgIA0KICAgIA0KICAgIEFic3RyYWN0Og0KICAgICAg IFRoaXMgZG9jdW1lbnQgYW5hbHl6ZXMgdGhlIHNlY3VyaXR5IGFuZCBwcml2YWN5IGltcGxpY2F0 aW9ucyBvZiBJUHY2DQogICAgICAgYWRkcmVzc2VzIGJhc2VkIG9uIGEgbnVtYmVyIG9mIHByb3Bl cnRpZXMgKHN1Y2ggYXMgYWRkcmVzcyBzY29wZSwNCiAgICAgICBzdGFiaWxpdHksIGFuZCB1c2Fn ZSB0eXBlKSwgYW5kIGlkZW50aWZpZXMgZ2FwcyB0aGF0IGN1cnJlbnRseQ0KICAgICAgIHByZXZl bnQgc3lzdGVtcyBhbmQgYXBwbGljYXRpb25zIGZyb20gbGV2ZXJhZ2luZyB0aGUgaW5jcmVhc2Vk DQogICAgICAgZmxleGliaWxpdHkgYW5kIGF2YWlsYWJpbGl0eSBvZiBJUHY2IGFkZHJlc3Nlcy4N CiAgICANCiAgICANCiAgICANCiAgICANCiAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCiAgICANCiAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0KICAgIA0KICAgIA0KICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgVGFw cyBtYWlsaW5nIGxpc3QNCiAgICBUYXBzQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90YXBzDQogICAgDQoNCg== From nobody Wed Mar 21 06:29: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 7022412D952 for ; Wed, 21 Mar 2018 06:29:06 -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 zALtVek21O9D for ; Wed, 21 Mar 2018 06:29:04 -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 A285E12DA23 for ; Wed, 21 Mar 2018 06:29:04 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7778A340FB6 for ; Wed, 21 Mar 2018 14:29:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.25563); Wed, 21 Mar 2018 14:29:01 +0100 (CET) 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 ; Wed, 21 Mar 2018 14:28:59 +0100 (CET) Received: from dhcp-808c.meeting.ietf.org (account ietf@trammell.ch [31.133.128.140] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 49145121 for taps@ietf.org; Wed, 21 Mar 2018 14:28:59 +0100 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_2EBBC539-BB04-4082-8B1C-545B7D93550A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <61D43D2D-4C45-4AF5-94D9-92C9A0694902@trammell.ch> Date: Wed, 21 Mar 2018 13:28:57 +0000 To: taps WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Taps] Github repository for arch/interface/implementation drafts... X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 13:29:06 -0000 --Apple-Mail=_2EBBC539-BB04-4082-8B1C-545B7D93550A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii is https://github.com/taps-api/drafts. We're using the issue tracker at = https://github.com/taps-api/drafts/issues; please feel free to add = comments or file issues there. Cheers, Brian --Apple-Mail=_2EBBC539-BB04-4082-8B1C-545B7D93550A 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlqyXhkACgkQihK3vwvq RqNxJw/9ErXbCpXOXJTv091qrp4cgu8DcquaF1+cBQ3kDkoGaUcYvFM+ITY3rw5C +wt74Wu2Ir8nOn66Gw5m00UML00xpEfAo+VGV6m9zBm4MXjZUG0lY2g4aVMJJ0BC ppDp8jNp6Ucmyz4DU8PPtTHJCCXwK717H9M5F9LxnJVsxNA7TbSSJrNXpcac8tJx cmbOyIc8V6CRmuQ0K/I+CRXZqVpASBtnb3SjRwXvA4t0YC38ionj9lA8Wu0n0B/W 2ErKFQgsHcpqggRFFVFcKgwZisSIIIIc3K7LC2nQsqps2E31DK+s1LvTtLODYVEQ s46RCsy+C1eSouCj/VoPIpkn/21fgvS05vEU+maiIXbn8MBflGIbF/CfgHCKKo7x hMOm0SV0Z9T1EJ6tTR8fAnS3d9lbWfxpz98phijCNEMgZeaTp8aocq1wrXFc9NSt A6WTWXK7vp1IVLYb0/W5cQ+IwYhmqBv6d1cqyrgb4mig5cCnysKbmJJyhPyRSy3g bIHLaNdA/znJxZEtwRsSiLSCq0yDBZfTRdt3PYtTy/hd8bDfyAK5xGlZGsDDaImu P/lBIY/XCv4zFZBiCFclo1KDV1Ixai3h4/4AuVXLZS7OHlDDhnENWshdJU95zSvb CImEZdJc1bMl+6slBrcUoekmOUNUhtRnI6yyj5eoggGZJT8oHts= =OliS -----END PGP SIGNATURE----- --Apple-Mail=_2EBBC539-BB04-4082-8B1C-545B7D93550A-- From nobody Wed Mar 21 06:49:28 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 B16A012702E for ; Wed, 21 Mar 2018 06:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvJG5Nfrgjn5 for ; Wed, 21 Mar 2018 06:49:24 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9336B12E048 for ; Wed, 21 Mar 2018 06:49:24 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id i189so6489915wmf.0 for ; Wed, 21 Mar 2018 06:49:24 -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 :content-transfer-encoding; bh=9SD3SPTdb5bjayS3qSfKAGsWINJkxdwhakShx/4SXi0=; b=VDb6qtV9vXrlVEUfx3buKkybmXjDIdskJCVM6i1U7Sr/Gyi3O4/pFE/DhelGsk4272 uGi4t4mR35HTXjf3QLFsdQ6bwg5bTh82p6s8N3PQpnQzl+3pWd9nYIcgt7Auha/8CZTQ R77a87XNY6r6vi7raSH8Mm+csvhcpi9CCW4plYrbVq71kL5RncAoabMphjN0muSR84lv Emgx/mXKTPEJnV0VM9Om3LzSrmsOZPA1pfMpHScE4gNmPERvBJIqemkTgOJT2igvPAxB wfXB6s8g8UwZUJWWgSFvTbh4KZSUX/CBwOv9IBriMHPDm5tvRoazt3tkK867rXDjHqYR 3gkQ== 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 :content-transfer-encoding; bh=9SD3SPTdb5bjayS3qSfKAGsWINJkxdwhakShx/4SXi0=; b=AFkbndfUoJ76oRR8DhR9UksrBzfQ+iQ/pxqGLMzRuKMwb2rBkNs2Ully28lGbQFtuA 5OUNYoL+PyYGCTc5cluuG6XzSqm5fWvPxddLvAE8ExHLIabhJoM/JmjZsUKXBu+gR0y3 URxGZdIUznsbFoZgwNMcAb+BY8XrftS3nM0asO33S4mg3dNPPx2pYW5x/+J+gN/V5H5m slrDASRzz2cvdM/JCwxyPNuxuL+pWbM5urn7/Bph9tSSIbLU0fr00w8eRjUq0eP1z2/S BuBDiiMsNYKZJWXvbjDrpDN0s8uziZMkFgxpjZWFTQEnARfdp9PLOaNWFCZJ/Urbag0D I6TA== X-Gm-Message-State: AElRT7ERt7+X2eJvMcta9UkVAONnpXd2hHBgiKII1m4anY2ABPdtScpe xakrcbIvByciEHaTysXofyyuSxhSXgc= X-Google-Smtp-Source: AG47ELv90xYdRm3+Ph8o8v7wJgjNnoczOgr9AJWb8zPwVrkB597+hwLp5aS7AVzpjgRMUEWiN0PQdg== X-Received: by 10.28.197.205 with SMTP id v196mr2940463wmf.39.1521640162850; Wed, 21 Mar 2018 06:49:22 -0700 (PDT) Received: from [172.19.152.210] ([2001:67c:1232:144:dc05:c9d6:77ec:59af]) by smtp.gmail.com with ESMTPSA id f22sm9115235wmi.39.2018.03.21.06.49.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 06:49:22 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Wed, 21 Mar 2018 13:49:21 +0000 X-Mailer: MailMate (1.11r5462) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_CD5D6DCF-41E1-4472-81FF-F914BFD76391_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] New working group documents X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 13:49:27 -0000 --=_MailMate_CD5D6DCF-41E1-4472-81FF-F914BFD76391_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit At the TAPS wg meeting today, we discussed making several contributions to be working group documents. There was a strong consensus in the room to adopt all of these. If you weren’t in the room and have any objections to the working group developing these docs, this is the thread on which to voice them. The docs are: **A Survey of Transport Security Protocols** https://tools.ietf.org/html/draft-pauly-taps-transport-security-02 **An Architecture for Transport Services** https://tools.ietf.org/html/draft-pauly-taps-arch-00 **An Abstract Application Layer Interface to Transport Services** https://tools.ietf.org/html/draft-trammell-taps-interface-00 **Implementing Interfaces to Transport Services** https://tools.ietf.org/html/draft-brunstrom-taps-impl-00 --aaron & zahed TAPS wg chairs --=_MailMate_CD5D6DCF-41E1-4472-81FF-F914BFD76391_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

        At the TAPS wg meeting today, we discussed making several= contributions to be working group documents. There was a strong consens= us in the room to adopt all of these. If you weren=E2=80=99t in the room= and have any objections to the working group developing these docs, this= is the thread on which to voice them.

        The docs are:

        A Survey of Transport Security Protocols=
        https://tools.ietf.org/html/draft-pauly-tap= s-transport-security-02

        An Architecture for Transport Services https://tools.ietf.org/html/draft-pauly-taps-arch-00<= /p>

        An Abstract Application Layer Interface to Transp= ort Services
        https://tools.ietf.org/html/draft-trammell-taps-i= nterface-00

        Implementing Interfaces to Transport Services
        https://tools.ietf.org/html/draft-brunstrom-taps-impl= -00

        --aaron & zahed
        TAPS wg chairs

        --=_MailMate_CD5D6DCF-41E1-4472-81FF-F914BFD76391_=-- From nobody Wed Mar 21 07:20:52 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 DBDCD12DA2B for ; Wed, 21 Mar 2018 07:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 oIVgx3ATS-DR for ; Wed, 21 Mar 2018 07:20:48 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1E25A1271FD for ; Wed, 21 Mar 2018 07:20:48 -0700 (PDT) Received: from MacBook-2.local (unknown [IPv6:2001:67c:370:1999:50b2:8037:fa7c:5979]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2D7601B0025A; Wed, 21 Mar 2018 14:20:47 +0000 (GMT) Message-ID: <5AB26A42.2020903@erg.abdn.ac.uk> Date: Wed, 21 Mar 2018 14:20:50 +0000 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: "Roni Even (A)" CC: "taps@ietf.org" References: <6E58094ECC8D8344914996DAD28F1CCD86DE4C@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD86DE4C@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] conflicting policies X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 14:20:51 -0000 I personally think this is an important topic. The topic also appeared in the TAPS chartering, and my thoughts are currently: - I think we should ensure that the decisions made by TAPS systems are evident, at least in the logging. Implementations should not just provide "magic". - I'd expect the "standard" API produces deterministic outcomes. This seems to be helped by the app either asking high-level path properties: "give me an interactive treatment" or alternatively the API requesting specific network path properties: "do not use wifi", "prefer low latency", "interface must be > x Mbps", "mark as DSCP=x", etc. I'd argue that characterising the App, rather than the network treatment e.g., "I'm a video conf App", "I wish to send x MB", etc, is much less helpful for this "standard" TAPS interface. I am not against a developer or vendor utilising a range of "additional" properties which aply for a specific system and then can inform specific decisions. To me, at least, this sort of optimisation requires more "understanding" to interpret how to match the connection to set of candidate paths. Gorry On 21/03/2018, 11:34, Roni Even (A) wrote: > > Hi, > > I made this comment in the past in QUIC when discussing migration. > > One policy may be prefer wifi over cellular network, > > Second policy prefers quic cove TCP > > Now I walk into my house and my cellphone has HTTP over QUIC. > > At home will switch to wifi but quic is not supported on the wifi so > will fall back to TCP. This contradicts the second policy. So two > options wifi TCP or cellular QUIC , how to decide? > > Roni Even > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Mar 21 07:42:01 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 6605F12DA6C for ; Wed, 21 Mar 2018 07:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 sSb6XRNazEwt for ; Wed, 21 Mar 2018 07:41:57 -0700 (PDT) Received: from mail-in2.euro.apple.com (mail-in2.euro.apple.com [17.72.148.12]) (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 327CA12DA6A for ; Wed, 21 Mar 2018 07:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1521643313; x=2385556913; 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=l2z3m2Xtb2CgE5fBW5j6p9v/uTHELSNzTxggRGf9MQc=; b=OKZ6J7r3b9oOM2bf9qSqUWoPnYmaICcEAVKwH2pTcxT/IbzF0lqzui1pCi/cWPc3 QUeF7opuDe+Tt4F+KkfegF0tnDgz5uikOxLsh3tIl0GKqCilKGbbZFw6gAEhxNa5 bNG8OF0mvgP6DhB8qEXtmczYXNXaupzWDDtrYlz9/3rzEc15WUlcwkNTuKXgAN4g TSKP7snvm2IJPr+fFC8gumUP0HjtsS5GiyCT0Wu/d7V7ZmC0ddGFbOG8Ip7Qwk9E fay8AiKxcPpdZgxpoEJHv0b3Hhs8ETW+b6uyW1X8wFIOo7CN17pqSp8XdgYxeJJ3 pW5N6WnSoaUVIy3XDMe0Cw==; Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.euro.apple.com (Apple Secure Mail Relay) with SMTP id 66.29.28874.13F62BA5; Wed, 21 Mar 2018 14:41:53 +0000 (GMT) X-AuditID: 1148940c-d70db9e0000070ca-fe-5ab26f310aca Received: from crk-mmpp-sz03.euro.apple.com ( [17.66.12.165]) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id DA.8C.16087.13F62BA5; Wed, 21 Mar 2018 14:41:53 +0000 (GMT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.235.203.148] (unknown [17.235.203.148]) by crk-mmpp-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P5Y00GRC3HSCX60@crk-mmpp-sz03.euro.apple.com>; Wed, 21 Mar 2018 14:41:53 +0000 (GMT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <5AB26A42.2020903@erg.abdn.ac.uk> Date: Wed, 21 Mar 2018 14:41:52 +0000 Cc: "taps@ietf.org" Content-transfer-encoding: quoted-printable Message-id: <8BEAE99C-B389-4A32-869A-368AC0067397@apple.com> References: <6E58094ECC8D8344914996DAD28F1CCD86DE4C@DGGEMM506-MBX.china.huawei.com> <5AB26A42.2020903@erg.abdn.ac.uk> To: G Fairhurst , "Roni Even (A)" X-Mailer: Apple Mail (2.3458) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUi6GTOo2uYvynK4H2/mcXrttmMFp+OnWex uBPjwOzR8/kFk0fLkbesHkuW/GQKYI7isklJzcksSy3St0vgylj26CFrwQ+ZigtrX7M1MB4U 72Lk5JAQMJGY+egbWxcjF4eQwA4miec3tjHCJCZfnsoEYgsJ7GKU2P4ELM4rICjxY/I9li5G Dg5mAXWJKVNyIXrnMklMX/2cESQuLCAhsXlPIki5sICGxNMv/WBj2ARUJI5/28AMYnMK6Ek8 f/yNFcRmEVCVONE1GyzOLKAs8XhWIwuErS3x5N0FVoi1NhJrj0+HOqdSYtGGrawgq0QE/CSW TLGDuFhWYuXsu6wg50gITGGTuL77MNsERuFZSK6ehXD1LCQbFjAyr2IUz03MzNHNzDPSSy0t ytdLLCjISdVLzs/dxAgKd48pPDsYLx40PMQowMGoxMNrIbYxSog1say4MvcQowQHs5II77bP QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8KY/9ooQE0hNLUrNTUwtSi2CyTBycUg2M67cWqP2P f/pg7w6jEKc9KhZKS0q7uC92WczliBNlkpcR4oy5vO2X8XcJgwurZjqnXf7PYmsTrJz63P+Z mlN8x+ZHdiuO+BqL/bux966sTsH5Tav/aly2nrnlxY1dZ7t7Ogy3LVzewfkrmYV/ef7/xXVH p/JE67Gmze37cL1L7UHY278FbsrrlViKMxINtZiLihMBjLk6G3MCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUi6MSzVNcwf1OUwd4pJhav22YzWnw6dp7F 4k6MA7NHz+cXTB4tR96yeixZ8pMpgDmKyyYlNSezLLVI3y6BK2PZo4esBT9kKi6sfc3WwHhQ vIuRk0NCwERi8uWpTCC2kMAuRontTxhBbF4BQYkfk++xdDFycDALqEtMmZLbxcgFVDKXSWL6 6ueMIHFhAQmJzXsSQcqFBTQknn7pBxvDJqAicfzbBmYQm1NAT+L542+sIDaLgKrEia7ZYHFm AWWJx7MaWSBsbYkn7y6wQqy1kVh7fDrUOZUSizZsZQVZJSLgJ7Fkih3ExbISK2ffZZ3AKDAL yaGzEA6dhWToAkbmVYyiRak5iZVGeqmlRfl6iQUFOal6yfm5mxjB4WnOs4Px1UHDQ4wCHIxK PLz9KZuihFgTy4orcw8xSnAwK4nwbvu8MUqINyWxsiq1KD++qDQntfgQozQHi5I4r60vf5SQ QHpiSWp2ampBahFMlomDU6qB0eht8JdNcs+eqchWfmaqzb+us2Fv/p3mxQLHzdP+hCwLU3fe 9Hn6TOXbHXctszpvmrFOnGJxziXbo7qtXdNn56ai/91SHP0HTljO4E5hP7bJzF95veC+ohrH tecTvxbxX+u9ZBr7NnST5ZkJP3L+btu1V7fT/V2F56Yn1bpxv9/wv3ffzuC3SomlOCPRUIu5 qDgRAAURnEBLAgAA Archived-At: Subject: Re: [Taps] conflicting policies X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 14:41:59 -0000 Agreed that the implementations should not do =E2=80=9Cmagical=E2=80=9D = or unexpected things. In the example question there are actually two elements at play: - How to rank preferences and policies at connection establishment time - How to treat path changes that may be disruptive to established = connections For the first case, current deployments avoid the issue by always = prioritizing path preference over protocol preference. Protocol = preference only has influence in the absence of a path preference, and = for cases like costly LTE and free Wi-Fi, the path preference is rather = hard-coded. Between two free ethernet interfaces, there is no particular = preference. Should this be codified? Perhaps, perhaps not. If it were, = what would reflect current practice is: - If there is an explicit path preference, choose that first - Within a given path, follow protocol preferences - If there are no path preferences, use protocol preferences to guide = path preferences - Within those selected paths, follow protocol preferences For the second case, where there is a path change, a protocol like QUIC = would try to migrate. However, if it can=E2=80=99t, I don=E2=80=99t = think the TAPS system can or should seamlessly re-establish=E2=80=94there = is new context! We would give a path changed event to indicate that = while you=E2=80=99re on a specific path (LTE), there is a new, more = preferred path (Wi-Fi), at which point the application can request a new = Connection (essentially cloning). Thanks, Tommy > On Mar 21, 2018, at 2:20 PM, G Fairhurst wrote: >=20 > I personally think this is an important topic. The topic also appeared = in the TAPS chartering, and my thoughts are currently: >=20 > - I think we should ensure that the decisions made by TAPS systems are = evident, at least in the logging. Implementations should not just = provide "magic". >=20 > - I'd expect the "standard" API produces deterministic outcomes. This = seems to be helped by the app either asking high-level path properties: = "give me an interactive treatment" or alternatively the API requesting = specific network path properties: "do not use wifi", "prefer low = latency", "interface must be > x Mbps", "mark as DSCP=3Dx", etc. >=20 > I'd argue that characterising the App, rather than the network = treatment e.g., "I'm a video conf App", "I wish to send x MB", etc, is = much less helpful for this "standard" TAPS interface. >=20 > I am not against a developer or vendor utilising a range of = "additional" properties which aply for a specific system and then can = inform specific decisions. To me, at least, this sort of optimisation = requires more "understanding" to interpret how to match the connection = to set of candidate paths. >=20 > Gorry >=20 > On 21/03/2018, 11:34, Roni Even (A) wrote: >>=20 >> Hi, >>=20 >> I made this comment in the past in QUIC when discussing migration. >>=20 >> One policy may be prefer wifi over cellular network, >>=20 >> Second policy prefers quic cove TCP >>=20 >> Now I walk into my house and my cellphone has HTTP over QUIC. >>=20 >> At home will switch to wifi but quic is not supported on the wifi so = will fall back to TCP. This contradicts the second policy. So two = options wifi TCP or cellular QUIC , how to decide? >>=20 >> Roni Even >>=20 >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Mar 21 07:43:13 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 4FFE912DA4D; Wed, 21 Mar 2018 07:43:12 -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.76.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152164339227.7352.3434510849833021865@ietfa.amsl.com> Date: Wed, 21 Mar 2018 07:43:12 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-minset-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 14:43:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : A Minimal Set of Transport Services for TAPS Systems Authors : Michael Welzl Stein Gjessing Filename : draft-ietf-taps-minset-03.txt Pages : 46 Date : 2018-03-21 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-minset-03 https://datatracker.ietf.org/doc/html/draft-ietf-taps-minset-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 21 08:47:12 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 DE07D12DA73 for ; Wed, 21 Mar 2018 08:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DSyLenm3WnL for ; Wed, 21 Mar 2018 08:47:08 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B90C12DB6E for ; Wed, 21 Mar 2018 08:47:08 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id f125so10642515wme.4 for ; Wed, 21 Mar 2018 08:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nGNQrB+oEH4Z45hWpu7wu94uuKGQMJ4GxsJcrEHdAio=; b=nwJataV2KaukQUbsYcbrX9FkgJ0ulY0d5hL+jSVhDyt0QYB/GNJO2vE6dn7drW8emh 4/QCB9FWvn38oDhiMfbxGGhhWBNj+Cz3Gr2EPtyVm3hlPiHbnEqsBN2aumCN6wFknxjd o8qv7GIgFXuSzId99vN3Tb6oJa5KUP36Qp5YdPYTxTxO/SHt5Rj/1uMo34ghzn8JvSgD KrbKqVwZwFNqT0WFJ7RyJv8Yvb5i7KZgZEnMBQbRnBmDs2sMqjoikBEy0BxQ6TM9CMr1 J6HFEHfViYJTEIwxPPsRPm9Mq75Xc9QtpHBKwxMLlNClQ9+kNALfeSsx5it0RdNLadlC OjCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nGNQrB+oEH4Z45hWpu7wu94uuKGQMJ4GxsJcrEHdAio=; b=ILNstl8bA2/qbN6bHWo/cRXHnsFFpLTnK2GqmRz1Jr3c18XBanRUsTvFAurxyZfJxb eQmAyROH1WQ8+UTkh9L61d900s/4AM1UBrF5jjWH6vfCP6KF2X++2lyslstDhqnkgD48 sIL/3W3F2q7GSs6XUsf7uMddVAKRfH17GJY8JWzKC9ANsLZremjRJpeSp5Xe4kOAMzOb k8DM0YvrVMNj6rC4j1lU77N02gbU/AUYDxexdm9aSgM5ooTdU+LNZyW2qBUszkE58aqj mmyuHQZgUdNeD3NE+hqoxAyZjRbtFb5uBuQQck6KoW0tzoQ9SBMku3Ed114eKThvc1Jt KfTw== X-Gm-Message-State: AElRT7E/GIx9DeXMYnHXCAoUFe7egO1QC1dtDpxAmWa3e8akZzi+WMZL vU3zi3KKjSB3PUcWbk65/VystsYxSl/V3gr0XFE= X-Google-Smtp-Source: AG47ELtwqKl/uR7ueXFq5oL+UuXIRTQWlChEyX0ZolrFdFSGscGfuh4EgDFFqTkxBs+uOCFs3AupZj59OG1zs1M1CTg= X-Received: by 10.28.171.131 with SMTP id u125mr2903267wme.19.1521647226517; Wed, 21 Mar 2018 08:47:06 -0700 (PDT) MIME-Version: 1.0 Sender: crowcroft@gmail.com Received: by 10.28.136.15 with HTTP; Wed, 21 Mar 2018 08:47:05 -0700 (PDT) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD86DE4C@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD86DE4C@DGGEMM506-MBX.china.huawei.com> From: Jon Crowcroft Date: Wed, 21 Mar 2018 15:47:05 +0000 X-Google-Sender-Auth: as4ngTlvoq8xbBsPLpBGWaOZyY0 Message-ID: To: "Roni Even (A)" Cc: "taps@ietf.org" Content-Type: multipart/alternative; boundary="001a114527766900e70567ee1a4e" Archived-At: Subject: Re: [Taps] conflicting policies X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 15:47:11 -0000 --001a114527766900e70567ee1a4e Content-Type: text/plain; charset="UTF-8" for historical perspective, this is similar to the problem of "feature interaction" in old private phone exchanges 30 years back - its (in general) quite a hard problem if you can't just order all the preferences... On Wed, Mar 21, 2018 at 11:34 AM, Roni Even (A) wrote: > Hi, > > I made this comment in the past in QUIC when discussing migration. > > > > One policy may be prefer wifi over cellular network, > > Second policy prefers quic cove TCP > > > > Now I walk into my house and my cellphone has HTTP over QUIC. > > At home will switch to wifi but quic is not supported on the wifi so will > fall back to TCP. This contradicts the second policy. So two options wifi > TCP or cellular QUIC , how to decide? > > > > Roni Even > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > > --001a114527766900e70567ee1a4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
        for historical perspective, this is similar to the problem= of "feature interaction" in old private phone exchanges 30 years= back - its (in general) quite a hard problem if you can't just order a= ll the preferences...

        On Wed, Mar 21, 2018 at 11:34 AM, Roni Even (A) <roni.even@hu= awei.com> wrote:

        Hi,

        I made this comment in the past in QUIC when discuss= ing migration.

        =C2=A0

        One policy may be prefer wifi over cellular network,=

        Second policy prefers quic cove TCP

        =C2=A0

        Now I walk into my house and my cellphone has HTTP o= ver QUIC.

        At home will switch to wifi but quic is not supporte= d on the wifi so will fall back to TCP. This contradicts the second policy.= So two options wifi TCP or cellular QUIC , how to decide?

        =C2=A0

        Roni Even


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


        --001a114527766900e70567ee1a4e-- From nobody Wed Mar 21 09:58:20 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 E700E12711B for ; Wed, 21 Mar 2018 09:58:18 -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 fAwcZTjfx1sy for ; Wed, 21 Mar 2018 09:58:16 -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 EACFB126CC7 for ; Wed, 21 Mar 2018 09:58:15 -0700 (PDT) Received: from [192.168.1.128] (unknown [213.205.251.248]) (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 9160D80E3C; Wed, 21 Mar 2018 17:58:13 +0100 (CET) To: taps WG From: Fernando Gont Cc: "gorry@erg.abdn.ac.uk" , Tommy Pauly Message-ID: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> Date: Wed, 21 Mar 2018 16:58:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 16:58:19 -0000 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 From nobody Wed Mar 21 10:10: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 CDBF412E043 for ; Wed, 21 Mar 2018 10:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVR28fbMP28x for ; Wed, 21 Mar 2018 10:10:07 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81F5127137 for ; Wed, 21 Mar 2018 10:10:06 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id e194so11037997wmd.3 for ; Wed, 21 Mar 2018 10:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:references:mime-version; bh=4IFICGJmxYMeKQCogszyZaJ3Sh/TTR5WO5aRdaSska4=; b=V2Lx6Yt+RXteEggiYUFg8ntDg+nKFb1jGtnryAkrl6HwG4Gbno8QfAKFLBXmYn2+bP cpotcGMkIsgBIhErUNgmSfqSuk9C7xxwqkGoI9uDPMHs9zwQoy+/hqYaNdXs3BE6PnFI hCdd7c1ZZx9jOWAtZph7t6UUYBu5bXK4m66DCRrmdHrC6MBwu9UvA8u3IImRJW3Cr8PY kAIwgkGiOYr5upyfnIQ4ArIhivNIiEqkeuSxVeveTX53JDc2+GpGwanaTkRl9ubVWY04 qKmFl86ZYPXUc3NU4JRGwttaIMnWKPXH7hpMI9fUQ73fnW5IC3GOmeEtmWeu3nXDL9Zv slJA== 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:references :mime-version; bh=4IFICGJmxYMeKQCogszyZaJ3Sh/TTR5WO5aRdaSska4=; b=knlc6+Ko5oq8y6F5Q6itCMEGAO63LsDreykvwrCutFFy0XGOHcHCvAnJBPaXYfeJ5P qEuLgUVYCahBaDgevu/C+Obh7B/OB53Z2IiA90qLF/ilnxGI6SjMM7CB1PHDyFGlkC2W 24KlqCT5MNfcUMd11LmnP5Aaoy8y8+Uc8x28Yp3U7o0xAZJYdiKoMiUm7NNj+YNuGIjD +fndRZ7qItJu3QIv26+MBrhGUwHYISolTkXshJQhkOCL7RjUVj02ymTMwD8fM8MeYnKm WwsNYZT1nuk8ieq2UhfAX82dba8T/nOVCIzTg89UN0XHah0xl/+StlgIRUOYKvSUlM9o koVA== X-Gm-Message-State: AElRT7FNMcB2/pO5Hp9UdIE+zjEcefMSY5Rp8Pn4NB0qECc3nnZYO7tK b1ClKFSRcLwarDNo9IxKkN8K2wqPKHo= X-Google-Smtp-Source: AG47ELsc6YMfz99nPi3ffpdvZyGQTLImfvOD2g14wQR9fRqA0GItEu/W/QhTNR7TJ7/Ws7GgMzCxtw== X-Received: by 10.28.22.208 with SMTP id 199mr3457154wmw.79.1521652204940; Wed, 21 Mar 2018 10:10:04 -0700 (PDT) Received: from [169.254.39.56] ([2001:67c:370:128:d530:dc36:21da:bbaa]) by smtp.gmail.com with ESMTPSA id r6sm5215959wrg.63.2018.03.21.10.10.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 10:10:04 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Wed, 21 Mar 2018 17:10:00 +0000 X-Mailer: MailMate (1.11r5462) Message-ID: References: <1521642460.314808.1310950208.632524EE@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_A65E9503-6EBA-44FD-937E-AC71F7E69698_=" Archived-At: Subject: [Taps] Fwd: Possible TAPS challenges X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 17:10:10 -0000 --=_MailMate_A65E9503-6EBA-44FD-937E-AC71F7E69698_= Content-Type: text/plain; format=flowed Mark Handley sent this thought provoking note after our meeting this morning. Some ideas here that stretch the architecture, I think. At least we need to consider extensibility of the API. Forwarding with permission. --aaron Forwarded message: > From: Mark Handley > To: Colin Perkins > , aaron.falk@gmail.com > Subject: Possible TAPS challenges > Date: Wed, 21 Mar 2018 14:27:40 +0000 > > Hi Aaron, Colin, > > As I mentioned, I'm playing with ideas for a new TCP-replacement > transport protocol at the moment. It doesn't really have a name right > now, but lets call it NeoTCP. Likely it won't go anywhere, but some > of the ideas differ a bit from other transport protocols, so may serve > as a useful test for the TAPS API. > > 1. Pre-authentication. I want to put the ssh server on my home > machine on the Internet without it being constantly attacked with > password guessing attacks. NeoTCP implements very simple > pre-authentication, where my laptop and my home machine share a > secret. When connecting, the client sends the pair (nonce, > Hash(nonce, secret)). The server won't send a syn/ack equivalent > unless the secret match one of the secrets from its cache. > > 2. Source-spoofing protection. NeoTCP supports the equivalent of SYN > cookies, but with a 4-way handshake to avoid the potential deadlock > associated with SYN cookies. I'm also playing with the idea of > allowing middleboxes to interpose a challenge in response to the SYN, > and when the challenge response arrives from the client, only then is > the packet passed through to the actual server, and the handshake > continues. I'm not clear yet if including middleboxes in some way > impacts the API. > > 3. Encryption. Goal is to do tcpcrypt-like encryption, but provide > hooks to higher layers so they can do whatever full authentication > that particular application needs. > > 4. Redirect. Redirecting connections is a very common > application-layer function, but really you would prefer to redirect > before you've set up a connection. Such redirection obviously needs > some form of authentication (maybe this contradicts 3 - not clear > where I'm going on this yet). What would the API be for a redirect > server? It's not a full server; it listens, but simply sends > stateless syn/ack redirects, rather than accept connections. > > 5. Acking. NeoTCP supports multi-path using two sequence spaces - > subflow packet sequence numbers and data sequence numbers like MPTCP. > Unlike MPTCP, the data sequence number ack indicates the receiving > application received the packet (with MPTCP, it only indicates > reception by the receiving stack. > > 6. Pulling. NeoTCP takes some lessons from NDP, and is a > receiver-driven protocol. When several senders are sending to one > receiver, this allows the receiver to choose precisely which senders > to pull packets from at any time. This generalizes the QUIC/HTTP2 > priorities to now support multiple different senders. You can use > this to do aggregate congestion control for incoming traffic, avoiding > self-congestion. It's up to the receiving application to determine > priorities, and to the transport to decide how to use those > priorities. > > 7. Close is a total mess with TCP. It's even worse with a user-space > protocol - your application may quit when close returns; data may not > have been received yet and needs retransmitting, but there's no-one > left to do it. By default, with NDP close won't return until the > receiving application has received sent data. Obviously you need > some way to avoid deadlock when the receiver died; that timeout is > application specific. > > 8. Finally, we've done a lot of work over the last couple of years on > understanding MPTCP for web traffic. It's ugly. You have a whole > load of short objects, and the application has a priority order for > them. But the paths may have very different latency. If you send any > packet from the highest priority object on the high latency path, you > can delay the object significantly, and it can really hurt the overall > page load time, as other requests get stalled waiting for that object. > The best you can do is to run a per-packet scheduler, and ask the > question "if I send the next packet from this object on the higher > latency path, will it arrive after the rest of the object sent on the > lower latency path?" If the answer is yes, you shouldn't send that > packet on the higher latency path. Next you have to consider the > second highest priority object, and ask if you should instead send a > packet from that object on the higher latency path. You should, if > will arrive before both the highest priority object and all the rest > of the second highest priority object. If not, you shouldn't, and you > should consider the third highest priority object, and so on. > Obviously, this is complicated. At the very least, the transport > protocol needs to know which packets are from which object, and what > those object priorities are. At the receiver, objects may arrive out > of order, but packets within an object must be in-order. > > There are probably more things, but that's what comes to mind right > now. > > Mark --=_MailMate_A65E9503-6EBA-44FD-937E-AC71F7E69698_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
        <= p dir=3D"auto">Mark Handley sent this thought provoking note after our me= eting this morning. Some ideas here that stretch the architecture, I thi= nk. At least we need to consider extensibility of the API. Forwarding w= ith permission.

        --aaron

        Forwarded message:

        From: Mark Handley <mark@handley= =2Eorg.uk>
        To: Colin Perkins > <csp@csperkins.org>, aaron.falk@gmail.com Subject: Possible TAPS challenges
        Date: Wed, 21 Mar 2018 14:27:40 +0000

        Hi Aaron, Colin,

        As I mentioned, I'm playing with ideas for a new TCP-replacement transpor= t protocol at the moment. It doesn't really have a name right now, but l= ets call it NeoTCP. Likely it won't go anywhere, but some of the ideas d= iffer a bit from other transport protocols, so may serve as a useful test= for the TAPS API.

        1. Pre-authentication. I want to put the ssh server on my home machine = on the Internet without it being constantly attacked with password guessi= ng attacks. NeoTCP implements very simple pre-authentication, where my l= aptop and my home machine share a secret. When connecting, the client se= nds the pair (nonce, Hash(nonce, secret)). The server won't send a syn/= ack equivalent unless the secret match one of the secrets from its cache.=

        2. Source-spoofing protection. NeoTCP supports the equivalent of SYN co= okies, but with a 4-way handshake to avoid the potential deadlock associa= ted with SYN cookies. I'm also playing with the idea of allowing middleb= oxes to interpose a challenge in response to the SYN, and when the challe= nge response arrives from the client, only then is the packet passed thro= ugh to the actual server, and the handshake continues. I'm not clear yet= if including middleboxes in some way impacts the API.

        3. Encryption. Goal is to do tcpcrypt-like encryption, but provide hook= s to higher layers so they can do whatever full authentication that parti= cular application needs.

        4. Redirect. Redirecting connections is a very common application-layer= function, but really you would prefer to redirect before you've set up a= connection. Such redirection obviously needs some form of authenticatio= n (maybe this contradicts 3 - not clear where I'm going on this yet). W= hat would the API be for a redirect server? It's not a full server; it l= istens, but simply sends stateless syn/ack redirects, rather than accept = connections.

        5. Acking. NeoTCP supports multi-path using two sequence spaces - subflo= w packet sequence numbers and data sequence numbers like MPTCP. Unlike M= PTCP, the data sequence number ack indicates the receiving application re= ceived the packet (with MPTCP, it only indicates reception by the receivi= ng stack.

        6. Pulling. NeoTCP takes some lessons from NDP, and is a receiver-driven= protocol. When several senders are sending to one receiver, this allows= the receiver to choose precisely which senders to pull packets from at a= ny time. This generalizes the QUIC/HTTP2 priorities to now support multi= ple different senders. You can use this to do aggregate congestion contr= ol for incoming traffic, avoiding self-congestion. It's up to the receiv= ing application to determine priorities, and to the transport to decide h= ow to use those priorities.

        7. Close is a total mess with TCP. It's even worse with a user-space pr= otocol - your application may quit when close returns; data may not have = been received yet and needs retransmitting, but there's no-one left to do= it. By default, with NDP close won't return until the receiving applic= ation has received sent data. Obviously you need some way to avoid dead= lock when the receiver died; that timeout is application specific.

        8. Finally, we've done a lot of work over the last couple of years on und= erstanding MPTCP for web traffic. It's ugly. You have a whole load of s= hort objects, and the application has a priority order for them. But the= paths may have very different latency. If you send any packet from the = highest priority object on the high latency path, you can delay the objec= t significantly, and it can really hurt the overall page load time, as ot= her requests get stalled waiting for that object. The best you can do is= to run a per-packet scheduler, and ask the question "if I send the next = packet from this object on the higher latency path, will it arrive after = the rest of the object sent on the lower latency path?" If the answer is= yes, you shouldn't send that packet on the higher latency path. Next yo= u have to consider the second highest priority object, and ask if you sho= uld instead send a packet from that object on the higher latency path. Y= ou should, if will arrive before both the highest priority object and all= the rest of the second highest priority object. If not, you shouldn't, = and you should consider the third highest priority object, and so on. Ob= viously, this is complicated. At the very least, the transport protocol = needs to know which packets are from which object, and what those object = priorities are. At the receiver, objects may arrive out of order, but pa= ckets within an object must be in-order.

        There are probably more things, but that's what comes to mind right now.<= br>
        Mark

        --=_MailMate_A65E9503-6EBA-44FD-937E-AC71F7E69698_=-- From nobody Wed Mar 21 10:48: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 4B096127863 for ; Wed, 21 Mar 2018 10:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1_h7EkhIEhP for ; Wed, 21 Mar 2018 10:48:20 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 9C17012762F for ; Wed, 21 Mar 2018 10:48:19 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id f125so11364134wme.4 for ; Wed, 21 Mar 2018 10:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4EabvsH6UsuiGXPnlCCN+R/QSyrPOqh8pvvHiV4bkWM=; b=PShpsYw248xbmfmKJTEZkd8hfG9x9sRxPVuZEUNAOtAbrT692CMKczLtfKauiwKMWS PaQU16u+PbYgOtqXohsmT/udpNuG4qGQ4EuULZy3gj+8lEM7vCfCgTu9G1tzS+KeKE8C Lws5V1jS3Kr+dZ9RURsModOI4LvpXPByqsUKVaqmTyJUHuFlipZZLr3QoOYQNQYBlENX mjRr9vudspY/dn6wSVHr/DSRE8s4lomn3JzNr9Wl3eJeFncMN97oy4FBl7UHHlu2+4iK N5zW6PEjQwp/OV+pOMGjrZIUs1jiUacx2cIpDQ8byj4uhqq+h8oWeN2o4BzVMb03Cpq+ WnJA== 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=4EabvsH6UsuiGXPnlCCN+R/QSyrPOqh8pvvHiV4bkWM=; b=ORO7SC+eOe8Vgp3gc2Qgetgr9qCksuBwof7kIU2VmdWjupvf2R/snqSjyHrdKsAskr ogXoI+YPbPmL61u32h1oBEXs3ERNWDTtKpFC0+d7oVJMDZkBkuzvb/CA+TFmOB5wPJP5 DJC6Ot5VZxmytfJoG2WC3VuzhTSf3yJoO+gXe3HRYtzSY4kvpZXrKOX9JerhL/QrBZtv 8hui6Lw1fHFIcchKdtiPVzAXHBwe94AdOmd88AkRplL8aFpVlcd3GrblPOU04JgvM5GF 9DTkb+Z3YdAnisxkPcSpqdrW46n8faROCzjcaKYunPaL3AwqfuFC1hlvFxwVIoASZVx8 x69g== X-Gm-Message-State: AElRT7EGMyBjyJjx/O95eU3Qaqz7x+o+zHYVDogUyuPFQ9F9/0tYhKcB rFQJMrpVFLqTFOaD/T+awoDbs/kWoU7yO52MrqR/BQ== X-Google-Smtp-Source: AG47ELuBnDgn+Rrg8y19bqq9a5JYVcEw3A7OidQzoWiIpepOySZlLnMpcrzSwhfuReF4oj4g/ytDs2plYY4azBdpVv8= X-Received: by 10.28.13.67 with SMTP id 64mr3166612wmn.5.1521654497689; Wed, 21 Mar 2018 10:48:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.191.93 with HTTP; Wed, 21 Mar 2018 10:47:56 -0700 (PDT) In-Reply-To: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> From: Erik Kline Date: Wed, 21 Mar 2018 10:47:56 -0700 Message-ID: To: Fernando Gont Cc: taps WG , "gorry@erg.abdn.ac.uk" , Tommy Pauly Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11443672d804df0567efcbf0" Archived-At: Subject: Re: [Taps] IPv6 address usage X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 17:48:22 -0000 --001a11443672d804df0567efcbf0 Content-Type: text/plain; charset="UTF-8" On 21 March 2018 at 09:58, 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: > My observation of: ... For example, a privacy-sensitive application might want that each outgoing communication instance employs a new, single-use IPv6 address, or to employ a new reusable address that is not employed or reusable by any other application on the host. is that it's just not a problem of selecting an address, but also the inability to request that the system /form/ such address for its use (selecting that address for use would come in a subsequent step). > * Analysis of IPv6 address properties: > WRT "4.3. Usage Type Considerations", I've been wanting to have an API for apps to request the formation of addresses exclusively for their own use (i.e. port 80 and 443 aren't shared with other system services). This could be useful for processes that control and spin up VMs as well. I've jotted down some notes in an embryonic draft (https://github.com/ekline/draft-v6addrs-api/blob/master/draft.txt), but they're not yet very well thought through. --001a11443672d804df0567efcbf0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMfg1wtYggohADxbT3MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDIxNTA2MzcxNVoXDTE4MDgx NDA2MzcxNVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANinyejqC3lpuuurPEnTTJsSB+LPui3CT4Cg4PEUVzKZf9l4ircMhwI8 LZmiRwWqg1CReYbVM1JTiQ6gJpWdGaiEdylfMEcCm6RMnuHA8k97/AqBUZti6ZGbtl77UEblK2Ok Qwai1Kza2k2CkjfnzfugTdF/XzOCF9BOYrW/B+fM2MGf7e48qKtoA2FGlTOOaitLYJJBaixBWQUZ oVO6XVPC7mhSoW1Wc7uwD85Yvuf1Qq0MXkxqgAXxJ1xBSS7KVJAIPPlXS3vtxFwmeqDlFIqNB9lY KwU08whM2akO03ENo0ixPJL3kSEafnFiQzVhXTLsgqbCA0lrfH2j4F8/wrMCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBS6wTowyOTvuUJ3LG0j/H1PWoaTrjAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAavJqbhv0cDn0rYD5aMbNL6cvp5a2 9oeeMhRGx55RMI7YywkO91RBJjzKAHWvb9Q2sdoQ/5PBmzEsFyYRhK68AnDE/h/GMhZPqK0p9JMe e1OSiWYexcjPi4ibnMkIBO+GMeTYQPweBfiD4pTwDPaKib+29SM5520Ba6C88h2wNEabdWj9EypL i/utAs30iZ97nKVXDFAgYvOORj5bQAnGAIZHIqSw2xAUu0l59uxdqW3mcZs/6JPrWEGjDh2enVmp BIiQJzNtVktT+lQInKeeJQM4jt+s/RE1m/GacTJZ63MNk9mE5Xn/hbmTkEgBSPu6/6gl1JnrIdTf Aex0alwnMTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH4NcLWIIKIQA8W09zAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgujejw9cwJEqqNupDKAFyIlZgIo3jruLZ uHGof9D6AXIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMzIx MTc0ODE4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAJD65nlyaMNSJ8j21zLWcr86+u2TOLv4+izzoBYa7fOXUs8YEhX0 vOUsTdbs2AHsYsdZib8vMK+7IZ/N79kWeGjKUeCQ48UUqMndbr2YKVKDukSl+U8p5Z/5wa8l08Xy jPhLDHMfbxnKArse0uck4S/qNZRgVjJ/EvZmgPqkMoOgdUOAYI0kf2gPzSMGWBQVCzXCGBGOKeEc E/c/4QzwXEE4DaFJ8Yxu2GGJvodo9PVzgpQEKWjq5qwh4WiT7LQ8enuSpQWVURR/aaMCMiPkOrzu xrYrnJ+XA7EYu7O3ZKaVs7nk76pTTj33isIAgQpJQxNyrgGO+lIG/aED68wYweA= --001a11443672d804df0567efcbf0-- From nobody Wed Mar 21 10:57:36 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 6193012E055 for ; Wed, 21 Mar 2018 10:57:35 -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 rU3_Askzy0Kq for ; Wed, 21 Mar 2018 10:57:33 -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 298D5126E01 for ; Wed, 21 Mar 2018 10:57:33 -0700 (PDT) Received: from [192.168.1.128] (unknown [213.205.251.248]) (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 89F8580E9B; Wed, 21 Mar 2018 18:57:29 +0100 (CET) To: Erik Kline Cc: taps WG , "gorry@erg.abdn.ac.uk" , Tommy Pauly References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> From: Fernando Gont Message-ID: Date: Wed, 21 Mar 2018 17:55:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 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.22 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, 21 Mar 2018 17:57:35 -0000 Hello, Erik, On 03/21/2018 05:47 PM, Erik Kline wrote: > On 21 March 2018 at 09:58, 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: >> > > My observation of: > > ... For > example, a privacy-sensitive application might want that each > outgoing communication instance employs a new, single-use IPv6 > address, or to employ a new reusable address that is not employed or > reusable by any other application on the host. > > is that it's just not a problem of selecting an address, but also the > inability to request that the system /form/ such address for its use > (selecting that address for use would come in a subsequent step). Yep, that's what we meant. We'll clarify this in the next rev. >> * Analysis of IPv6 address properties: >> > > WRT "4.3. Usage Type Considerations", I've been wanting to have an > API for apps to request the formation of addresses exclusively for > their own use (i.e. port 80 and 443 aren't shared with other system > services). Yes, this use case (at least separating surfing from everything else is ne we had in mind). > This could be useful for processes that control and spin > up VMs as well. > > I've jotted down some notes in an embryonic draft > (https://github.com/ekline/draft-v6addrs-api/blob/master/draft.txt), > but they're not yet very well thought through. I will take a look. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Mar 21 11:08:18 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB38126E01 for ; Wed, 21 Mar 2018 11:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vJKDvopepkNZ for ; Wed, 21 Mar 2018 11:08:14 -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 6041A1242EA for ; Wed, 21 Mar 2018 11:08:14 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1eyi9j-0007PL-Oq for taps@ietf.org; Wed, 21 Mar 2018 19:08:11 +0100 Received: from dhcp-9f58.meeting.ietf.org ([31.133.159.88]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.90_1) (envelope-from ) id 1eyi9f-000B52-NT for taps@ietf.org; Wed, 21 Mar 2018 19:08:11 +0100 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 21 Mar 2018 18:08:11 +0000 References: <152164339227.7352.3434510849833021865@ietfa.amsl.com> To: "taps@ietf.org" In-Reply-To: <152164339227.7352.3434510849833021865@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 31.133.159.88 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.159.88; envelope-from=michawe@ifi.uio.no; helo=dhcp-9f58.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.022, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A755485E9E1D87C6BFD0E6A8F601D08F5B7B111F Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-minset-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 18:08:16 -0000 Hi all, This is the tiny update that addresses the things we said we=E2=80=99d = do before the draft could go to WGLC: We updated the sentence referencing the security draft = [I-D.pauly-taps-transport-security] to say that "the minimum security requirements for a taps system are discussed in a = separate security document=E2=80=9D, and we wrote "example" in the paragraph introducing the decision tree = (Mirja was right, it wasn=E2=80=99t explicitly said, but I thought it=E2=80=99s implicitly clear from the text - I hope = it=E2=80=99s clear enough now that this is really only meant as an example). Cheers, Michael > On Mar 21, 2018, at 2:43 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Services WG of the IETF. >=20 > Title : A Minimal Set of Transport Services for TAPS = Systems > Authors : Michael Welzl > Stein Gjessing > Filename : draft-ietf-taps-minset-03.txt > Pages : 46 > Date : 2018-03-21 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-taps-minset-03 > https://datatracker.ietf.org/doc/html/draft-ietf-taps-minset-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-minset-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Mar 21 16:12: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 5CF2712D777 for ; Wed, 21 Mar 2018 16:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_SPF_PERMERROR=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=strayalpha.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 K36nx5L2laPz for ; Wed, 21 Mar 2018 16:12:45 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 A233C129C6E for ; Wed, 21 Mar 2018 16:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wBVXX8OsLLX0XRC8xjs5eSnyqY0dMa7nlAzex/yh1Ts=; b=l9Fh0upO8sYN9fhA4TieCvx2Z 3YZopxQfthqlphMH0TAqBNieL3W9xEEyKpJtguX67zrBTw+KhCAViwFQMcmFYHIXwkfe8BZl5BFly 1BsUF120bYfgHWlhlet8tvRmYw9i9laAJsnZVQpcXJPzPn+t6ysyr/2CeL033YZCcemOHhfRX5QPR UEebvPiAr+Yic0o36JiCbazGbY+5I6W9EijDseqFDvDQn15pXgfU2gQNtdWn53nMDVJ7dsnBUsCqE VFSgUSOLA0R4gUNbHUG4MbBsBDuECqKL9XcgWhooSoXf2nDj3CHbWkMfe15N4f52IUqAdnvfLAt4v 869k09gjA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57285 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eymuK-0025Yo-Nl; Wed, 21 Mar 2018 19:12:40 -0400 To: Aaron Falk , taps WG References: <1521642460.314808.1310950208.632524EE@webmail.messagingengine.com> From: Joe Touch Message-ID: Date: Wed, 21 Mar 2018 16:12:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C869FF7AE26BA538888833CC" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Taps] Fwd: Possible TAPS challenges X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2018 23:12:47 -0000 This is a multi-part message in MIME format. --------------C869FF7AE26BA538888833CC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit FWIW, #8 was raised when MPTCP was created - I pointed out that this system, like HTTP muxing, was doomed to needing to reinvent the whole of IP at the TCP layer (or HTTP layer, for HTTP muxing). That includes differentiated services. Joe On 3/21/2018 10:10 AM, Aaron Falk wrote: > > Mark Handley sent this thought provoking note after our meeting this > morning. Some ideas here that stretch the architecture, I think. At > least we need to consider extensibility of the API. Forwarding with > permission. > > --aaron > > Forwarded message: > > From: Mark Handley > To: Colin Perkins > , aaron.falk@gmail.com > Subject: Possible TAPS challenges > Date: Wed, 21 Mar 2018 14:27:40 +0000 > > Hi Aaron, Colin, > > As I mentioned, I'm playing with ideas for a new TCP-replacement > transport protocol at the moment. It doesn't really have a name > right now, but lets call it NeoTCP. Likely it won't go anywhere, > but some of the ideas differ a bit from other transport protocols, > so may serve as a useful test for the TAPS API. > > 1. Pre-authentication. I want to put the ssh server on my home > machine on the Internet without it being constantly attacked with > password guessing attacks. NeoTCP implements very simple > pre-authentication, where my laptop and my home machine share a > secret. When connecting, the client sends the pair (nonce, > Hash(nonce, secret)). The server won't send a syn/ack equivalent > unless the secret match one of the secrets from its cache. > > 2. Source-spoofing protection. NeoTCP supports the equivalent of > SYN cookies, but with a 4-way handshake to avoid the potential > deadlock associated with SYN cookies. I'm also playing with the > idea of allowing middleboxes to interpose a challenge in response > to the SYN, and when the challenge response arrives from the > client, only then is the packet passed through to the actual > server, and the handshake continues. I'm not clear yet if > including middleboxes in some way impacts the API. > > 3. Encryption. Goal is to do tcpcrypt-like encryption, but provide > hooks to higher layers so they can do whatever full authentication > that particular application needs. > > 4. Redirect. Redirecting connections is a very common > application-layer function, but really you would prefer to > redirect before you've set up a connection. Such redirection > obviously needs some form of authentication (maybe this > contradicts 3 - not clear where I'm going on this yet). What would > the API be for a redirect server? It's not a full server; it > listens, but simply sends stateless syn/ack redirects, rather than > accept connections. > > 5. Acking. NeoTCP supports multi-path using two sequence spaces - > subflow packet sequence numbers and data sequence numbers like > MPTCP. Unlike MPTCP, the data sequence number ack indicates the > receiving application received the packet (with MPTCP, it only > indicates reception by the receiving stack. > > 6. Pulling. NeoTCP takes some lessons from NDP, and is a > receiver-driven protocol. When several senders are sending to one > receiver, this allows the receiver to choose precisely which > senders to pull packets from at any time. This generalizes the > QUIC/HTTP2 priorities to now support multiple different senders. > You can use this to do aggregate congestion control for incoming > traffic, avoiding self-congestion. It's up to the receiving > application to determine priorities, and to the transport to > decide how to use those priorities. > > 7. Close is a total mess with TCP. It's even worse with a > user-space protocol - your application may quit when close > returns; data may not have been received yet and needs > retransmitting, but there's no-one left to do it. By default, with > NDP close won't return until the receiving application has > received sent data. Obviously you need some way to avoid deadlock > when the receiver died; that timeout is application specific. > > 8. Finally, we've done a lot of work over the last couple of years > on understanding MPTCP for web traffic. It's ugly. You have a > whole load of short objects, and the application has a priority > order for them. But the paths may have very different latency. If > you send any packet from the highest priority object on the high > latency path, you can delay the object significantly, and it can > really hurt the overall page load time, as other requests get > stalled waiting for that object. The best you can do is to run a > per-packet scheduler, and ask the question "if I send the next > packet from this object on the higher latency path, will it arrive > after the rest of the object sent on the lower latency path?" If > the answer is yes, you shouldn't send that packet on the higher > latency path. Next you have to consider the second highest > priority object, and ask if you should instead send a packet from > that object on the higher latency path. You should, if will arrive > before both the highest priority object and all the rest of the > second highest priority object. If not, you shouldn't, and you > should consider the third highest priority object, and so on. > Obviously, this is complicated. At the very least, the transport > protocol needs to know which packets are from which object, and > what those object priorities are. At the receiver, objects may > arrive out of order, but packets within an object must be in-order. > > There are probably more things, but that's what comes to mind > right now. > > Mark > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --------------C869FF7AE26BA538888833CC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

        FWIW, #8 was raised when MPTCP was created - I pointed out that this system, like HTTP muxing, was doomed to needing to reinvent the whole of IP at the TCP layer (or HTTP layer, for HTTP muxing). That includes differentiated services.

        Joe


        On 3/21/2018 10:10 AM, Aaron Falk wrote:

        Mark Handley sent this thought provoking note after our meeting this morning. Some ideas here that stretch the architecture, I think. At least we need to consider extensibility of the API. Forwarding with permission.

        --aaron

        Forwarded message:

        From: Mark Handley <mark@handley.org.uk>
        To: Colin Perkins > <csp@csperkins.org>, aaron.falk@gmail.com
        Subject: Possible TAPS challenges
        Date: Wed, 21 Mar 2018 14:27:40 +0000

        Hi Aaron, Colin,

        As I mentioned, I'm playing with ideas for a new TCP-replacement transport protocol at the moment. It doesn't really have a name right now, but lets call it NeoTCP. Likely it won't go anywhere, but some of the ideas differ a bit from other transport protocols, so may serve as a useful test for the TAPS API.

        1. Pre-authentication. I want to put the ssh server on my home machine on the Internet without it being constantly attacked with password guessing attacks. NeoTCP implements very simple pre-authentication, where my laptop and my home machine share a secret. When connecting, the client sends the pair (nonce, Hash(nonce, secret)). The server won't send a syn/ack equivalent unless the secret match one of the secrets from its cache.

        2. Source-spoofing protection. NeoTCP supports the equivalent of SYN cookies, but with a 4-way handshake to avoid the potential deadlock associated with SYN cookies. I'm also playing with the idea of allowing middleboxes to interpose a challenge in response to the SYN, and when the challenge response arrives from the client, only then is the packet passed through to the actual server, and the handshake continues. I'm not clear yet if including middleboxes in some way impacts the API.

        3. Encryption. Goal is to do tcpcrypt-like encryption, but provide hooks to higher layers so they can do whatever full authentication that particular application needs.

        4. Redirect. Redirecting connections is a very common application-layer function, but really you would prefer to redirect before you've set up a connection. Such redirection obviously needs some form of authentication (maybe this contradicts 3 - not clear where I'm going on this yet). What would the API be for a redirect server? It's not a full server; it listens, but simply sends stateless syn/ack redirects, rather than accept connections.

        5. Acking. NeoTCP supports multi-path using two sequence spaces - subflow packet sequence numbers and data sequence numbers like MPTCP. Unlike MPTCP, the data sequence number ack indicates the receiving application received the packet (with MPTCP, it only indicates reception by the receiving stack.

        6. Pulling. NeoTCP takes some lessons from NDP, and is a receiver-driven protocol. When several senders are sending to one receiver, this allows the receiver to choose precisely which senders to pull packets from at any time. This generalizes the QUIC/HTTP2 priorities to now support multiple different senders. You can use this to do aggregate congestion control for incoming traffic, avoiding self-congestion. It's up to the receiving application to determine priorities, and to the transport to decide how to use those priorities.

        7. Close is a total mess with TCP. It's even worse with a user-space protocol - your application may quit when close returns; data may not have been received yet and needs retransmitting, but there's no-one left to do it. By default, with NDP close won't return until the receiving application has received sent data. Obviously you need some way to avoid deadlock when the receiver died; that timeout is application specific.

        8. Finally, we've done a lot of work over the last couple of years on understanding MPTCP for web traffic. It's ugly. You have a whole load of short objects, and the application has a priority order for them. But the paths may have very different latency. If you send any packet from the highest priority object on the high latency path, you can delay the object significantly, and it can really hurt the overall page load time, as other requests get stalled waiting for that object. The best you can do is to run a per-packet scheduler, and ask the question "if I send the next packet from this object on the higher latency path, will it arrive after the rest of the object sent on the lower latency path?" If the answer is yes, you shouldn't send that packet on the higher latency path. Next you have to consider the second highest priority object, and ask if you should instead send a packet from that object on the higher latency path. You should, if will arrive before both the highest priority object and all the rest of the second highest priority object. If not, you shouldn't, and you should consider the third highest priority object, and so on. Obviously, this is complicated. At the very least, the transport protocol needs to know which packets are from which object, and what those object priorities are. At the receiver, objects may arrive out of order, but packets within an object must be in-order.

        There are probably more things, but that's what comes to mind right now.

        Mark



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

        --------------C869FF7AE26BA538888833CC-- From nobody Mon Mar 26 06:28: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 99E5D127201; Mon, 26 Mar 2018 06:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 tOYGpppOAf7I; Mon, 26 Mar 2018 06:28:05 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7897B124D68; Mon, 26 Mar 2018 06:28:05 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id B38CB49657; Mon, 26 Mar 2018 15:28:03 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id DE9FC189; Mon, 26 Mar 2018 15:28:02 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 983313B6; Mon, 26 Mar 2018 15:28:02 +0200 (CEST) Received: (nullmailer pid 18009 invoked by uid 1000); Mon, 26 Mar 2018 13:28:01 -0000 Date: Mon, 26 Mar 2018 15:28:01 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-trammell-taps-interface@ietf.org Cc: taps@ietf.org Message-ID: <20180326132800.GA17717@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: [Taps] Hello from CoRE X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 26 Mar 2018 13:28:07 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello taps-interface authors, I was having a look at the work of the TAPS Group on suggestion of Theresa; my context is as an implementor the CoAP protocol, which is a primarily UDP based protocol for RESTful interaction in constrained ("IoT") environments (short: CoRE). That protocol is a bit tricky to implement in full on POSIX sockets because it requires that responses be sent from the destination address of the request, and because role reversal (a server that has received requests starts sending requests to the original client) means that even a server needs to receive ICMP errors on messages it sends. While this can be done on POSIX using various socket options and sendmsg/recvmsg, it is not trivial to implement and sometimes badly supported by platforms and language bindings. I've had a look at the abstract API outlined in trammell-taps-interface, and it seems to be suitable for implementing CoAP in a much more straightforward way, but I don't know yet whether it can do the following: * Can the API be instructed that a UDP package shall go out on the same IP and port as a given received package? (CoAP requirement) * Can a listening (pre)connection be used to initiate a connection actively from the listening port? (This is convenient to have because it allows hosts to advertise their server role in a client capacity without needing to transmit their own server address explicitly). * Can the API be used for sending and receiving multicasts (or will provide that in a later form)? * On the topic of DTLS protected connections: Can the API give me a handle to (or representation of) an outgoing packet in its encrypted form, so that I can issue a retransmit at a later time using the same DTLS sequence number? (There are mechanisms being specified with which CoAP can deal with malicious reordering, but those keep track of lost packages. If the packages get retransmitted as-was and get ack'ed, that mechanism can save a few bytes). * For CoAP, it is recommended to introspect an returning ICMP error to see whether it is genuine (the headers match a sent package) and relevant for various reasons (RFC7252 Section 4.2). Will the API provide that detail to the protocol implementor, or can the protocl implementor configure how to treat which errors? And last but not least: Is there an implementation of this around I could experiment with? Best regards, Christian PS. Please keep me in To/Cc when replying, as I am not subscribed to the TAPS mailing list. --=20 We are dreamers, shapers, singers, and makers. -- Elric --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlq49VwACgkQOY0REtOk veF/6Q//cyQosMGc+p/opR43aorCEKaS7JtL/aoLPw7z+su9Zt/6ScBFCkwCvcxy Y9Em//5CiMzgZtcSDA15mAcF7Jf6KUiXdoKOBLM+hm4a+nBoaxs8OHX6JVj6g942 xGjK13UUZAPyf+7tw32HgcFYjF6FD7j89HEu8ng5CMMSS92z+oHZ/SXDrjyG4ZAn wDeII/l7dk362vhh06/tpPaY4xaHw7hz1HhmfwL6CuA7QNeV/HLbNTjsteTMOE9y sB7riomkLvuksXEhUG464wLSn2SQxP30yokr5Vi/P5p6481DuJhH8Z2xCF/sf2W7 igl3BnRBX1X9omcF3lzSw8qikTuXgCs5ym1ZsZtSElKNuVtqVzKr3b/U0PokbDLp 0SOBNE0BkIxYrFkATyqeT2ol/8jNGQ/YRhGxKY7+5pFshdDbGqK4Bdt0DE9Nt0Z5 x8hobm9/RGQ1xfBM8JDM6/O9kbkhkNxfYayaoRXu8gfwcT6zfJRBdyMR443+bfuX 8z59v2sK2IMFq+Q0NnTAQtihNej9qvte15wHLreFmxtj0QHfD7CfYoEPA0Lbk7sH rNnpifUgHAwZsClIJMG3g3kSrD9IVHuTodFW1mUUdnjdj/RGswxbvx6pjlsPfxt7 j6CsnBPYlqsYvPEhlnZoThm3CJI7jdkyo0mXuBmbAYA+SFxOVLc= =NQPP -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From nobody Mon Mar 26 06:33:32 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 C2B811274D2 for ; Mon, 26 Mar 2018 06:33:30 -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_RP_MATCHES_RCVD=-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 DgI8PmuJEkLt for ; Mon, 26 Mar 2018 06:33:29 -0700 (PDT) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (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 23E4F127419 for ; Mon, 26 Mar 2018 06:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1522071207; x=2385984807; 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=1CFFmVriD+M70GAyxcbemY2EBpgaw2h5e0MwxnXP5D0=; b=IpP4ZhFATJ0oP/Tb+3qHvIAMqKIWent4Xez/uHJ+bU6SByExlqTbjjoEve4m1IEK 6IIYPmRntLt3nvauJb8O8rW/ExQ/ee80Cvp1fTWb89pdN3JEusy20ERKQCu7EMwM bw3Fd50ujd+aiKr1tUp95CtKU02yp4kT5eXGsHP69Npy0p8UUONcGEnwl2CLQVh1 SXqaufMR/mgsquTSLWu2nb/3oh7u4BterJUhcZ7Hn3uN04qPcdP1YCaf7K5E9v2a fNb44FZVXoEAWNxcBLZGVubsiVwoWPSmMEBf6nJMXFAcl23WH1OtVUytMb/k9p4W 4Qg1qg6eqJc0+xjll5ZfMw==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id CC.08.03684.7A6F8BA5; Mon, 26 Mar 2018 06:33:27 -0700 (PDT) X-AuditID: 11ab0215-4bdff70000000e64-22-5ab8f6a7326a Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 9C.29.21982.6A6F8BA5; Mon, 26 Mar 2018 06:33:27 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from chris-workmac.scv.apple.com (chris-workmac.scv.apple.com [17.192.192.12]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P6700DNL9NQ6Y40@nwk-mmpp-sz09.apple.com>; Mon, 26 Mar 2018 06:33:26 -0700 (PDT) Sender: cawood@apple.com From: Chris Wood In-reply-to: <20180326132800.GA17717@hephaistos.amsuess.com> Date: Mon, 26 Mar 2018 06:33:25 -0700 Cc: draft-trammell-taps-interface@ietf.org, taps@ietf.org Content-transfer-encoding: quoted-printable Message-id: <070B4070-B232-4386-9BF4-A5AC45E4EDA7@apple.com> References: <20180326132800.GA17717@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3445.6.10) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUi2FCYqrv8244og0/TLS327ehjsWg7+IvZ 4k6MA7NH18FfrB5LlvxkCmCK4rJJSc3JLEst0rdL4MrofnKKvWCORMXzvumsDYxThbsYOTkk BEwkNt84zNzFyMUhJLCWSWLzhMfMMIlvM94yQiTWM0l0XdjABpLgFRCU+DH5HksXIwcHs4C6 xJQpuRA1G5kkdi9dwQRSIywgIfF6z0RmCFtG4vWkWYwgNpuAssSFgwvZQWxOARuJpi3rWUBs FgFVif7Gd2A2s4ClxPb7i9ggbG2JJ+8usELstZG4uuMw2HwhAWuJQy/3gtWICNhKtMxYDXW0 ksT+vwfZQQ6SEOhgkzgz5SPTBEbhWUjunoVw9ywkKxYwMq9iFM5NzMzRzcwzMtRLLCjISdVL zs/dxAgK8dVMojsY578yPMQowMGoxMN74P/2KCHWxLLiytxDjNIcLErivNeeN0YJCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYAxZF3h31bqYl/eurtSI+Kik1LbvQ3L70pzyGRVMbR2Gj7Md 5saErbpXvn5T1OwJG/xPL9UO3hNkP6O+OzXS4oRnwJvAFzOYjb8x7ZzvOvX2idc7nZZf+/tq h9YLI2nBCWrLUjtnM/k6ZLt7RJtlfE/1OX7HhK8ifv70osScxLxTN29xvd+8M1WJpTgj0VCL uag4EQBDemNvUgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FAcoLv8244og38TWSz27ehjsWg7+IvZ 4k6MA7NH18FfrB5LlvxkCmCK4rJJSc3JLEst0rdL4MrofnKKvWCORMXzvumsDYxThbsYOTkk BEwkvs14y9jFyMUhJLCeSaLrwgY2kASvgKDEj8n3WLoYOTiYBdQlpkzJhajZyCSxe+kKJpAa YQEJidd7JjJD2DISryfNYgSx2QSUJS4cXMgOYnMK2Eg0bVnPAmKzCKhK9De+A7OZBSwltt9f xAZha0s8eXeBFWKvjcTVHYfB5gsJWEscerkXrEZEwFaiZcZqZoijlST2/z3IPoFRYBaSU2ch nDoLydQFjMyrGAWKUnMSK831EgsKclL1kvNzNzGCA7IwdQdj43KrQ4wCHIxKPLwSTDuihFgT y4orcw8xSnAwK4nw8s0HCvGmJFZWpRblxxeV5qQWH2KU5mBREue1qwBKCaQnlqRmp6YWpBbB ZJk4OKUaGO1kdZT3fVLfedf3loFB6xMpn4Y8jfgl6s0Wtr9V6td+mZ3U89p4wfP3gvf3pr2e uyvtd0v5knOrT3EaXzz+/OvSzv8cUm+u1W/v5rHluHzL586mX+Jih9Ypstvlh9dz1MdVfH35 96qY9hndoDOWj7hjX974I/J97vk/23fNNfwys3x31GEZkyQlluKMREMt5qLiRAC4vJ7pRAIA AA== Archived-At: Subject: Re: [Taps] Hello from CoRE X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 26 Mar 2018 13:33:31 -0000 Hi Christian, Please see inline below. Best, Chris > On Mar 26, 2018, at 6:28 AM, Christian Ams=C3=BCss = wrote: >=20 > Hello taps-interface authors, >=20 > I was having a look at the work of the TAPS Group on suggestion of > Theresa; my context is as an implementor the CoAP protocol, which is a > primarily UDP based protocol for RESTful interaction in constrained > ("IoT") environments (short: CoRE). >=20 > That protocol is a bit tricky to implement in full on POSIX sockets > because it requires that responses be sent from the destination = address > of the request, and because role reversal (a server that has received > requests starts sending requests to the original client) means that = even > a server needs to receive ICMP errors on messages it sends. While this > can be done on POSIX using various socket options and sendmsg/recvmsg, > it is not trivial to implement and sometimes badly supported by > platforms and language bindings. >=20 > I've had a look at the abstract API outlined in = trammell-taps-interface, > and it seems to be suitable for implementing CoAP in a much more > straightforward way, but I don't know yet whether it can do the > following: >=20 > * Can the API be instructed that a UDP package shall go out on the = same > IP and port as a given received package? (CoAP requirement) >=20 > * Can a listening (pre)connection be used to initiate a connection > actively from the listening port? (This is convenient to have because > it allows hosts to advertise their server role in a client capacity > without needing to transmit their own server address explicitly). >=20 > * Can the API be used for sending and receiving multicasts (or will > provide that in a later form)? >=20 > * On the topic of DTLS protected connections: Can the API give me a > handle to (or representation of) an outgoing packet in its encrypted > form, so that I can issue a retransmit at a later time using the same > DTLS sequence number? No. Such details are hidden beneath the API. Retransmission, for = example, would be something you specify on a per-message basis. >=20 > (There are mechanisms being specified with which CoAP can deal with > malicious reordering, but those keep track of lost packages. If the > packages get retransmitted as-was and get ack'ed, that mechanism can > save a few bytes). >=20 > * For CoAP, it is recommended to introspect an returning ICMP error to > see whether it is genuine (the headers match a sent package) and > relevant for various reasons (RFC7252 Section 4.2). >=20 > Will the API provide that detail to the protocol implementor, or can > the protocl implementor configure how to treat which errors? >=20 > And last but not least: Is there an implementation of this around I > could experiment with? >=20 > Best regards, > Christian >=20 > PS. Please keep me in To/Cc when replying, as I am not subscribed to = the > TAPS mailing list. >=20 > --=20 > We are dreamers, shapers, singers, and makers. > -- Elric From nobody Mon Mar 26 07:10: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 C779A127601; Mon, 26 Mar 2018 07:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 tWksDtU8UVbE; Mon, 26 Mar 2018 07:10:30 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD1A1275FD; Mon, 26 Mar 2018 07:10:24 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id AECC249657; Mon, 26 Mar 2018 16:10:22 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A92BF189; Mon, 26 Mar 2018 16:10:21 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 670EA3B6; Mon, 26 Mar 2018 16:10:21 +0200 (CEST) Received: (nullmailer pid 19750 invoked by uid 1000); Mon, 26 Mar 2018 14:10:20 -0000 Date: Mon, 26 Mar 2018 16:10:20 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Chris Wood Cc: draft-trammell-taps-interface@ietf.org, taps@ietf.org Message-ID: <20180326141020.GA18863@hephaistos.amsuess.com> References: <20180326132800.GA17717@hephaistos.amsuess.com> <070B4070-B232-4386-9BF4-A5AC45E4EDA7@apple.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <070B4070-B232-4386-9BF4-A5AC45E4EDA7@apple.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [Taps] Hello from CoRE X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 26 Mar 2018 14:10:32 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Chris, On Mon, Mar 26, 2018 at 06:33:25AM -0700, Chris Wood wrote: > > * On the topic of DTLS protected connections: [...] so that I can > > issue a retransmit at a later time using the same DTLS sequence > > number? >=20 > No. Such details are hidden beneath the API. Retransmission, for > example, would be something you specify on a per-message basis. Would that mean that I can tell it to send this particular message with, say, "retransmissit roughly after 2s, exponentialy fallin off with factor 2 for up to 4 transmissions", and can call off retransmission of that message when I've decoded a CoAP ACK? For that would work just as well. I'd only need to be informed whether the implementation retransmits with the same or a DTLS new sequence number, and whether such a retransmit actually happened. (The feedback to the application about the retransmits is not only relevant to the encrypted case, but also to tune the retransmission for applications as [1]). Thanks Christian [1]: https://tools.ietf.org/html/draft-ietf-core-cocoa-03 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlq4/0gACgkQOY0REtOk veGBog/9GCfSJiS/el4unsoq7XS167jtDAj7rPuZK2fxqpnSDwzI5GUaqrv9Ixh3 gC3lPCWZoYZtI2c/n6thHkbPfL52PcrDj6QhdOf+A+h1QXXKOTLmNNAzgxyaxNcR IG7BAHxr4ibisYA4MVn3fu7gwI2vLd4/VPNu+NZSvN1pZI8nV2wrlH9q0iGAKmvc kr+RIcxvdLEAWVensHn5//BQSnvPL3o3BYs3rnBwU7rHbU4A045RuCqGZ/DxkzyN 4zntDfmkucWtlnCR4ycVeAfwDsu7wPdQqc2T4K3q6zaXxxcC5j3j3W8Ra6x05kjb W6xGUBMHal84AiA9bykTCAk3/2edKebBL1W0S2j6ssrBUrtM38oTwjKVMvvZzTGi G87gHXhuEc3IktQMDPY4vOTdOLZCgH6ODtn9I3Mo0tJmayXn9sh1WIvDXJE9e31Z jK3+hSJ4vm/W60L2eH+WczuilmxPqHSjaZg6qQ8X1AvDpje5oi/zFDQGEq2alkMB 47NQEgmBiZVBedXOjaZRtTHRyjjWdLgp35zzU3tzqURgyNWtqMJyCie2+RvN9CvN qb2Y11B0STu+NZ8VuzeYphPzeItKRXMUJ3ZcCvzVyTzpWpOmFgVFmTRa+ZVM02v8 +AhDznq3UOPgsDoKrj26o3SY2t2PsUI75Qxf8Uo2OsZaLKh1RlI= =XlOo -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From nobody Mon Mar 26 08:44: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 B7FB01252BA for ; Mon, 26 Mar 2018 08:44:14 -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_RP_MATCHES_RCVD=-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 Dc0et5muhNgz for ; Mon, 26 Mar 2018 08:44:13 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (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 5D81E1243F3 for ; Mon, 26 Mar 2018 08:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1522079052; x=2385992652; 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=bxCin+xelYbHhIOxToNVhLfWm2kHidGlNM6xgohBBRU=; b=zGjDAVjrVaE3y893gZ/w9PiGTHC7JXqKpiNkgWQcl8m6z7raZaLxab3bArshC66K SVMWW+VFYGb+cAnQsNXdr6BHBMm5Jw4x4oPSsV1aViidmRi8ovtpfCyY3DIioDQs FHt6ANwhqIB9RaQym2D7EdKnQEze6Np2KMYg3ipJsT4ZJiWjdAlr4n744NPokTab BWNQCJc5kufcxkQTDuAVUDmiZGRVTGDU/m7Z2KLOnah+/yXhyDQurFcATqQo+NB2 tbO9NnjmBysmc5N5McVghAw3w7jwoAn4ovD8D3/ReSCDiIOkuFRY3oZT9RDfStog 3S+1DOYNFmOeesJ5X6FC8w==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 6C.D3.10828.B4519BA5; Mon, 26 Mar 2018 08:44:12 -0700 (PDT) X-AuditID: 11ab0218-260a89e000002a4c-a1-5ab9154bcbd8 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 9C.B6.23499.B4519BA5; Mon, 26 Mar 2018 08:44:11 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from chris-workmac.scv.apple.com (chris-workmac.scv.apple.com [17.192.192.12]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P67004A4FPNRC30@nwk-mmpp-sz09.apple.com>; Mon, 26 Mar 2018 08:44:11 -0700 (PDT) Sender: cawood@apple.com From: Chris Wood In-reply-to: <20180326141020.GA18863@hephaistos.amsuess.com> Date: Mon, 26 Mar 2018 08:44:10 -0700 Cc: draft-trammell-taps-interface@ietf.org, taps@ietf.org Content-transfer-encoding: quoted-printable Message-id: References: <20180326132800.GA17717@hephaistos.amsuess.com> <070B4070-B232-4386-9BF4-A5AC45E4EDA7@apple.com> <20180326141020.GA18863@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3445.6.10) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUi2FAYoesjujPKYMoTIYt9O/pYLNoO/mK2 uBPjwOzRdfAXq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDImH/zFUnCRq2Lx3/MsDYx7OboYOTgk BEwkfn7Q7GLk4hASWMMk8e38BcYuRk6w+PtNE5ghEuuZJHZu3MAGkuAVEJT4MfkeC0gzs4C6 xJQpuRA1G5kklr+8AFYjLCAh8XrPRGYIW0bi9aRZYEPZBJQlLhxcyA5icwrYSOw+sBSshkVA VWLe1y0sIDazgKXE9vuL2CBsbYkn7y6wguziBaqf3GYHsWsBo8TDu8fBekUEbCVaZqxmhjha SWL/34PsEHYHm8Stg1wTGIVnITl7FsLZs5BsWMDIvIpRODcxM0c3M8/IRC+xoCAnVS85P3cT Iyi8VzNJ7GD88trwEKMAB6MSD68D284oIdbEsuLK3EOM0hwsSuK8V583RgkJpCeWpGanphak FsUXleakFh9iZOLglGpg3HNQSTxv/ow5Rz9qbal3nHQlouFoTsX8HAfNlYdkXkntfLvNcb39 5H9TrghveCy9Oiml0m9JX68n+/1U0bvzNO40b76SMLehKn+Vh2RR/YMGq3fFZ45/3p0e8Nr5 beQ8jj8J1lJbloU5ifD89VDdsKnfuVjkjYlm02ahuBrDB/zy9/mP7mG6rcRSnJFoqMVcVJwI AICu0iJQAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FAcoOstujPK4ORGS4t9O/pYLNoO/mK2 uBPjwOzRdfAXq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDImH/zFUnCRq2Lx3/MsDYx7OboYOTkk BEwk3m+awNzFyMUhJLCeSWLnxg1sIAleAUGJH5PvsXQxcnAwC6hLTJmSC1GzkUli+csLYDXC AhISr/dMZIawZSReT5rFCGKzCShLXDi4kB3E5hSwkdh9YClYDYuAqsS8r1tYQGxmAUuJ7fcX sUHY2hJP3l1gBdnFC1Q/uc0OYtcCRomHd4+D9YoI2Eq0zFjNDHG0ksT+vwfZJzAKzEJy6iyE U2chmbqAkXkVo0BRak5ipaleYkFBTqpecn7uJkZwQBZG7GD8v8zqEKMAB6MSD+8Mjp1RQqyJ ZcWVuYcYJTiYlUR4+ebviBLiTUmsrEotyo8vKs1JLT7EKM3BoiTO28EFVC2QnliSmp2aWpBa BJNl4uCUamAs3LP/28U7vsveh1tWKL8yLg6OqFwd8sNs0uvvFl6C75RVEyQzRUJy87XOHBBN WfHz/TN+/lira/mPrqvZPfG75b299GZAUNQ1rv/3pSrPtGzssH+vvJV7obBG/+WiaUI50/Ln e57T+3xeXP9A/K7pawUMr5u5XVuhq8ph2+V+Pkzjv7zB9WQlluKMREMt5qLiRAAnehAJRAIA AA== Archived-At: Subject: Re: [Taps] Hello from CoRE X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 26 Mar 2018 15:44:15 -0000 > On Mar 26, 2018, at 7:10 AM, Christian Ams=C3=BCss = wrote: >=20 > Hello Chris, >=20 > On Mon, Mar 26, 2018 at 06:33:25AM -0700, Chris Wood wrote: >>> * On the topic of DTLS protected connections: [...] so that I can >>> issue a retransmit at a later time using the same DTLS sequence >>> number? >>=20 >> No. Such details are hidden beneath the API. Retransmission, for >> example, would be something you specify on a per-message basis. >=20 > Would that mean that I can tell it to send this particular message = with, > say, "retransmissit roughly after 2s, exponentialy fallin off with > factor 2 for up to 4 transmissions", and can call off retransmission = of > that message when I've decoded a CoAP ACK? I don=E2=80=99t know if the API as specified permits such fine-grained = control, though it certainly seems within reason.=20 >=20 > For that would work just as well. >=20 > I'd only need to be informed whether the implementation retransmits = with > the same or a DTLS new sequence number, and whether such a retransmit > actually happened. (The feedback to the application about the > retransmits is not only relevant to the encrypted case, but also to = tune > the retransmission for applications as [1]). Makes sense. Thanks for bringing this use case to the group! Best, Chris= From nobody Mon Mar 26 12:57:04 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 3F706126CC4; Mon, 26 Mar 2018 12:56:56 -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.76.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152209421616.15208.16943082849432364370@ietfa.amsl.com> Date: Mon, 26 Mar 2018 12:56:56 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transport-security-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2018 19:56:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : A Survey of Transport Security Protocols Authors : Tommy Pauly Colin Perkins Kyle Rose Christopher A. Wood Filename : draft-ietf-taps-transport-security-00.txt Pages : 29 Date : 2018-03-23 Abstract: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols. It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and WireGuard. This survey is not limited to protocols developed within the scope or context of the IETF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transport-security-00 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 26 13:20: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 0BA531276AF; Mon, 26 Mar 2018 13:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HJRsE5RMEbA3; Mon, 26 Mar 2018 13:20:02 -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 251D2126CC4; Mon, 26 Mar 2018 13:20:01 -0700 (PDT) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1f0Yb0-000FjO-Jl; Mon, 26 Mar 2018 22:19:58 +0200 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.10]) by mail-mx06.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.90_1) (envelope-from ) id 1f0Yay-0002qQ-4c; Mon, 26 Mar 2018 22:19:58 +0200 From: Michael Welzl Message-Id: <0BAAA7BD-C776-4664-9A7F-FF291AC42A3C@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_2A79F9FB-3824-46B2-A70D-EDB6F07F5457" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 26 Mar 2018 22:19:53 +0200 In-Reply-To: <20180326132800.GA17717@hephaistos.amsuess.com> Cc: draft-trammell-taps-interface@ietf.org, "taps@ietf.org" To: =?utf-8?Q?Christian_Ams=C3=BCss?= References: <20180326132800.GA17717@hephaistos.amsuess.com> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.10]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DF9E0EA17D850F38D8D4F227B2E5D5396100383C Archived-At: Subject: Re: [Taps] Hello from CoRE X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 26 Mar 2018 20:20:05 -0000 --Apple-Mail=_2A79F9FB-3824-46B2-A70D-EDB6F07F5457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Christian, Thanks a lot for your interest! I see you got a few answers already; I=E2=80=99ll complement with a few = more, in line: > On Mar 26, 2018, at 3:28 PM, Christian Ams=C3=BCss = wrote: >=20 > Hello taps-interface authors, >=20 > I was having a look at the work of the TAPS Group on suggestion of > Theresa; my context is as an implementor the CoAP protocol, which is a > primarily UDP based protocol for RESTful interaction in constrained > ("IoT") environments (short: CoRE). >=20 > That protocol is a bit tricky to implement in full on POSIX sockets > because it requires that responses be sent from the destination = address > of the request, and because role reversal (a server that has received > requests starts sending requests to the original client) means that = even > a server needs to receive ICMP errors on messages it sends. While this > can be done on POSIX using various socket options and sendmsg/recvmsg, > it is not trivial to implement and sometimes badly supported by > platforms and language bindings. >=20 > I've had a look at the abstract API outlined in = trammell-taps-interface, > and it seems to be suitable for implementing CoAP in a much more > straightforward way, but I don't know yet whether it can do the > following: >=20 > * Can the API be instructed that a UDP package shall go out on the = same > IP and port as a given received package? (CoAP requirement) >=20 > * Can a listening (pre)connection be used to initiate a connection > actively from the listening port? (This is convenient to have because > it allows hosts to advertise their server role in a client capacity > without needing to transmit their own server address explicitly). >=20 > * Can the API be used for sending and receiving multicasts (or will > provide that in a later form)? I think =E2=80=9Cwill provide that in a later form=E2=80=9D is the right = answer here. > * On the topic of DTLS protected connections: Can the API give me a > handle to (or representation of) an outgoing packet in its encrypted > form, so that I can issue a retransmit at a later time using the same > DTLS sequence number? >=20 > (There are mechanisms being specified with which CoAP can deal with > malicious reordering, but those keep track of lost packages. If the > packages get retransmitted as-was and get ack'ed, that mechanism can > save a few bytes). >=20 > * For CoAP, it is recommended to introspect an returning ICMP error to > see whether it is genuine (the headers match a sent package) and > relevant for various reasons (RFC7252 Section 4.2). >=20 > Will the API provide that detail to the protocol implementor, or can > the protocl implementor configure how to treat which errors? I think our goal is to describe something reasonable: - not too large - yet not entirely "lame" - and implementable I would say that a TAPS implementation should probably be free to = provide details such as the one you=E2=80=99re asking for here, but on = the other hand, I think we need to set some bounds to the list that will = end up in our doc as =E2=80=9Ca TAPS implementation MUST =E2=80=A6=E2=80=9D= - it=E2=80=99s easy for this list to grow endlessly. *Right now*, your = requested ICMP functionality is not in our list. I also suspect that it = falls in the category of =E2=80=9Ccan be done under the hood=E2=80=9D. = Whatever can reasonably be done under the hood should not be exposed in = our API. > And last but not least: Is there an implementation of this around I > could experiment with? Yes, we have NEAT: https://github.com/NEAT-project/neat = - please do play with it ! Cheers, Michael --Apple-Mail=_2A79F9FB-3824-46B2-A70D-EDB6F07F5457 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Christian,

        Thanks a lot for your interest!
        I see = you got a few answers already; I=E2=80=99ll complement with a few more, = in line:


        On = Mar 26, 2018, at 3:28 PM, Christian Ams=C3=BCss <christian@amsuess.com> wrote:

        Hello = taps-interface authors,

        I was having a look = at the work of the TAPS Group on suggestion of
        Theresa; my = context is as an implementor the CoAP protocol, which is a
        primarily UDP based protocol for RESTful interaction in = constrained
        ("IoT") environments (short: CoRE).

        That protocol is a bit tricky to implement in = full on POSIX sockets
        because it requires that responses = be sent from the destination address
        of the request, and = because role reversal (a server that has received
        requests = starts sending requests to the original client) means that even
        a server needs to receive ICMP errors on messages it sends. = While this
        can be done on POSIX using various socket = options and sendmsg/recvmsg,
        it is not trivial to = implement and sometimes badly supported by
        platforms and = language bindings.

        I've had a look at the = abstract API outlined in trammell-taps-interface,
        and it = seems to be suitable for implementing CoAP in a much more
        straightforward way, but I don't know yet whether it can do = the
        following:

        * Can the API = be instructed that a UDP package shall go out on the same
        =  IP and port as a given received package? (CoAP requirement)

        * Can a listening (pre)connection be used to = initiate a connection
         actively from the listening = port? (This is convenient to have because
         it allows = hosts to advertise their server role in a client capacity
        =  without needing to transmit their own server address = explicitly).

        * Can the API be used for = sending and receiving multicasts (or will
         provide = that in a later form)?

        I think =E2=80=9Cwill provide that in a later = form=E2=80=9D is the right answer here.

        * On the topic of DTLS protected connections: Can the API = give me a
         handle to (or representation of) an = outgoing packet in its encrypted
         form, so that I = can issue a retransmit at a later time using the same
        =  DTLS sequence number?

         (There = are mechanisms being specified with which CoAP can deal with
         malicious reordering, but those keep track of lost = packages. If the
         packages get retransmitted as-was = and get ack'ed, that mechanism can
         save a few = bytes).

        * For CoAP, it is recommended to = introspect an returning ICMP error to
         see whether = it is genuine (the headers match a sent package) and
        =  relevant for various reasons (RFC7252 Section 4.2).

         Will the API provide that detail to the = protocol implementor, or can
         the protocl = implementor configure how to treat which errors?

        I = think our goal is to describe something reasonable:
        - not too = large
        - yet not entirely "lame"
        - and = implementable

        I would say that a = TAPS implementation should probably be free to provide details such as = the one you=E2=80=99re asking for here, but on the other hand, I think = we need to set some bounds to the list that will end up in our doc as = =E2=80=9Ca TAPS implementation MUST =E2=80=A6=E2=80=9D - it=E2=80=99s = easy for this list to grow endlessly. *Right now*, your requested ICMP = functionality is not in our list. I also suspect that it falls in the = category of =E2=80=9Ccan be done under the hood=E2=80=9D. Whatever can = reasonably be done under the hood should not be exposed in our = API.


        And last but = not least: Is there an implementation of this around I
        could= experiment with?

        Yes, we have NEAT:
         - = please do play with it !

        Cheers,
        Michael

        = --Apple-Mail=_2A79F9FB-3824-46B2-A70D-EDB6F07F5457-- From nobody Wed Mar 28 01:55: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 D094A124C27; Wed, 28 Mar 2018 01:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zphuuALNpN88; Wed, 28 Mar 2018 01:55:31 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id B17FF1200C1; Wed, 28 Mar 2018 01:55:30 -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 94071590; Wed, 28 Mar 2018 10:55:29 +0200 (CEST) To: =?UTF-8?Q?Christian_Ams=c3=bcss?= , draft-trammell-taps-interface@ietf.org Cc: taps@ietf.org References: <20180326132800.GA17717@hephaistos.amsuess.com> From: Theresa Enghardt Message-ID: <0c960b8f-58ba-17f6-b5ca-dcceac097c3b@inet.tu-berlin.de> Date: Wed, 28 Mar 2018 10:55:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180326132800.GA17717@hephaistos.amsuess.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qDPJW7xCgI0o5SWehkx3ElEhdOomPzZ4V" Archived-At: Subject: Re: [Taps] Hello from CoRE X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2018 08:55:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qDPJW7xCgI0o5SWehkx3ElEhdOomPzZ4V Content-Type: multipart/mixed; boundary="EhNs5wd4fz0iQw53PnPJ7Th8eJ06IcmUP"; protected-headers="v1" From: Theresa Enghardt To: =?UTF-8?Q?Christian_Ams=c3=bcss?= , draft-trammell-taps-interface@ietf.org Cc: taps@ietf.org Message-ID: <0c960b8f-58ba-17f6-b5ca-dcceac097c3b@inet.tu-berlin.de> Subject: Re: [Taps] Hello from CoRE References: <20180326132800.GA17717@hephaistos.amsuess.com> In-Reply-To: <20180326132800.GA17717@hephaistos.amsuess.com> --EhNs5wd4fz0iQw53PnPJ7Th8eJ06IcmUP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Christian, thanks for your interest and for the really good questions. On 26.03.2018 15:28, Christian Ams=FCss wrote: > [=85] > > I've had a look at the abstract API outlined in trammell-taps-interface= , > and it seems to be suitable for implementing CoAP in a much more > straightforward way, but I don't know yet whether it can do the > following: > > * Can the API be instructed that a UDP package shall go out on the same= > IP and port as a given received package? (CoAP requirement) Yes. The application would have to create a connection with the desired properties, e.g. similar to UDP, specify a certain IP address and port as local endpoint, receive messages on the connection (=3DUDP packets), and then send on the same connection, thus using the same IP address. > * Can a listening (pre)connection be used to initiate a connection > actively from the listening port? (This is convenient to have because= > it allows hosts to advertise their server role in a client capacity > without needing to transmit their own server address explicitly). I think the API allows it. You call Listen() on the Preconnection and you get ConnectionReceived events, but you can still call Initiate() on the same Preconnection. But I'm not sure what happens then... something to think about :) Best, Theresa --=20 Theresa Enghardt Wissenschaftliche Mitarbeiterin / Research Assistant Phone: +49 30 314 78628 Office: MAR 4.032 FG / Group "Internet Network Architectures" (INET) Technische Universit=E4t Berlin Sekr. MAR 4-4, Marchstra=DFe 23, 10587 Berlin --EhNs5wd4fz0iQw53PnPJ7Th8eJ06IcmUP-- --qDPJW7xCgI0o5SWehkx3ElEhdOomPzZ4V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQFOBAEBCAA4FiEE7xG3phZ0Plgk2BDpgz007xx2oPcFAlq7WHkaHHRoZXJlc2FA aW5ldC50dS1iZXJsaW4uZGUACgkQgz007xx2oPcZzQf9FihwdHGr298QKRR8eMsJ rvOdyCeBGzNolw+8ATvMU/ZMUTH5DYjx6fW8cIWJaD+QWAc8h+nhLLODWTKay3m9 Ou0N6+Bh8BcnBnkexg62QIY3xaO7Ijj5z1xVcSzwPbpZmgqxfo3ZBkYUAEW6T5+7 3a6N2I2k9iMjSO5FQRYRBjhcMnnPCtwVRcYAL9QZlTSuA22yUq02FZsvo7kyVXg1 6oOLCfv9W1GhhUMd8lhqWdU8AcEicZnDT2u+oAJLc4+6AzmbBwIbvqEkDAQjz9H7 5kR3gM7aHhVSmH76Neh7rsVOZJ/RBM7BX0fScs7RpfHQzDDNGSKskS/Kw8B8DV3J xw== =lHJ5 -----END PGP SIGNATURE----- --qDPJW7xCgI0o5SWehkx3ElEhdOomPzZ4V--