From nobody Tue Jan 2 08:05: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 749AD12D0C3 for ; Tue, 2 Jan 2018 08:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 xcrK6KeCuhfZ for ; Tue, 2 Jan 2018 08:05:10 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E9912706D for ; Tue, 2 Jan 2018 08:05:09 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id c5so2768276qkg.6 for ; Tue, 02 Jan 2018 08:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=wXYpXhAGMURKfQfY4ywpBdeqK3JLa57euigPEvx6dBM=; b=ZPUsg/ndmeq49wb1KepW4ui6USXmneQqY/8nEDjNHX+xnk9wBdT5myl+Q7A7HNVYbE srE9nFmO4iNVqpUY2COSWH/6QQ8XAK9yO16w2U1kXWdtgn269kMNmBffi4ayl/CkE/RN ePJPOhdWJ6uwn2dAjSfwNtllArQufO4bCJ2hJGFHwXMliH3xbi9j9JQCXsEzRnaaQJQX TYjrpLVUlTZ3AHUEAu+OzOr76d7FDm8ERuYNQVk7l9x9nSzvITkzeBPmd1/3AkLrnT+b 46Emw0jQqA98AY9QPDK6PPQPGhzZfKySHZCsf4k/yQFWRS1h+bF2/fpYth69tE0+g7dE ntTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wXYpXhAGMURKfQfY4ywpBdeqK3JLa57euigPEvx6dBM=; b=GFELoSTPj34qkHghOoVsFYvhMBj8zx+Jz0Px7S/gs3Ca38KN/Rd0XLQ66VEdboE2rF 685PYUwiXRpSOt10bIwyNsf+ln0wIce5ijA+b3Bp5+jz0HyyPowtuaYHCtMtO3XkzxK2 kVfpMJwu+r6JH/c+augwfxkX4gBY73/d2Hg+JP099ePG1eiOBo+rg0KsKrvNIOy5swaJ KyarnLu+Cwc3V9wQ3nzy8Dse/4KsiVpLtqZfXePV9uLoDEPQWB71rSWZFC9BFQn2sS0r tfuVQdmcgYFrQyG90yhLsiVxbZlFMgE/z+JIbt/PneeYUk8+IDL8CMx3cmhChJH9T4SR aEIQ== X-Gm-Message-State: AKGB3mJBh0rlj/OaYNFryIRJuDnSDKNJjAHETeYlKH+b3z/bFBu3mCBS JMGFcCTDbc0UTsj+NlwM8yQ= X-Google-Smtp-Source: ACJfBou7Rw+4id/NS4+8hprmNEbxvbFveTlBFWIZiuKkwloPOVSvU9lSW8ktVCrx8g3xIXczSzxvWA== X-Received: by 10.55.215.93 with SMTP id m90mr60435992qki.27.1514909108788; Tue, 02 Jan 2018 08:05:08 -0800 (PST) Received: from [169.254.217.57] ([2001:4878:a000:3000:ace6:3cb1:ad90:78a3]) by smtp.gmail.com with ESMTPSA id j17sm18869437qkh.6.2018.01.02.08.05.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jan 2018 08:05:07 -0800 (PST) From: "Aaron Falk" To: "tom p." Cc: "Ignacio Solis" , "taps WG" Date: Tue, 02 Jan 2018 11:05:06 -0500 X-Mailer: MailMate (1.10r5443) Message-ID: <308CBA10-1BDA-48DE-B440-E4690864E6A6@gmail.com> In-Reply-To: <000901d37fd3$e50df300$4001a8c0@gateway.2wire.net> References: <000901d37fd3$e50df300$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] Draft TAPS minutes 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, 02 Jan 2018 16:05:11 -0000 On 28 Dec 2017, at 7:03, tom p. wrote: > TAPS is doing rather > well; and yes, TAPS are good minutes, not a link to or transcription > of, Etherpad. Funny enough, the minutes are exactly what is in the Etherpad. The key is to get good minute-takers. Glad you find them helpful. —aaron From nobody Wed Jan 3 13:13:26 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DD812AF83 for ; Wed, 3 Jan 2018 13:13:24 -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 j569YuGsOjau for ; Wed, 3 Jan 2018 13:13:22 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 AF86E1270AC for ; Wed, 3 Jan 2018 13:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1515014002; 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=P5WQSdZcL3mL9V2fVN4VMOJbmiVdxviXYHmKylopuAc=; b=ITvwtA1cPicBerh//kjCV5ZFc0ZlIrPBcp4zOZxl3HnLEauoZXJSg156TTQ/hbR+ TlYh3ZWV3n6PtpKAch59tYpWQOTgvBM4+tExTLjiVlLPibyRnMuD4s8455ClOrXB aX73QhRij3QIYUQxVjl6d55RrPG8nTuBtHQz0wT9T1jo9eJzq2u4lt+signGHDHH qAEx4Mde4fBUAOJgpUySiR2LB25Oh+TjEgPq7FvnA1rPQIzPKa1p0mEO6HEAzuLX M/OSkHkUCaPnIj/lqJt7anU2kFIXpRsXm0zNMtRzMb43lQLqjzeLdSUI8IuOryV7 ptB0vi1OpZPzHoPmhkqSiA==; 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-in6.apple.com (Apple Secure Mail Relay) with SMTP id 15.BD.20985.2774D4A5; Wed, 3 Jan 2018 13:13:22 -0800 (PST) X-AuditID: 11973e15-265ff700000051f9-ca-5a4d4772bee2 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay7.apple.com (Apple SCV relay) with SMTP id 25.D1.05443.2774D4A5; Wed, 3 Jan 2018 13:13:22 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_IPRYkm/2RQUlvTjsOSGEJg)" Received: from [17.234.35.45] (unknown [17.234.35.45]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.1.20171204 64bit (built Dec 4 2017)) with ESMTPSA id <0P2000L1X0A9RH10@nwk-mmpp-sz09.apple.com>; Wed, 03 Jan 2018 13:13:22 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <3F9EBCE7-EAC7-41CF-854F-00838A828280@apple.com> Date: Wed, 03 Jan 2018 13:13:21 -0800 In-reply-to: <52746EE2-1898-4879-8B33-C2AF17FC812D@gmail.com> Cc: Robert Moskowitz , Brian Trammell , Kyle Rose , Michael Welzl , "taps@ietf.org" , Chris Wood To: Aaron Falk References: <05F414A1-A2B3-4EF6-A280-DC9DD421B3EC@ifi.uio.no> <406114AF-F4DC-4FB4-B75E-54922F78799A@trammell.ch> <1EDFF789-D5D2-4A52-ABF6-5D6D1B1E61C3@apple.com> <52746EE2-1898-4879-8B33-C2AF17FC812D@gmail.com> X-Mailer: Apple Mail (2.3458) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUi2FCYqlvk7htlsPyomEXb72msFhtb3rFZ rH8xic3ix9mdrBavj71hsbgT48DmsXPWXXaP3ZOa2D2WLPnJ5LF69UNmj66L35k8nuyfyRLA FsVlk5Kak1mWWqRvl8CV8WnvDaaCzQ4Vl48vYW5g3GrRxcjJISFgItGwaDlrFyMXh5DAGiaJ D4ues8IkHm37CpU4yCixYfoGsASvgKDEj8n3WEBsZoEwia//ZzJDFPUzSXxa9x7I4eAQFpCQ 2LwnEaSGTUBF4vi3DWBhXgEbiZM7OSAq9CWeztECqWARUJX486WHBSTMKWArcXdnOshAZoGb jBKv1l9hBKkRAapZ9qKdDWLTLSaJb6/esEDcKSuxcvZdsDslBK6zSXzoecE6gVFoFpJTZyE5 dRbQEmYBdYkpU3IhwtoST95dYIWw1SQW/l7EhCy+gJFtFaNQbmJmjm5mnpleYkFBTqpecn7u JkZQVE23E93BeGaV1SFGAQ5GJR7ehhs+UUKsiWXFlbmHGKU5WJTEec9rAoUE0hNLUrNTUwtS i+KLSnNSiw8xMnFwSjUwlh7/Wrr3/P/XnEEXL8w46CkvZKrMGVOmtmoH/+KnW+4pOm4/bRjy eP86lstXfrcv/mHwKV+vXHx+inRWkm0wZxY/Y3pfqLj1y4UnHzZPbZ3+9v517U1zqv6/Ppa/ nSuIk3fbqdANH5QPPYpdYvDl9b6p4syOU+2VmDd+t/NkOG7kqD5jRQx3thJLcUaioRZzUXEi APOKmdqLAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUi2FAcoFvk7htl8O+KgEXb72msFhtb3rFZ rH8xic3ix9mdrBavj71hsbgT48DmsXPWXXaP3ZOa2D2WLPnJ5LF69UNmj66L35k8nuyfyRLA FsVlk5Kak1mWWqRvl8CV8WnvDaaCzQ4Vl48vYW5g3GrRxcjJISFgIvFo21fWLkYuDiGBg4wS G6ZvYAVJ8AoISvyYfI8FxGYWCJP4+n8mM0RRP5PEp3XvgRwODmEBCYnNexJBatgEVCSOf9sA FuYVsJE4uZMDokJf4ukcLZAKFgFViT9felhAwpwCthJ3d6aDDGQWuMko8Wr9FUaQGhGgmmUv 2tkgNt1ikvj26g0LxJ2yEitn32WdwMg/C8l1s5BcNwtoLrOAusSUKbkQYW2JJ+8usELYahIL fy9iQhZfwMi2ilGgKDUnsdJcL7GgICdVLzk/dxMjOAoKU3cwNi63OsQowMGoxMPbcMMnSog1 say4MvcQowQHs5IIr1sWUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjv7kNOUUIC6YklqdmpqQWp RTBZJg5OqQbGhIs+cw+faz245dZsm0LLkum5a66ZpeyrnLek1n3izkOGLrNeHNYLXXlt3pni U8cmyNxcWffywM+J4Q9UO3bKL2cV58lZzbb/zuPQ1GKRS//2/pjVoMqWNeXttE9/lRwa3bfK 2r42aN3e2vjpQHfiebWHF1fvDvm9J7j14rb2x/PYguoaL6TKuyqxFGckGmoxFxUnAgCfGyt9 fgIAAA== Archived-At: Subject: Re: [Taps] Charter change for security 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, 03 Jan 2018 21:13:24 -0000 --Boundary_(ID_IPRYkm/2RQUlvTjsOSGEJg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Aaron, We=E2=80=99ve just posted an update to the Transport Security protocol = survey = (https://tools.ietf.org/html/draft-pauly-taps-transport-security-01 = ), = and noted that the charter for TAPS is still waiting for the update to = the text as proposed by Kyle. Can you give an update on the status of this, and if we have the request = already sent to the ADs? Best, Tommy > On Jul 18, 2017, at 5:21 AM, Aaron Falk wrote: >=20 > This is fine with me. Brief pause for any objections before making = the charter change request to the ADs=E2=80=A6 >=20 > =E2=80=94aaron >=20 >=20 > On 18 Jul 2017, at 13:40, Robert Moskowitz wrote: >=20 >> I just joined this list. >>=20 >> I can work with this. >>=20 >> Bob >>=20 >> On 07/18/2017 01:36 PM, Tommy Pauly wrote: >>> Agreed. Thanks for the text proposal, Kyle! >>>=20 >>> Tommy >>>=20 >>>> On Jul 18, 2017, at 12:15 PM, Brian Trammell (IETF) = wrote: >>>>=20 >>>> +1. >>>>=20 >>>> Cheers, >>>>=20 >>>> Brian >>>>=20 >>>>> On 18 Jul 2017, at 12:02, Michael Welzl = wrote: >>>>>=20 >>>>> Agree 100% - I think this proposal is exactly the right way to do = it. >>>>>=20 >>>>> Cheers, >>>>> Michael >>>>>=20 >>>>>=20 >>>>>> On Jul 18, 2017, at 11:12 AM, Kyle Rose wrote: >>>>>>=20 >>>>>> Proposal: >>>>>>=20 >>>>>> (1) Strike the last paragraph of the charter ("TAPS is not = chartered to perform detailed analysis..."). >>>>>>=20 >>>>>> (2) Change the third bullet right above it to read "Extension, = modification, or creation of transport or security protocols" >>>>>>=20 >>>>>> The idea being to permit analysis of the properties of security = protocols with respect to the requirements of TAPS systems, but not to = permit creation or customization of security protocols. >>>>>>=20 >>>>>> Thoughts? >>>>>>=20 >>>>>> Kyle >>>>>> _______________________________________________ >>>>>> 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 >>=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 --Boundary_(ID_IPRYkm/2RQUlvTjsOSGEJg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = Aaron,

We=E2=80=99ve = just posted an update to the Transport Security protocol survey (https://tools.ietf.org/html/draft-pauly-taps-transport-security= -01), and noted that the charter for TAPS is still waiting for the = update to the text as proposed by Kyle.

Can you give an update on the status of = this, and if we have the request already sent to the ADs?

Best,
Tommy

On Jul = 18, 2017, at 5:21 AM, Aaron Falk <aaron.falk@gmail.com> wrote:

This = is fine with me.  Brief pause for any objections before making the = charter change request to the ADs=E2=80=A6

=E2=80=94aaron


On = 18 Jul 2017, at 13:40, Robert Moskowitz wrote:

I just joined this = list.

I can work with this.
Bob

On 07/18/2017 01:36 PM, = Tommy Pauly wrote:
Agreed. Thanks for the text proposal, Kyle!

Tommy

On Jul 18, 2017, at 12:15 PM, Brian Trammell (IETF) <ietf@trammell.ch> = wrote:

+1.

Cheers,

Brian

On 18 Jul 2017, at = 12:02, Michael Welzl <michawe@ifi.uio.no> wrote:

Agree 100% - I think this proposal is exactly the right way = to do it.

Cheers,
Michael


On Jul 18, 2017, at 11:12 AM, Kyle Rose <Krose@krose.org> = wrote:

Proposal:

(1) Strike the last paragraph of the charter ("TAPS is not = chartered to perform detailed analysis...").

(2) Change the third bullet right above it to read = "Extension, modification, or creation of transport or security = protocols"

The idea being to permit = analysis of the properties of security protocols with respect to the = requirements of TAPS systems, but not to permit creation or = customization of security protocols.

Thoughts?

Kyle
_______________________________________________
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

_______________________________________________
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_IPRYkm/2RQUlvTjsOSGEJg)-- From nobody Wed Jan 3 13:15: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 5368B1270AC for ; Wed, 3 Jan 2018 13:15:09 -0800 (PST) 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 tlEXzXsfyOSn for ; Wed, 3 Jan 2018 13:15:06 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532D4126C83 for ; Wed, 3 Jan 2018 13:15:06 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id d4so3774279qtj.5 for ; Wed, 03 Jan 2018 13:15:06 -0800 (PST) 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=/UUq+yvNknpAP143tBCrtj9ZI31k46bmPr61BuIjBG8=; b=ioEHmpFn1ixwksBR18reYYa4hNF32CjrrCv+A9yNOzHG3nuKQcnwb1i16cMhRYCLGp 7ycHEq1occuZKYu8iUatEft4L89SPQ69JCqEo8bcNEWjCIcYDR6SKgRfOwIrp/aRmPuv emmmcM1NAV+yn9eew+xYhB3d4QtbSau4w7/ooR6hqINHEGHho7QvTqqKwNjW/NIT0hD8 fJsWHda3GSRkrQdHyNVm9g7oF19phtZnvWnEES6Zz5j5jk0r05JeHG8eqQmGToxiFKYi Uaw+cOyap/1+bEngYxYE1iKTM08mcHBbjoxeCYo8yFl7T5ppDJYSMccIC38ZgBEEZmO5 ZOOg== 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=/UUq+yvNknpAP143tBCrtj9ZI31k46bmPr61BuIjBG8=; b=rhz8KGp0zS+fzzfqHeIpSu/kl57UOQkVH7tR8Hz47Jsk2yIvxYoaxwHuG/WA0EJghl YhEaXAjrjvIm8GSruveMdsIGsOSEhgsqBzB7ZE72Fvurh3EeYgD5mP/oFU+EOg/iLdSm g52LzqRSWqJ7l/7cfVrUJZkJ85zcESyNjAxpXlzMNn+ejJdpw0/3Um5d4BeyVpGi4/hN jvJsCU7LODmoUGyRBR5X6z7N2kPDXItGtU+OH4IbKAljWw8Yg19MWevtNazhjIg9OZAX vl2vqAv6yBBayX38Tc9wGef0YB76YpdL30j5r9JAiByDI2X42SgilpTr504u/aeUNoqw 22jA== X-Gm-Message-State: AKGB3mKMe/Z5CDfyn/CEVa4kn8vl6z/b7JcoRKdM7Wb5IKfytsMvePTp t8OjM32morKHYOriZ3W1j/2ylO+PGI0= X-Google-Smtp-Source: ACJfBov4ccSMUm/8E2NMlEr3UfbMs48T7TOuDvyeB2P3CS3AQ3NtqmejfuY0wMhxOLWa7oBW3JGnkA== X-Received: by 10.200.44.154 with SMTP id 26mr3424015qtw.186.1515014105381; Wed, 03 Jan 2018 13:15:05 -0800 (PST) Received: from [172.19.38.30] ([2001:4878:a000:3000:d538:5277:5453:7b58]) by smtp.gmail.com with ESMTPSA id t48sm1167759qtc.10.2018.01.03.13.15.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jan 2018 13:15:04 -0800 (PST) From: "Aaron Falk" To: "Tommy Pauly" Cc: "Robert Moskowitz" , "Brian Trammell" , "Kyle Rose" , "Michael Welzl" , taps@ietf.org, "Chris Wood" Date: Wed, 03 Jan 2018 16:15:09 -0500 X-Mailer: MailMate (1.10r5443) Message-ID: In-Reply-To: <3F9EBCE7-EAC7-41CF-854F-00838A828280@apple.com> References: <05F414A1-A2B3-4EF6-A280-DC9DD421B3EC@ifi.uio.no> <406114AF-F4DC-4FB4-B75E-54922F78799A@trammell.ch> <1EDFF789-D5D2-4A52-ABF6-5D6D1B1E61C3@apple.com> <52746EE2-1898-4879-8B33-C2AF17FC812D@gmail.com> <3F9EBCE7-EAC7-41CF-854F-00838A828280@apple.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_AF2BDD40-D7A8-42D4-BEE2-EABA1870940B_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[571, 4498], "plain":[192, 2750], "uuid":"3AD8BF9F-F1B0-438E-ABB7-10C28F0A44B5"}] Archived-At: Subject: Re: [Taps] Charter change for security 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, 03 Jan 2018 21:15:09 -0000 --=_MailMate_AF2BDD40-D7A8-42D4-BEE2-EABA1870940B_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for the revision, Tommy. The status is ‘no progress’ but (surprise!) in response to your note I will do something now. :) —aaron On 3 Jan 2018, at 16:13, Tommy Pauly wrote: > Hi Aaron, > > We’ve just posted an update to the Transport Security protocol > survey > (https://tools.ietf.org/html/draft-pauly-taps-transport-security-01 > ), > and noted that the charter for TAPS is still waiting for the update to > the text as proposed by Kyle. > > Can you give an update on the status of this, and if we have the > request already sent to the ADs? > > Best, > Tommy > >> On Jul 18, 2017, at 5:21 AM, Aaron Falk wrote: >> >> This is fine with me. Brief pause for any objections before making >> the charter change request to the ADs… >> >> —aaron >> >> >> On 18 Jul 2017, at 13:40, Robert Moskowitz wrote: >> >>> I just joined this list. >>> >>> I can work with this. >>> >>> Bob >>> >>> On 07/18/2017 01:36 PM, Tommy Pauly wrote: >>>> Agreed. Thanks for the text proposal, Kyle! >>>> >>>> Tommy >>>> >>>>> On Jul 18, 2017, at 12:15 PM, Brian Trammell (IETF) >>>>> wrote: >>>>> >>>>> +1. >>>>> >>>>> Cheers, >>>>> >>>>> Brian >>>>> >>>>>> On 18 Jul 2017, at 12:02, Michael Welzl >>>>>> wrote: >>>>>> >>>>>> Agree 100% - I think this proposal is exactly the right way to do >>>>>> it. >>>>>> >>>>>> Cheers, >>>>>> Michael >>>>>> >>>>>> >>>>>>> On Jul 18, 2017, at 11:12 AM, Kyle Rose wrote: >>>>>>> >>>>>>> Proposal: >>>>>>> >>>>>>> (1) Strike the last paragraph of the charter ("TAPS is not >>>>>>> chartered to perform detailed analysis..."). >>>>>>> >>>>>>> (2) Change the third bullet right above it to read "Extension, >>>>>>> modification, or creation of transport or security protocols" >>>>>>> >>>>>>> The idea being to permit analysis of the properties of security >>>>>>> protocols with respect to the requirements of TAPS systems, but >>>>>>> not to permit creation or customization of security protocols. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Kyle >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> _______________________________________________ >>> 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_AF2BDD40-D7A8-42D4-BEE2-EABA1870940B_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Thanks for the revision, Tommy. The status is =E2=80=98no= progress=E2=80=99 but (surprise!) in response to your note I will do som= ething now. :)

=E2=80=94aaron

On 3 Jan 2018, at 16:13, Tommy Pauly wrote:

Hi Aaron,

We=E2=80=99ve just posted an update to the Transport = Security protocol survey (https://tools.ietf.org/html/dr= aft-pauly-taps-transport-security-01), and noted that the charter for= TAPS is still waiting for the update to the text as proposed by Kyle.

Can you give an u= pdate on the status of this, and if we have the request already sent to t= he ADs?

Best,
Tommy

On Jul 18, 2017, = at 5:21 AM, Aaron Falk <aaron.falk@gmail.com> wrote:

This is fine with me.  Br= ief pause for any objections before making the charter change request to = the ADs=E2=80=A6

=E2=80=94aaron


On 18 Jul 2017, at 13:40, Robert Moskowit= z wrote:

I just joined this list.

I can work with t= his.

Bob

On 07/= 18/2017 01:36 PM, Tommy Pauly wrote:
Agreed. Thanks for the text proposal, Kyle!
=
Tommy

On Jul 18, 2017, at 12:15 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrot= e:

+1.

Cheers,<= br class=3D"">
Brian

On 18 Jul 2017, at 12:02, Michael Welzl <<= a href=3D"mailto:michawe@ifi.uio.no" class=3D"">michawe@ifi.uio.no>= ; wrote:

Agree 100% - I think this proposal = is exactly the right way to do it.

Cheers,Michael


On Jul 18, 2017, at 11:12 AM, Kyle Rose <= Krose@krose.org> wro= te:

Proposal:

(= 1) Strike the last paragraph of the charter ("TAPS is not chartered to pe= rform detailed analysis...").

(2) Change the= third bullet right above it to read "Extension, modification, or creatio= n of transport or security protocols"

The id= ea being to permit analysis of the properties of security protocols with = respect to the requirements of TAPS systems, but not to permit creation o= r customization of security protocols.

Thoug= hts?

Kyle
____________________= ___________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
= _______________________________________________
Taps mailin= g list
Taps@iet= f.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 mai= ling list
Taps@= ietf.org
https://www.ietf.org/mailman/listinfo/taps

__________________________________= _____________
Taps mailing list
Taps@ietf.org
https://ww= w.ietf.org/mailman/listinfo/taps
<= /div>
--=_MailMate_AF2BDD40-D7A8-42D4-BEE2-EABA1870940B_=-- From nobody Wed Jan 3 13:20: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 9E02E129C6C; Wed, 3 Jan 2018 13:20:55 -0800 (PST) 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 B-UdgrfRTtuw; Wed, 3 Jan 2018 13:20:54 -0800 (PST) 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 D00C0128C0A; Wed, 3 Jan 2018 13:20:53 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id u10so3803478qtg.2; Wed, 03 Jan 2018 13:20:53 -0800 (PST) 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=LOPywhiwm8mlbAsJoxeg9snxAdYZ0A6fBp7jJYtOG64=; b=Wgqc+NSQnMN69ImZkFjXVE7Q0Wu2Uzt9jniD/HMEc2NlLbEFc4PipCEBG2T5QkJKRI yQnDG/o6gv4pWdczdkesYUNc6iapLo95Wde+W/bR6ZBn3Ocb8/xSvdU+Bozg74RoQJ1T psHGiCLdJCEocFvGgZmNWqdNys3NPR97GgT+tGqf/C3ZOvXDPEREHfShD++JaYWdPDDJ 4yhRHIwB3NhaCA7/MhX3qDk1WSJamKXDarhc847ZVd9IxcVU4oYjv+DW0z7U2p8ObodV fOxWnbZSIH0UrDV1X5VEJP5wNuJniROn7PU20YQ9RdLkUuI5kZra273DO8yPnZtq2dkz crbw== 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=LOPywhiwm8mlbAsJoxeg9snxAdYZ0A6fBp7jJYtOG64=; b=fsgCEcw4axOTtPG4XayZWSl5dRemMhBm+1x1qnF/3k5E2xlg9msFGdzszLib2/vQE7 RS0EDBfha+dtT8TCa3a6J90FDfibcIUWrWL1IL4oNNw4CG4CJGjRW559tjlypNymqy3m C4Q5xIk4tEbcXqRhN+I87gbCEeA2etpc3+9ZjuwIRclzsdmY13L9QcP4Wpc59Jh/ov4M FTcR7HfVZBkSIFdgBl57yVN9hzlooq/08Fdw7LRZ9AbDHnKieAS8LOtJefgkXtSY8kB2 OvCcCV7kqePhn+eYM0dcR/neLDgBCZ2+kBBkevLjnlyp09fyveCBxgsJlFpHkp6R9oN+ D82A== X-Gm-Message-State: AKGB3mJ0X/2yPYs8XsafqzdJ5bzv+jLih4A6mfkmHB0Le3+4E/XqP0BZ 1k32K1ZMXjVfpuAxFf79+p2LRC8XyQY= X-Google-Smtp-Source: ACJfBouDhCF5gQcA1Z39RK4Pfz/BW4b63rBljFeQSDHnNyo1kSu32Azuz08et/uqprL8yRtOmmHfgg== X-Received: by 10.237.62.4 with SMTP id l4mr3607332qtf.331.1515014452647; Wed, 03 Jan 2018 13:20:52 -0800 (PST) Received: from [172.19.38.30] ([2001:4878:a000:3000:d538:5277:5453:7b58]) by smtp.gmail.com with ESMTPSA id c50sm1144986qtk.45.2018.01.03.13.20.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jan 2018 13:20:51 -0800 (PST) From: "Aaron Falk" To: tsv-ads Cc: "taps WG" , taps-chairs@ietf.org Date: Wed, 03 Jan 2018 16:20:57 -0500 X-Mailer: MailMate (1.10r5443) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_C943EA98-2432-4F72-ABC2-6E1CB68B1AE4_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] proposed TAPS charter revision 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, 03 Jan 2018 21:20:56 -0000 --=_MailMate_C943EA98-2432-4F72-ABC2-6E1CB68B1AE4_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Dear TSV ADs, The TAPS working group would like to request the following change to the [charter](https://datatracker.ietf.org/wg/taps/about/) to permit analysis of the properties of security protocols with respect to the requirements of TAPS systems. This change will not add any creation or customization of security protocols. This change was [discussed and supported on the wg list](https://mailarchive.ietf.org/arch/msg/taps/359ewr6nWfHBr38WMRuK_Vq0dYk). —aaron **Proposal:** 1. Strike the last paragraph of the charter ("TAPS is not chartered to perform detailed analysis..."). 2. Change the third bullet right above it to read "Extension, modification, or creation of transport or security protocols" --=_MailMate_C943EA98-2432-4F72-ABC2-6E1CB68B1AE4_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Dear TSV ADs,

The TAPS working group would like to request the followin= g change to the charter to permit analysis of the properties o= f security protocols with respect to the requirements of TAPS systems. T= his change will not add any creation or customization of security protoco= ls.

This change was discuss= ed and supported on the wg list.

=E2=80=94aaron

Proposal:

  1. Strike the last paragraph of the charter = ("TAPS is not chartered to perform detailed analysis...").

  2. Change the third bullet right above it to= read "Extension, modification, or creation of transport or security prot= ocols"

--=_MailMate_C943EA98-2432-4F72-ABC2-6E1CB68B1AE4_=-- From nobody Wed Jan 3 13:35: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 B6CCB128C0A for ; Wed, 3 Jan 2018 13:35:28 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 KufPZqYDoEcf for ; Wed, 3 Jan 2018 13:35:26 -0800 (PST) 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 37B44120726 for ; Wed, 3 Jan 2018 13:35:26 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id i40so3820941qti.8 for ; Wed, 03 Jan 2018 13:35:26 -0800 (PST) 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=laI30KDzU2UGEYIOPkxx1V6GeRDD0wSSsVnUK62qIFg=; b=dDlq/HFpL7g6juqBMHbQoKfExnSEVPI0MLloSEert/0Vi+XxTtCi465ey8JM00fOeP bTeZrZyiiTtLgrTCVa/LpJ+c+dYLitjVtkmq5Gg+MIVdRvJK2zh5EBdogO9/rn3DkpUd zdAVZmUN2sf0FP+LjtZyfPsFkrMbEraeFd7t4= 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=laI30KDzU2UGEYIOPkxx1V6GeRDD0wSSsVnUK62qIFg=; b=mFzmqJY4gXhk3KxAp2fCgGMlD/PAocfMTwxMt3XsuDXVR9de/Q21/gOf7VFyFNp2sV YEgE2WGPtaQ6ejscWv+KoZwiht2WmadiU8yCenIdVBob8LMbpBCItZBTjA/kBsqDujkG +YyrgjmsPaEmR3pfJ/JXnRCxqzzaeLG6ecteRMRIFUHEDNvZ4VqWkD+1jVDs6HNZCdnY lI4mckRErGuMBN8mg70a79iARS0JpcDQFU4oACv/0mpJ3o1KitwBuuuG66Dry5QAURkL ikINeQ+UAxK7l7RYDWAHCMAW/ZS8STKpneonMmTbPSGDQr+YSBjJBLwJlekYSY9a+GKv ak2A== X-Gm-Message-State: AKGB3mLP1zT7c3opaLEQQ/rlNn7lf8IGtZ6UzuDHvdcc2G6Uv+QkEgGF YL6aXe2SJUIJVnlhi8ThmjzD0LBa7MiFJA1PAWy9/Q== X-Google-Smtp-Source: ACJfBosXmDiMRBNjPJpUAyA7/TP2oAIPWdcnLKl3Q6o+jS5tWVicICrpkhxvLUzVH9CaxILYj+6Zyd9Bdx01Vju50cI= X-Received: by 10.237.34.51 with SMTP id n48mr3686320qtc.300.1515015325156; Wed, 03 Jan 2018 13:35:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.160.129 with HTTP; Wed, 3 Jan 2018 13:35:24 -0800 (PST) X-Originating-IP: [2001:4878:a000:3000:5af:c407:cbef:3d43] In-Reply-To: References: <05F414A1-A2B3-4EF6-A280-DC9DD421B3EC@ifi.uio.no> <406114AF-F4DC-4FB4-B75E-54922F78799A@trammell.ch> <1EDFF789-D5D2-4A52-ABF6-5D6D1B1E61C3@apple.com> <52746EE2-1898-4879-8B33-C2AF17FC812D@gmail.com> <3F9EBCE7-EAC7-41CF-854F-00838A828280@apple.com> From: Kyle Rose Date: Wed, 3 Jan 2018 16:35:24 -0500 Message-ID: To: Aaron Falk Cc: Tommy Pauly , Robert Moskowitz , Brian Trammell , Michael Welzl , taps@ietf.org, Chris Wood Content-Type: multipart/alternative; boundary="001a113e7c384917350561e5fe6f" Archived-At: Subject: Re: [Taps] Charter change for security 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, 03 Jan 2018 21:35:28 -0000 --001a113e7c384917350561e5fe6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. FWIW, I am very familiar with the concept of an interrupt-driven WG chair, being one myself. :-) On Wed, Jan 3, 2018 at 4:15 PM, Aaron Falk wrote: > Thanks for the revision, Tommy. The status is =E2=80=98no progress=E2=80= =99 but > (surprise!) in response to your note I will do something now. :) > > =E2=80=94aaron > > On 3 Jan 2018, at 16:13, Tommy Pauly wrote: > > Hi Aaron, > > We=E2=80=99ve just posted an update to the Transport Security protocol su= rvey ( > https://tools.ietf.org/html/draft-pauly-taps-transport-security-01), and > noted that the charter for TAPS is still waiting for the update to the te= xt > as proposed by Kyle. > > Can you give an update on the status of this, and if we have the request > already sent to the ADs? > > Best, > Tommy > > On Jul 18, 2017, at 5:21 AM, Aaron Falk wrote: > > This is fine with me. Brief pause for any objections before making the > charter change request to the ADs=E2=80=A6 > > =E2=80=94aaron > > > On 18 Jul 2017, at 13:40, Robert Moskowitz wrote: > > I just joined this list. > > I can work with this. > > Bob > > On 07/18/2017 01:36 PM, Tommy Pauly wrote: > > Agreed. Thanks for the text proposal, Kyle! > > Tommy > > On Jul 18, 2017, at 12:15 PM, Brian Trammell (IETF) > wrote: > > +1. > > Cheers, > > Brian > > On 18 Jul 2017, at 12:02, Michael Welzl wrote: > > Agree 100% - I think this proposal is exactly the right way to do it. > > Cheers, > Michael > > > On Jul 18, 2017, at 11:12 AM, Kyle Rose wrote: > > Proposal: > > (1) Strike the last paragraph of the charter ("TAPS is not chartered to > perform detailed analysis..."). > > (2) Change the third bullet right above it to read "Extension, > modification, or creation of transport or security protocols" > > The idea being to permit analysis of the properties of security protocols > with respect to the requirements of TAPS systems, but not to permit > creation or customization of security protocols. > > Thoughts? > > Kyle > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > --001a113e7c384917350561e5fe6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks.

FWIW, I am very familiar with the concept o= f an interrupt-driven WG chair, being one myself. :-)


On Wed, Jan 3, 2018 at 4:= 15 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

Thanks for the revision, Tommy. The status is =E2=80=98no pro= gress=E2=80=99 but (surprise!) in response to your note I will do something= now. :)

=E2=80=94aaron

On 3 Jan 2018, at 16:13, Tommy Pauly wrote:

Hi Aaron,

We=E2=80=99ve just posted an update to the T= ransport Security protocol survey (https://tools.ietf= .org/html/draft-pauly-taps-transport-security-01), and noted = that the charter for TAPS is still waiting for the update to the text as pr= oposed by Kyle.

Can you give an update on the stat= us of this, and if we have the request already sent to the ADs?
<= br>
Best,
Tommy

On Jul 18, 2017, at 5:21 AM, Aaron Falk <aaron.falk@gmail.com> wrote:
Th= is is fine with me.=C2=A0 Brief pause for any objections before making the = charter change request to the ADs=E2=80=A6

=E2=80=94aaron

On 18 Jul 2017, at 13:40, Robert Moskowitz wrote:

I just joined this list.

I can work with this.

Bob<= br>
On 07/18/2017 01:36 PM, Tommy Pauly wrote:
Agreed. Thanks for the text proposal, Kyle!

Tommy

On Jul 18, 2017, at 12:15 PM, Brian Trammell (IETF) <= ietf@trammell.ch&= gt; wrote:

+1.

Cheers,

Brian

On 18 Jul 2017, at 12:02, Michael Welzl <michawe@ifi.uio.no> wrote:
Agree 100% - I think this proposal is exactly the right way to do it.
<= br>Cheers,
Michael


On Jul 18, 2017,= at 11:12 AM, Kyle Rose <Krose@krose.org> wrote:

Proposal:

(1) Strike the= last paragraph of the charter ("TAPS is not chartered to perform deta= iled analysis...").

(2) Change the third bullet right above it = to read "Extension, modification, or creation of transport or security= protocols"

The idea being to permit analysis of the properties= of security protocols with respect to the requirements of TAPS systems, bu= t not to permit creation or customization of security protocols.

Tho= ughts?

Kyle
_______________________________________________<= br>Taps mailing list
= Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
<= /blockquote>_______________________________________________
Taps ma= iling list
Taps@ietf.= org
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list=
Taps@ietf.orgh= ttps://www.ietf.org/mailman/listinfo/taps
________= _______________________________________
Taps mailing list
Taps@ietf.org
https://w= ww.ietf.org/mailman/listinfo/taps

____________= ___________________________________
Taps mailing list
Taps@ietf.org
https://www.iet= f.org/mailman/listinfo/taps

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

=

--001a113e7c384917350561e5fe6f-- From nobody Wed Jan 10 09:11: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 9211B12DA24 for ; Wed, 10 Jan 2018 09:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_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 bsjnonbROI7d for ; Wed, 10 Jan 2018 09:11:48 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BFD12D875 for ; Wed, 10 Jan 2018 09:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1515604308; 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=n31jI9flPbvpeM4lVnNJyUvp2ttHGV0BAxpEzo/X7jQ=; b=EPQLN5wg7TFfJNHpIkkTOUBhLvIONOHMK9AeNkvBAm2Lo50lVUsOWBtWc7WkK2zU sOUEITK4OpT2Ktf9UEQ9qiGFWc2igwO2oIhYWVjLRseA8DNSrT5K1xPTWWI3y8R6 6637GcvnrhgEfPW2vqW+PBmM3itrwbDyUerglGL5AF30c4vb7l9ygVONs/YNbYVY vWIIz6jvXZhZAEkZxFm9A5XIPssJiU1l5BKa/FwvVlqMc04mKsuxAtf4HoiAEMPK QdmHNd2VpKhDLSRSUBv3y/LL4Mab+SGld+7sge2KkOGpVblIikalxSSAFyadNy6a iFA+vx59wTDYXutKKqQc+w==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id B5.B1.16042.459465A5; Wed, 10 Jan 2018 09:11:48 -0800 (PST) X-AuditID: 11973e12-801fd9c000003eaa-ea-5a564954a4a6 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay3.apple.com (Apple SCV relay) with SMTP id 86.FC.12852.359465A5; Wed, 10 Jan 2018 09:11:48 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_fmjFdq7W+xOzElL0nnZNaw)" Received: from [17.234.98.96] (unknown [17.234.98.96]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.1.20171204 64bit (built Dec 4 2017)) with ESMTPSA id <0P2C00600NRN3070@nwk-mmpp-sz13.apple.com> for taps@ietf.org; Wed, 10 Jan 2018 09:11:47 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <19E34FCD-7BD6-41DB-8830-C376CF6B0623@apple.com> Date: Wed, 10 Jan 2018 09:11:46 -0800 To: taps@ietf.org X-Mailer: Apple Mail (2.3458) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FAYrBviGRZl8Osvs8WdGAdGjyVLfjIF MEZx2aSk5mSWpRbp2yVwZSx/vpK5oHcCY8WSQ9eZGxhv1XQxcnBICJhIfOiQ7GLk4hASWM0k ceb/RrYuRk6weN+n3awQiUOMEidPNbKDJHgFBCV+TL7HAmIzC4RJ3N/5hRmiaCGTxOw7e9hA pgoLSEhs3pMIUsMmoCJx/NsGZhBbWEBL4vPXN0wQc2wktr6fC2azCKhK3Lg1E2y+CND8rSe7 WSGOkJVYOfsu2BESAndZJaZuv8s4gZF/FpI7ZiG5YxbQamYBdYkpU3IhwtoST95dYIWw1SQW /l7EhCy+gJFtFaNQbmJmjm5mnoleYkFBTqpecn7uJkZQqE63E9rBeGqV1SFGAQ5GJR7eDeJh UUKsiWXFlbmHGKU5WJTEefd98Y8SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMiVm3NxumvF 0ovrir1MKnN/Bq/c2M1wylXgi6Q1g9oMiS8a6qu2lFs270l0s809u2XnfZ6ueV393OsVD3Fw 5zvIb9wckZCtvnylRoyS1+aItWwZQjGPp/AGRqTFyt+ZnBEVe6F7OePGoIa7PNXKn84u6Psz t/0g22vW7xNu+2yvTE6KWqi1U4mlOCPRUIu5qDgRAGg9Vyk2AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUi2FB8QzfEMyzK4KqexZ0YB0aPJUt+MgUw RnHZpKTmZJalFunbJXBlLH++krmgdwJjxZJD15kbGG/VdDFyckgImEj0fdrN2sXIxSEkcIhR 4uSpRnaQBK+AoMSPyfdYQGxmgTCJ+zu/MEMULWSSmH1nD1sXIweHsICExOY9iSA1bAIqEse/ bWAGsYUFtCQ+f33DBDHHRmLr+7lgNouAqsSNWzPB5osAzd96spsV4ghZiZWz77JOYOSZhWT1 LCSrZwFtYxZQl5gyJRcirC3x5N0FVghbTWLh70VMyOILGNlWMQoUpeYkVhrrJRYU5KTqJefn bmIEh1Zh8A7GP8usDjEKcDAq8fBGiIZFCbEmlhVX5gL9z8GsJMLrZA4U4k1JrKxKLcqPLyrN SS0+xCjNwaIkznvIDiglkJ5YkpqdmlqQWgSTZeLglGpgbF944Oe7beVXrZ6E3pq8qfriBK2L zvtmz0hxfs51941uHof97vVlqtyHec+2+jPv1emcGq6ZYXblrLzbj5RaDWGvfwyrVu7rEr98 1FF7hcHWZ8c2c9owbS1y536z5YFa11+GiUwl28Q/S94KDat1bjjoc/qcPmN6bTbr1T5VU0me Vf9+Vei5K7EUZyQaajEXFScCALbOedQpAgAA Archived-At: Subject: [Taps] TAPS Documents for Charter Item 3 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, 10 Jan 2018 17:11:51 -0000 --Boundary_(ID_fmjFdq7W+xOzElL0nnZNaw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hello TAPS, In Singapore, there was much discussion about where we go after the = minset drafts, and what documents will form charter item 3: 3) Specify experimental support mechanisms to provide the Transport=20 Services identified in work item 2. This document will explain=20 how to select and engage an appropriate protocol and how to=20 discover which protocols are available for the selected service=20 between a given pair of end points. Further, it will provide a=20 basis for incremental deployment. Work on this document will=20 begin when the TAPS Transport Services have been specified. Since it would be good to get convergence and adoption of documents in = London, I=E2=80=99d like to take a stab at how we can structure the WG = documents and start a discussion on this list to decide our collective = approach. At a high level, based on the work of NEAT, Post Sockets, Happy = Eyeballs, Socket Intents, etc, it seems like the =E2=80=9Csupport = mechanisms=E2=80=9D for TAPS are converging into categories (a) how to = expose functionality in an Abstract API and (b) guidance on how to = implement a library that provides TAPS functionality. These two = categories are not unrelated, but have different audiences; Abstract = APIs are aimed at adopters of a TAPS system, while the implementation = guidance aspects are aimed at library and system implementers. The = high-level concepts that bind these together form the overall TAPS = architecture. Looking at things in this way, I could imagine three documents, which = would form the capstone of the TAPS work 1) TAPS Architecture: high level explanation of the approach and goals, = how the API and implementations relate, and how the system is derived = from the protocol surveys and minset. Defines consistent terminology for = concepts used in the other documents. 2) TAPS API: document aimed at adopters taking advantage of a TAPS = system: configuration, initiation of channels, listening/responding, = data transfer, and maintenance. 3) TAPS Implementation Guide: document aimed at implementers on how to = bring up connections (handling a multiplicity of paths, endpoints, and = protocols), sending and receiving data through protocol stack instances, = and interpreting configuration and system policy into decisions. I believe that many (or all) of the outstanding documents we have in the = WG already fall into one or more of the categories. Here=E2=80=99s a = table with the three proposed documents as 1, 2, 3, and three aspects of = a TAPS system/architecture as A, B, C: A B C 1. TAPS Architecture Connection Establishment Data transfer Policy and Path Selection 2. TAPS API Initiator/Listener/Responder Send/Receive Intents and configuration 3. TAPS Implementation Guide Protocol Racing, Path Racing, Happy Eyeballs Protocol Stack Instance Policy engine In this table, we could see the existing documents contributing aspects = to certain blocks: draft-fairhurst-taps-neat: 1A, 1B, 1C, 2A, 2B, 2C, 3C draft-trammell-taps-post-sockets: 1A, 1B, 1C, 2A, 2B, (2C), (3B) draft-pauly-taps-guidelines: 3A, (1C) draft-grinnemo-taps-he: 3A draft-tiesel-taps-socketintents: 2C This is a rough assignment and not necessarily exhaustive, but the point = is that much of the content is probably already there is some form, and = can be reinterpreted into these documents. What do people think about this approach? Any aspects that are missed = here that would need to be separate documents, or new sections across = the documents? Thanks, Tommy= --Boundary_(ID_fmjFdq7W+xOzElL0nnZNaw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hello= TAPS,

In Singapore, = there was much discussion about where we go after the minset drafts, and = what documents will form charter item 3:

3) Specify experimental support = mechanisms to provide the Transport 
Services = identified in work item 2. This document will explain 
how to select and engage an appropriate protocol and how = to 
discover which protocols are available for the = selected service 
between a given pair of end points. = Further, it will provide a 
basis for incremental = deployment. Work on this document will 
begin when = the TAPS Transport Services have been specified.

Since it would be good to get = convergence and adoption of documents in London, I=E2=80=99d like to = take a stab at how we can structure the WG documents and start a = discussion on this list to decide our collective approach.

At a high level, based = on the work of NEAT, Post Sockets, Happy Eyeballs, Socket Intents, etc, = it seems like the =E2=80=9Csupport mechanisms=E2=80=9D for TAPS are = converging into categories (a) how to expose functionality in an = Abstract API and (b) guidance on how to implement a library that = provides TAPS functionality. These two categories are not unrelated, but = have different audiences; Abstract APIs are aimed at adopters of a TAPS = system, while the implementation guidance aspects are aimed at library = and system implementers. The high-level concepts that bind these = together form the overall TAPS architecture.

Looking at things in this way, I could = imagine three documents, which would form the capstone of the TAPS = work
1) TAPS Architecture: high level explanation = of the approach and goals, how the API and implementations relate, and = how the system is derived from the protocol surveys and minset. Defines = consistent terminology for concepts used in the other = documents.
2) TAPS API: document aimed at adopters = taking advantage of a TAPS system: configuration, initiation of = channels, listening/responding, data transfer, and = maintenance.
3) TAPS Implementation Guide: document = aimed at implementers on how to bring up connections (handling a = multiplicity of paths, endpoints, and protocols), sending and receiving = data through protocol stack instances, and interpreting configuration = and system policy into decisions.

I believe that many (or all) of the = outstanding documents we have in the WG already fall into one or more of = the categories. Here=E2=80=99s a table with the three proposed documents = as 1, 2, 3, and three aspects of a TAPS system/architecture as A, B, = C:
A
B
C
1. TAPS = Architecture
Connection Establishment
Data transfer
Policy and Path Selection
2. TAPS = API
Initiator/Listener/Responder
Send/Receive
Intents and configuration
3. TAPS Implementation = Guide
Protocol Racing, Path Racing, Happy Eyeballs
Protocol Stack Instance
Policy engine

In this table, we could see = the existing documents contributing aspects to certain blocks:

draft-fairhurst-taps-neat:= 1A, 1B, 1C, 2A, 2B, 2C, 3C
draft-trammell-taps-post-sockets: 1A, 1B, 1C, 2A, 2B, (2C), = (3B)
draft-pauly-taps-guidelines: 3A, = (1C)
draft-grinnemo-taps-he: 3A
draft-tiesel-taps-socketintents: 2C

This is a rough assignment and not = necessarily exhaustive, but the point is that much of the content is = probably already there is some form, and can be reinterpreted into these = documents.

What = do people think about this approach? Any aspects that are missed here = that would need to be separate documents, or new sections across the = documents?

Thanks,
Tommy
= --Boundary_(ID_fmjFdq7W+xOzElL0nnZNaw)-- From nobody Thu Jan 11 00:23:33 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9953C12EAAC for ; Thu, 11 Jan 2018 00:23:31 -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 tRVZawQs9OX0 for ; Thu, 11 Jan 2018 00:23:29 -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 CB14A12EA9F for ; Thu, 11 Jan 2018 00:23:28 -0800 (PST) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eZY8z-0005Pt-LS; Thu, 11 Jan 2018 09:23:25 +0100 Received: from [160.80.82.29] by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eZY8y-0006SQ-I4; Thu, 11 Jan 2018 09:23:25 +0100 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7AB5314B-282E-48C4-934F-BD9E0611B736" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 11 Jan 2018 09:23:24 +0100 In-Reply-To: <19E34FCD-7BD6-41DB-8830-C376CF6B0623@apple.com> Cc: "taps@ietf.org" To: Tommy Pauly References: <19E34FCD-7BD6-41DB-8830-C376CF6B0623@apple.com> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 160.80.82.29 is neither permitted nor denied by domain of ifi.uio.no) client-ip=160.80.82.29; envelope-from=michawe@ifi.uio.no; helo=[160.80.82.29]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.044, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F4EBC391DFF2B36CF22D78CB392AD637E1178F15 Archived-At: Subject: Re: [Taps] TAPS Documents for Charter Item 3 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, 11 Jan 2018 08:23:31 -0000 --Apple-Mail=_7AB5314B-282E-48C4-934F-BD9E0611B736 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tommy, A few answers below: > On Jan 10, 2018, at 6:11 PM, Tommy Pauly wrote: >=20 > Hello TAPS, >=20 > In Singapore, there was much discussion about where we go after the = minset drafts, and what documents will form charter item 3: >=20 > 3) Specify experimental support mechanisms to provide the Transport=20 > Services identified in work item 2. This document will explain=20 > how to select and engage an appropriate protocol and how to=20 > discover which protocols are available for the selected service=20 > between a given pair of end points. Further, it will provide a=20 > basis for incremental deployment. Work on this document will=20 > begin when the TAPS Transport Services have been specified. >=20 > Since it would be good to get convergence and adoption of documents in = London, I=E2=80=99d like to take a stab at how we can structure the WG = documents and start a discussion on this list to decide our collective = approach. >=20 > At a high level, based on the work of NEAT, Post Sockets, Happy = Eyeballs, Socket Intents, etc, it seems like the =E2=80=9Csupport = mechanisms=E2=80=9D for TAPS are converging into categories (a) how to = expose functionality in an Abstract API and (b) guidance on how to = implement a library that provides TAPS functionality. These two = categories are not unrelated, but have different audiences; Abstract = APIs are aimed at adopters of a TAPS system, while the implementation = guidance aspects are aimed at library and system implementers. The = high-level concepts that bind these together form the overall TAPS = architecture. >=20 > Looking at things in this way, I could imagine three documents, which = would form the capstone of the TAPS work > 1) TAPS Architecture: high level explanation of the approach and = goals, how the API and implementations relate, and how the system is = derived from the protocol surveys and minset. Defines consistent = terminology for concepts used in the other documents. > 2) TAPS API: document aimed at adopters taking advantage of a TAPS = system: configuration, initiation of channels, listening/responding, = data transfer, and maintenance. > 3) TAPS Implementation Guide: document aimed at implementers on how to = bring up connections (handling a multiplicity of paths, endpoints, and = protocols), sending and receiving data through protocol stack instances, = and interpreting configuration and system policy into decisions. Funny, I have also been thinking about item 3 in exactly this way for a = long time =E2=80=A6 and I believe we two are not the only ones. This split really seems quite natural. > I believe that many (or all) of the outstanding documents we have in = the WG already fall into one or more of the categories. Here=E2=80=99s a = table with the three proposed documents as 1, 2, 3, and three aspects of = a TAPS system/architecture as A, B, C: >=20 >=20 > A > B > C > 1. TAPS Architecture > Connection Establishment > Data transfer > Policy and Path Selection > 2. TAPS API > Initiator/Listener/Responder > Send/Receive > Intents and configuration > 3. TAPS Implementation Guide > Protocol Racing, Path Racing, Happy Eyeballs > Protocol Stack Instance > Policy engine >=20 > In this table, we could see the existing documents contributing = aspects to certain blocks: >=20 > draft-fairhurst-taps-neat: 1A, 1B, 1C, 2A, 2B, 2C, 3C > draft-trammell-taps-post-sockets: 1A, 1B, 1C, 2A, 2B, (2C), (3B) > draft-pauly-taps-guidelines: 3A, (1C) > draft-grinnemo-taps-he: 3A > draft-tiesel-taps-socketintents: 2C I agree with this rough assessment. This table is good to think about! I think draft-tiesel-taps-communitgrany is missing for 1) (not sure if = it=E2=80=99s A / B / C, but it=E2=80=99s about terminology) > This is a rough assignment and not necessarily exhaustive, but the = point is that much of the content is probably already there is some = form, and can be reinterpreted into these documents. >=20 > What do people think about this approach? Any aspects that are missed = here that would need to be separate documents, or new sections across = the documents? Personally I like the approach but I=E2=80=99d caution that we need a = tight connection between the lines in the table. For everything we do, = we must make sure it=E2=80=99s implementable, and explain how. Hence, a = document describing API primitives should also clarify how these = primitives could be implemented - with the split you describe above, by = pointing at a specific section for each functionality in a "line 3=E2=80=9D= document (if these things really are going to be separate documents?). Cheers, Michael --Apple-Mail=_7AB5314B-282E-48C4-934F-BD9E0611B736 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Tommy,

A= few answers below:

On Jan 10, 2018, at 6:11 PM, = Tommy Pauly <tpauly@apple.com> wrote:

Hello TAPS,

In Singapore, there was = much discussion about where we go after the minset drafts, and what = documents will form charter item 3:

3) Specify experimental support = mechanisms to provide the Transport 
Services = identified in work item 2. This document will explain 
how to select and engage an appropriate protocol and how = to 
discover which protocols are available for the = selected service 
between a given pair of end points. = Further, it will provide a 
basis for incremental = deployment. Work on this document will 
begin when = the TAPS Transport Services have been specified.

Since it would be good to get = convergence and adoption of documents in London, I=E2=80=99d like to = take a stab at how we can structure the WG documents and start a = discussion on this list to decide our collective approach.

At a high level, based = on the work of NEAT, Post Sockets, Happy Eyeballs, Socket Intents, etc, = it seems like the =E2=80=9Csupport mechanisms=E2=80=9D for TAPS are = converging into categories (a) how to expose functionality in an = Abstract API and (b) guidance on how to implement a library that = provides TAPS functionality. These two categories are not unrelated, but = have different audiences; Abstract APIs are aimed at adopters of a TAPS = system, while the implementation guidance aspects are aimed at library = and system implementers. The high-level concepts that bind these = together form the overall TAPS architecture.

Looking at things in this way, I could = imagine three documents, which would form the capstone of the TAPS = work
1) TAPS Architecture: high level explanation = of the approach and goals, how the API and implementations relate, and = how the system is derived from the protocol surveys and minset. Defines = consistent terminology for concepts used in the other = documents.
2) TAPS API: document aimed at adopters = taking advantage of a TAPS system: configuration, initiation of = channels, listening/responding, data transfer, and = maintenance.
3) TAPS Implementation Guide: document = aimed at implementers on how to bring up connections (handling a = multiplicity of paths, endpoints, and protocols), sending and receiving = data through protocol stack instances, and interpreting configuration = and system policy into decisions.

Funny, I have also been thinking about item 3 in = exactly this way for a long time =E2=80=A6 and I believe we two are not = the only ones.
This split really seems quite = natural.


I believe that many (or all) of the = outstanding documents we have in the WG already fall into one or more of = the categories. Here=E2=80=99s a table with the three proposed documents = as 1, 2, 3, and three aspects of a TAPS system/architecture as A, B, = C:
A
B
C
1. TAPS Architecture
Connection = Establishment
Data = transfer
Policy and = Path Selection
2. TAPS API
Initiator/Listener/Responder
Send/Receive
Intents and = configuration
3. TAPS Implementation Guide
Protocol = Racing, Path Racing, Happy Eyeballs
Protocol = Stack Instance
Policy = engine

In this table, we could see = the existing documents contributing aspects to certain blocks:

draft-fairhurst-taps-neat:= 1A, 1B, 1C, 2A, 2B, 2C, 3C
draft-trammell-taps-post-sockets: 1A, 1B, 1C, 2A, 2B, (2C), = (3B)
draft-pauly-taps-guidelines: 3A, = (1C)
draft-grinnemo-taps-he: 3A
draft-tiesel-taps-socketintents: = 2C

I agree = with this rough assessment. This table is good to think = about!
I think draft-tiesel-taps-communitgrany is missing = for 1)  (not sure if it=E2=80=99s A / B / C, but it=E2=80=99s about = terminology)


This is a rough = assignment and not necessarily exhaustive, but the point is that much of = the content is probably already there is some form, and can be = reinterpreted into these documents.

What do people think about this = approach? Any aspects that are missed here that would need to be = separate documents, or new sections across the = documents?

Personally I like the approach but I=E2=80=99d = caution that we need a tight connection between the lines in the table. = For everything we do, we must make sure it=E2=80=99s implementable, and = explain how. Hence, a document describing API primitives should also = clarify how these primitives could be implemented - with the split you = describe above, by pointing at a specific section for each functionality = in a "line 3=E2=80=9D document (if these things really are going to be = separate documents?).

Cheers,
Michael

= --Apple-Mail=_7AB5314B-282E-48C4-934F-BD9E0611B736-- From nobody Thu Jan 11 07:28: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 08DED12EB86 for ; Thu, 11 Jan 2018 07:28:16 -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 nKmUiWQoLa_v for ; Thu, 11 Jan 2018 07:28:13 -0800 (PST) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CDC1204DA for ; Thu, 11 Jan 2018 07:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1515684492; x=2379598092; 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=/SbbtwkWWjhP23w8GhIc5YkpCUbprvyd/XhU1hESnvA=; b=Kl8ktZYZxtHr70F4ZKxle1+ihskVbtZXqasGgIvCWp/kmdDeubIwFQKmwNMWJDRc 38cwleAYprcft4i9VwA5Q9BHPtX2kH6gGAXUIxbYo6Dk1tx4M/CnUT7biuMlN+j3 XtRfe9h0zsOTA5YF4X98rhmSNECk3DnULPD/qz9WMRSNbum0WuSP3ZA3FJi1YPfR Vjv8/LXhmpG2d6fK8wBGXB+UVnxjsJLMFL67l8SDz81GX+eDa8jE9kVotfuvmORe okdfpHDQiydsddXDnlYG/TVHFjr+w8dvbFVdLWEtQrfE7md8P26lhkkBzjsfRap6 /L7gwRwYZLOxZGuK0nN3Ww==; 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-in23.apple.com (Apple Secure Mail Relay) with SMTP id 4D.C7.05970.C82875A5; Thu, 11 Jan 2018 07:28:12 -0800 (PST) X-AuditID: 11ab0217-f00cb9e000001752-75-5a57828c78f3 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay5.apple.com (Apple SCV relay) with SMTP id F4.9C.18983.B82875A5; Thu, 11 Jan 2018 07:28:11 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_14qtWJj9G+cYPyWPsruDZQ)" Received: from [17.234.112.39] (unknown [17.234.112.39]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.1.20171204 64bit (built Dec 4 2017)) with ESMTPSA id <0P2E00C06DMZVT60@nwk-mmpp-sz11.apple.com>; Thu, 11 Jan 2018 07:28:11 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Thu, 11 Jan 2018 07:28:10 -0800 In-reply-to: Cc: "taps@ietf.org" To: Michael Welzl References: <19E34FCD-7BD6-41DB-8830-C376CF6B0623@apple.com> X-Mailer: Apple Mail (2.3458) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYodvTFB5l8KFB3OLH2Z2sFndiHJg8 liz5yeSxevVD5gCmKC6blNSczLLUIn27BK6MA22rGQv+PWGs6J8wjb2B8fVRxi5GTg4JAROJ 3dOfMXcxcnEICaxhkrjTM4MNJrFp2wNGiMQhRoktC/6zgCR4BQQlfky+B2YzC4RJHL2/hwWi aCKTxNTWlUAdHBzCAhISm/ckgtSwCahIHP+2gRmi10bizYJJTBAlphLXFlqDhFkEVCX27T/C CmJzCthJzLr5ixFivLLE41mNYKtEBNQkTixfzQbSKiRQIDHjnhXEmbISK2ffZQW5QEJgCptE +4E7zBMYhWYhuXQWkktnAbUzC6hLTJmSCxHWlnjy7gIrhK0msfD3IiZk8QWMbKsYhXMTM3N0 M/OMjPUSCwpyUvWS83M3MYIiYTWT+A7Gz68NDzEKcDAq8fA+yA2PEmJNLCuuzD3EKM3BoiTO mxxtEyUkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUTO2avucDH6Za3sNDZimxEqqz2aLmvhG Z5vlw+VyEYvtL/3X69087bjJWvOoaSH35YwfXpqsG3S86YTKV83sDY9f+3w8dMVjS+iim6FP JhV8n+S0bP8x2WmHd6Zo/P6xzMt/36fli2Xn3puxzsSrLHFdjNtSB6E/7y8xJ223E/5QaVJ9 vPbmrFNKLMUZiYZazEXFiQCbEn9AZQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUi2FA8W7e7KTzK4NdrK4sfZ3eyWtyJcWDy WLLkJ5PH6tUPmQOYorhsUlJzMstSi/TtErgyDrStZiz494Sxon/CNPYGxtdHGbsYOTkkBEwk Nm17AGRzcQgJHGKU2LLgPwtIgldAUOLH5HtgNrNAmMTR+3tYIIomMklMbV0J1MHBISwgIbF5 TyJIDZuAisTxbxuYIXptJN4smMQEUWIqcW2hNUiYRUBVYt/+I6wgNqeAncSsm78YIcYrSzye 1Qi2SkRATeLE8tVsIK1CAgUSM+5ZQZwpK7Fy9l3WCYz8s5AcNwvJcbOAOpgF1CWmTMmFCGtL PHl3gRXCVpNY+HsRE7L4Aka2VYwCRak5iZWmeokFBTmpesn5uZsYwWFbGLGD8f8yq0OMAhyM Sjy8FgXhUUKsiWXFlbnAEOJgVhLhXRwYFiXEm5JYWZValB9fVJqTWnyIUZqDRUmcd8YqoJRA emJJanZqakFqEUyWiYNTqoFRXvPsTcOOFAanCVHnvk16VhTjelv799VlxlEZnsH8qjvcPc9w Xes40LKtteWQndWiSxI7Hz4/+Eg1WiD536eZ1bffH34ecne2qovMT8H7QUm34g8o/DryjYk5 4NI0oaUdv/OlrmTWXj96YPmOX5UPfiWL8GRP2/JK2E6uV9buO7fQ2ez71noLlFiKMxINtZiL ihMBW0pxYVcCAAA= Archived-At: Subject: Re: [Taps] TAPS Documents for Charter Item 3 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, 11 Jan 2018 15:28:16 -0000 --Boundary_(ID_14qtWJj9G+cYPyWPsruDZQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Jan 11, 2018, at 12:23 AM, Michael Welzl = wrote: >=20 > Hi Tommy, >=20 > A few answers below: >=20 >> On Jan 10, 2018, at 6:11 PM, Tommy Pauly > wrote: >>=20 >> Hello TAPS, >>=20 >> In Singapore, there was much discussion about where we go after the = minset drafts, and what documents will form charter item 3: >>=20 >> 3) Specify experimental support mechanisms to provide the Transport=20= >> Services identified in work item 2. This document will explain=20 >> how to select and engage an appropriate protocol and how to=20 >> discover which protocols are available for the selected service=20 >> between a given pair of end points. Further, it will provide a=20 >> basis for incremental deployment. Work on this document will=20 >> begin when the TAPS Transport Services have been specified. >>=20 >> Since it would be good to get convergence and adoption of documents = in London, I=E2=80=99d like to take a stab at how we can structure the = WG documents and start a discussion on this list to decide our = collective approach. >>=20 >> At a high level, based on the work of NEAT, Post Sockets, Happy = Eyeballs, Socket Intents, etc, it seems like the =E2=80=9Csupport = mechanisms=E2=80=9D for TAPS are converging into categories (a) how to = expose functionality in an Abstract API and (b) guidance on how to = implement a library that provides TAPS functionality. These two = categories are not unrelated, but have different audiences; Abstract = APIs are aimed at adopters of a TAPS system, while the implementation = guidance aspects are aimed at library and system implementers. The = high-level concepts that bind these together form the overall TAPS = architecture. >>=20 >> Looking at things in this way, I could imagine three documents, which = would form the capstone of the TAPS work >> 1) TAPS Architecture: high level explanation of the approach and = goals, how the API and implementations relate, and how the system is = derived from the protocol surveys and minset. Defines consistent = terminology for concepts used in the other documents. >> 2) TAPS API: document aimed at adopters taking advantage of a TAPS = system: configuration, initiation of channels, listening/responding, = data transfer, and maintenance. >> 3) TAPS Implementation Guide: document aimed at implementers on how = to bring up connections (handling a multiplicity of paths, endpoints, = and protocols), sending and receiving data through protocol stack = instances, and interpreting configuration and system policy into = decisions. >=20 > Funny, I have also been thinking about item 3 in exactly this way for = a long time =E2=80=A6 and I believe we two are not the only ones. > This split really seems quite natural. >=20 Good to hear that the split seems reasonable! >=20 >> I believe that many (or all) of the outstanding documents we have in = the WG already fall into one or more of the categories. Here=E2=80=99s a = table with the three proposed documents as 1, 2, 3, and three aspects of = a TAPS system/architecture as A, B, C: >>=20 >>=20 >> A >> B >> C >> 1. TAPS Architecture >> Connection Establishment >> Data transfer >> Policy and Path Selection >> 2. TAPS API >> Initiator/Listener/Responder >> Send/Receive >> Intents and configuration >> 3. TAPS Implementation Guide >> Protocol Racing, Path Racing, Happy Eyeballs >> Protocol Stack Instance >> Policy engine >>=20 >> In this table, we could see the existing documents contributing = aspects to certain blocks: >>=20 >> draft-fairhurst-taps-neat: 1A, 1B, 1C, 2A, 2B, 2C, 3C >> draft-trammell-taps-post-sockets: 1A, 1B, 1C, 2A, 2B, (2C), (3B) >> draft-pauly-taps-guidelines: 3A, (1C) >> draft-grinnemo-taps-he: 3A >> draft-tiesel-taps-socketintents: 2C >=20 > I agree with this rough assessment. This table is good to think about! > I think draft-tiesel-taps-communitgrany is missing for 1) (not sure = if it=E2=80=99s A / B / C, but it=E2=80=99s about terminology) Yes, this wasn=E2=80=99t a complete list. Also note that I=E2=80=99m not = proposing that we adopt any of the documents as they are, but = specifically adopt WG items for Architecture, API, and Implementation, = and we build those documents from the existing ones, taking the best = parts of all of them. >=20 >=20 >> This is a rough assignment and not necessarily exhaustive, but the = point is that much of the content is probably already there is some = form, and can be reinterpreted into these documents. >>=20 >> What do people think about this approach? Any aspects that are missed = here that would need to be separate documents, or new sections across = the documents? >=20 > Personally I like the approach but I=E2=80=99d caution that we need a = tight connection between the lines in the table. For everything we do, = we must make sure it=E2=80=99s implementable, and explain how. Hence, a = document describing API primitives should also clarify how these = primitives could be implemented - with the split you describe above, by = pointing at a specific section for each functionality in a "line 3=E2=80=9D= document (if these things really are going to be separate documents?). That=E2=80=99s why I=E2=80=99d propose having three documents that are = adopted as a group, that are designed to go through the process = together, and heavily reference one another. The definition of what goes = in each should be based on the audience. One other comment I have for = the API is that it should likely remain agnostic to specific protocols: = it should say =E2=80=9Chere=E2=80=99s how to send/receive with these = kind of options, and protocols will treat them like this=E2=80=9D; but = the implementation document can go into details of how those map down to = specific protocol details in existing mappings (TCP, SCTP, UDP, QUIC). = My two goals in saying this are: 1) The API should be simple and easy to understand for an adopter=E2=80=99= s perspective 2) The API should be relevant despite changes in transport protocols de = jour. Maybe in fifty years no one is using TCP anymore; we=E2=80=99ll = publish implementation and mapping updates, but the API document should = still be unchanged. Thanks, Tommy >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps = --Boundary_(ID_14qtWJj9G+cYPyWPsruDZQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On Jan 11, 2018, at 12:23 AM, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi Tommy,

A few answers below:

On Jan 10, 2018, at 6:11 PM, Tommy Pauly <tpauly@apple.com> = wrote:

Hello TAPS,

In Singapore, there was much discussion = about where we go after the minset drafts, and what documents will form = charter item 3:

3) Specify experimental support mechanisms to provide the = Transport 
Services identified in work item 2. This = document will explain 
how to select and engage an = appropriate protocol and how to 
discover which = protocols are available for the selected service 
between a given pair of end points. Further, it will provide = a 
basis for incremental deployment. Work on this = document will 
begin when the TAPS Transport Services = have been specified.

Since it would be good to get convergence and adoption of = documents in London, I=E2=80=99d like to take a stab at how we can = structure the WG documents and start a discussion on this list to decide = our collective approach.

At a high level, based on the work of NEAT, Post Sockets, = Happy Eyeballs, Socket Intents, etc, it seems like the =E2=80=9Csupport = mechanisms=E2=80=9D for TAPS are converging into categories (a) how to = expose functionality in an Abstract API and (b) guidance on how to = implement a library that provides TAPS functionality. These two = categories are not unrelated, but have different audiences; Abstract = APIs are aimed at adopters of a TAPS system, while the implementation = guidance aspects are aimed at library and system implementers. The = high-level concepts that bind these together form the overall TAPS = architecture.

Looking at things in this way, I could imagine three = documents, which would form the capstone of the TAPS work
1) TAPS Architecture: high level explanation of the approach = and goals, how the API and implementations relate, and how the system is = derived from the protocol surveys and minset. Defines consistent = terminology for concepts used in the other documents.
2) TAPS API: document aimed at adopters taking advantage of a = TAPS system: configuration, initiation of channels, = listening/responding, data transfer, and maintenance.
3) TAPS Implementation Guide: document aimed at implementers = on how to bring up connections (handling a multiplicity of paths, = endpoints, and protocols), sending and receiving data through protocol = stack instances, and interpreting configuration and system policy into = decisions.

Funny, I have also been thinking about = item 3 in exactly this way for a long time =E2=80=A6 and I believe we = two are not the only ones.
This split really seems = quite natural.


Good to hear that the split seems = reasonable!


I believe that many (or all) of the = outstanding documents we have in the WG already fall into one or more of = the categories. Here=E2=80=99s a table with the three proposed documents = as 1, 2, 3, and three aspects of a TAPS system/architecture as A, B, = C:


A
B
C
1. TAPS Architecture
Connection Establishment
Data = transfer
Policy and Path Selection
2. TAPS API
Initiator/Listener/Responder
Send/Receive
Intents and configuration
3. TAPS Implementation Guide
Protocol Racing, Path Racing, Happy = Eyeballs
Protocol Stack Instance
Policy = engine

In this table, we could see the existing documents = contributing aspects to certain blocks:

draft-fairhurst-taps-neat: 1A, 1B, 1C, = 2A, 2B, 2C, 3C
draft-trammell-taps-post-sockets: = 1A, 1B, 1C, 2A, 2B, (2C), (3B)
draft-pauly-taps-guidelines: 3A, (1C)
draft-grinnemo-taps-he: 3A
draft-tiesel-taps-socketintents: = 2C

I agree with this rough assessment. This table is good to = think about!
I = think draft-tiesel-taps-communitgrany is missing for 1)  (not = sure if it=E2=80=99s A / B / C, but it=E2=80=99s about = terminology)

Yes, this wasn=E2=80=99t a complete list. Also note = that I=E2=80=99m not proposing that we adopt any of the documents as = they are, but specifically adopt WG items for Architecture, API, and = Implementation, and we build those documents from the existing ones, = taking the best parts of all of them.


This is a rough = assignment and not necessarily exhaustive, but the point is that much of = the content is probably already there is some form, and can be = reinterpreted into these documents.

What do people think about this = approach? Any aspects that are missed here that would need to be = separate documents, or new sections across the = documents?

Personally I like the approach but = I=E2=80=99d caution that we need a tight connection between the lines in = the table. For everything we do, we must make sure it=E2=80=99s = implementable, and explain how. Hence, a document describing API = primitives should also clarify how these primitives could be implemented = - with the split you describe above, by pointing at a specific section = for each functionality in a "line 3=E2=80=9D document (if these things = really are going to be separate = documents?).

That=E2=80=99s why I=E2=80=99d propose having = three documents that are adopted as a group, that are designed to go = through the process together, and heavily reference one another. The = definition of what goes in each should be based on the audience. One = other comment I have for the API is that it should likely remain = agnostic to specific protocols: it should say =E2=80=9Chere=E2=80=99s = how to send/receive with these kind of options, and protocols will treat = them like this=E2=80=9D; but the implementation document can go into = details of how those map down to specific protocol details in existing = mappings (TCP, SCTP, UDP, QUIC). My two goals in saying this = are:
1) The API should be simple and easy to understand for an = adopter=E2=80=99s perspective
2) The API should be = relevant despite changes in transport protocols de jour. Maybe in fifty = years no one is using TCP anymore; we=E2=80=99ll publish implementation = and mapping updates, but the API document should still be = unchanged.

Thanks,
Tommy

Cheers,
Michael

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

= --Boundary_(ID_14qtWJj9G+cYPyWPsruDZQ)-- From nobody Thu Jan 18 07:02:21 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 BC8A3126FB3 for ; Thu, 18 Jan 2018 07:02:19 -0800 (PST) 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 I1ul2kD6loQH for ; Thu, 18 Jan 2018 07:02:17 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 63E5F124217 for ; Thu, 18 Jan 2018 07:02:17 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id o35so20751499qtj.13 for ; Thu, 18 Jan 2018 07:02:17 -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; bh=zFYwu5YXS3VEam3WouVtH0x3J7vKN8Ll+/d0Wid9SQc=; b=tUNZ0xi1bNwJlay+QKKAgLDlrLrsH2rdAcEapOweeeMTKBCNKp3G1+XhFduYImsCi3 P63oL0Mx6EYSk9N+jpJqaEpd5t1oiYNsvJ5GxoQdO8JdXwRYvOItSQqn30QF2IhBQgSI yWsqJm8fHZcgzr6QneyGFuiTO1zeufcS+5HZiBXCx8AuEtmubfgxXTXx+vTjvmYiuIGK 18z0/6Y1nAAdrHlQheeVJdX+YBJ8KnYRr+b4RBUyXF8V9461ia7H4RRqfyVypEFQmVLN eoyRGBEhxTDjb6UxmfCg6zof31gFI9UL6zqDlVybjIrOJ5qQNFATh7bdQEorzZBJnTEo Vgjw== 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=zFYwu5YXS3VEam3WouVtH0x3J7vKN8Ll+/d0Wid9SQc=; b=O+ckxjD8PVRHEEphG1P0nkwynJ9M4hvAOznx8Pj3QSWkHD7xOil5O7RSiT1DJ1u0kw U1qRMPS8/vhc6CcxuvpxCXXwPcOmTOw0I6sKezI012iJLVI0RCmLeGHaRMJOjMvvv0wn ZIUrtgwHsxmW3uJbbeslODsHLGVGLZ9XhRwF+OiXDUIeZSYQ22e29FAE/dm/8vDetCDA 86eEcjCgl4YEwey9TMFnN5EYSJ691KTSJOCowa7GIglZMqdWjWF0ZbTQm9wXiTcZ8v9Q 1s3RpQgYxrF5KMScXOekozi0rKH4B5om1fQ4m7lnz4jyEApiOGyYlnXwB1Ro+37I5cK4 qdPw== X-Gm-Message-State: AKwxytcIx2EGEKAryk6gzzyeW4t+dUBi19N4xlGICRr+mxeaNaif2JnJ bfYng+ebuuwCKC3JxTmRN2QR5GWAf+eOUP4zE6uknA== X-Google-Smtp-Source: AH8x226bCxQXZ+et/ljc6zAX26+dm1M62/RSwhwQVbbVVqxd4rlEVwgNLD+YBTO3L+keSyMk7wNrsTOOd2FqtUuhCpU= X-Received: by 10.55.20.228 with SMTP id 97mr5435900qku.24.1516287736388; Thu, 18 Jan 2018 07:02:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.16.245 with HTTP; Thu, 18 Jan 2018 07:02:14 -0800 (PST) In-Reply-To: References: <19E34FCD-7BD6-41DB-8830-C376CF6B0623@apple.com> From: Christopher Wood Date: Thu, 18 Jan 2018 07:02:14 -0800 Message-ID: To: Tommy Pauly Cc: Michael Welzl , "taps@ietf.org" Content-Type: multipart/alternative; boundary="001a11400fe4e79f7705630e3fae" Archived-At: Subject: Re: [Taps] TAPS Documents for Charter Item 3 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, 18 Jan 2018 15:02:20 -0000 --001a11400fe4e79f7705630e3fae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 11, 2018 at 7:28 AM, Tommy Pauly wrote: > > > On Jan 11, 2018, at 12:23 AM, Michael Welzl wrote: > > Hi Tommy, > > A few answers below: > > On Jan 10, 2018, at 6:11 PM, Tommy Pauly wrote: > > Hello TAPS, > > In Singapore, there was much discussion about where we go after the minse= t > drafts, and what documents will form charter item 3: > > 3) Specify experimental support mechanisms to provide the Transport > Services identified in work item 2. This document will explain > how to select and engage an appropriate protocol and how to > discover which protocols are available for the selected service > between a given pair of end points. Further, it will provide a > basis for incremental deployment. Work on this document will > begin when the TAPS Transport Services have been specified. > > Since it would be good to get convergence and adoption of documents in > London, I=E2=80=99d like to take a stab at how we can structure the WG do= cuments > and start a discussion on this list to decide our collective approach. > > At a high level, based on the work of NEAT, Post Sockets, Happy Eyeballs, > Socket Intents, etc, it seems like the =E2=80=9Csupport mechanisms=E2=80= =9D for TAPS are > converging into categories (a) how to expose functionality in an Abstract > API and (b) guidance on how to implement a library that provides TAPS > functionality. These two categories are not unrelated, but have different > audiences; Abstract APIs are aimed at adopters of a TAPS system, while th= e > implementation guidance aspects are aimed at library and system > implementers. The high-level concepts that bind these together form the > overall TAPS architecture. > > Looking at things in this way, I could imagine three documents, which > would form the capstone of the TAPS work > 1) TAPS Architecture: high level explanation of the approach and goals, > how the API and implementations relate, and how the system is derived fro= m > the protocol surveys and minset. Defines consistent terminology for > concepts used in the other documents. > 2) TAPS API: document aimed at adopters taking advantage of a TAPS system= : > configuration, initiation of channels, listening/responding, data transfe= r, > and maintenance. > 3) TAPS Implementation Guide: document aimed at implementers on how to > bring up connections (handling a multiplicity of paths, endpoints, and > protocols), sending and receiving data through protocol stack instances, > and interpreting configuration and system policy into decisions. > > > Funny, I have also been thinking about item 3 in exactly this way for a > long time =E2=80=A6 and I believe we two are not the only ones. > This split really seems quite natural. > > > Good to hear that the split seems reasonable! > > > I believe that many (or all) of the outstanding documents we have in the > WG already fall into one or more of the categories. Here=E2=80=99s a tabl= e with the > three proposed documents as 1, 2, 3, and three aspects of a TAPS > system/architecture as A, B, C: > > > *A* > *B* > *C* > *1. TAPS Architecture* > Connection Establishment > Data transfer > Policy and Path Selection > *2. TAPS API* > Initiator/Listener/Responder > Send/Receive > Intents and configuration > *3. TAPS Implementation Guide* > Protocol Racing, Path Racing, Happy Eyeballs > Protocol Stack Instance > Policy engine > > In this table, we could see the existing documents contributing aspects t= o > certain blocks: > > draft-fairhurst-taps-neat: 1A, 1B, 1C, 2A, 2B, 2C, 3C > draft-trammell-taps-post-sockets: 1A, 1B, 1C, 2A, 2B, (2C), (3B) > draft-pauly-taps-guidelines: 3A, (1C) > draft-grinnemo-taps-he: 3A > draft-tiesel-taps-socketintents: 2C > > > I agree with this rough assessment. This table is good to think about! > I think draft-tiesel-taps-communitgrany is missing for 1) (not sure if > it=E2=80=99s A / B / C, but it=E2=80=99s about terminology) > > > Yes, this wasn=E2=80=99t a complete list. Also note that I=E2=80=99m not = proposing that we > adopt any of the documents as they are, but specifically adopt WG items f= or > Architecture, API, and Implementation, and we build those documents from > the existing ones, taking the best parts of all of them. > > > > This is a rough assignment and not necessarily exhaustive, but the point > is that much of the content is probably already there is some form, and c= an > be reinterpreted into these documents. > > What do people think about this approach? Any aspects that are missed her= e > that would need to be separate documents, or new sections across the > documents? > > > Personally I like the approach but I=E2=80=99d caution that we need a tig= ht > connection between the lines in the table. For everything we do, we must > make sure it=E2=80=99s implementable, and explain how. Hence, a document = describing > API primitives should also clarify how these primitives could be > implemented - with the split you describe above, by pointing at a specifi= c > section for each functionality in a "line 3=E2=80=9D document (if these t= hings > really are going to be separate documents?). > > > That=E2=80=99s why I=E2=80=99d propose having three documents that are ad= opted as a group, > that are designed to go through the process together, and heavily referen= ce > one another. The definition of what goes in each should be based on the > audience. One other comment I have for the API is that it should likely > remain agnostic to specific protocols: it should say =E2=80=9Chere=E2=80= =99s how to > send/receive with these kind of options, and protocols will treat them li= ke > this=E2=80=9D; but the implementation document can go into details of how= those map > down to specific protocol details in existing mappings (TCP, SCTP, UDP, > QUIC). My two goals in saying this are: > 1) The API should be simple and easy to understand for an adopter=E2=80= =99s > perspective > 2) The API should be relevant despite changes in transport protocols de > jour. Maybe in fifty years no one is using TCP anymore; we=E2=80=99ll pub= lish > implementation and mapping updates, but the API document should still be > unchanged. > +1, especially for decoupling the API from specific protocols. Best, Chris --001a11400fe4e79f7705630e3fae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 11, 2018 at 7:28 AM, Tommy Pauly <tpauly@apple= .com> wrote:


On Jan 11, 2018, at 12:23 AM, Michael Welzl <michawe@ifi.uio.no> wro= te:

= Hi Tommy,<= div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-va= riant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start= ;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;te= xt-decoration:none">
A few answers below:

On Jan 10, 2= 018, at 6:11 PM, Tommy Pauly <tpauly@apple.com> wrote:

Hello TAPS,

In Singapore, = there was much discussion about where we go after the minset drafts, and wh= at documents will form charter item 3:

3) Specify = experimental support mechanisms to provide the Transport=C2=A0
Services = identified in work item 2. This document will explain=C2=A0
how to selec= t and engage an appropriate protocol and how to=C2=A0
discover which pro= tocols are available for the selected service=C2=A0
between a given pair= of end points. Further, it will provide a=C2=A0
basis for incremental d= eployment. Work on this document will=C2=A0
begin when the TAPS Transpor= t Services have been specified.

Since it would be = good to get convergence and adoption of documents in London, I=E2=80=99d li= ke to take a stab at how we can structure the WG documents and start a disc= ussion on this list to decide our collective approach.

=
At a high level, based on the work of NEAT, Post Sockets, Happy Eyebal= ls, Socket Intents, etc, it seems like the =E2=80=9Csupport mechanisms=E2= =80=9D for TAPS are converging into categories (a) how to expose functional= ity in an Abstract API and (b) guidance on how to implement a library that = provides TAPS functionality. These two categories are not unrelated, but ha= ve different audiences; Abstract APIs are aimed at adopters of a TAPS syste= m, while the implementation guidance aspects are aimed at library and syste= m implementers. The high-level concepts that bind these together form the o= verall TAPS architecture.

Looking at things in thi= s way, I could imagine three documents, which would form the capstone of th= e TAPS work
1) TAPS Architecture: high level explanation of the a= pproach and goals, how the API and implementations relate, and how the syst= em is derived from the protocol surveys and minset. Defines consistent term= inology for concepts used in the other documents.
2) TAPS API: do= cument aimed at adopters taking advantage of a TAPS system: configuration, = initiation of channels, listening/responding, data transfer, and maintenanc= e.
3) TAPS Implementation Guide: document aimed at implementers o= n how to bring up connections (handling a multiplicity of paths, endpoints,= and protocols), sending and receiving data through protocol stack instance= s, and interpreting configuration and system policy into decisions.

Funny, I have also been thinking= about item 3 in exactly this way for a long time =E2=80=A6 and I believe w= e two are not the only ones.
This split really seems quite natura= l.


Good to hear that the split seems reasonable!
<= br>

I believe that many (or all) of the outstanding documents we= have in the WG already fall into one or more of the categories. Here=E2=80= =99s a table with the three proposed documents as 1, 2, 3, and three aspect= s of a TAPS system/architecture as A, B, C:


A
B=
C
1. TAPS Architecture
Connection Establishment
Data transfer
Policy and P= ath Selection
2. TAP= S API
Initiator/Listener/Responder
Send/Receive
Intents and configuration
3. TAPS Implementation Guide
Protocol Racing, Path R= acing, Happy Eyeballs
Protocol Stack Instance
Policy engi= ne

In this table, we c= ould see the existing documents contributing aspects to certain blocks:

draft-fairhurst-taps-neat: 1A, 1B, 1C, 2A, 2B, 2C, 3C=
draft-trammell-taps-post-sockets: 1A, 1B, 1C, 2A, 2B, (2C),= (3B)
draft-pauly-taps-guidelines: 3A, (1C)
draft-grinn= emo-taps-he: 3A
draft-tiesel-taps-socketintents: 2C

I agree with this rough assessmen= t. This table is good to think about!
I think=C2=A0draft-tiesel-t= aps-communitgrany is missing for 1) =C2=A0(not sure if it=E2=80=99s A = / B / C, but it=E2=80=99s about terminology)

Yes, this wasn=E2=80=99t a complete list. Also = note that I=E2=80=99m not proposing that we adopt any of the documents as t= hey are, but specifically adopt WG items for Architecture, API, and Impleme= ntation, and we build those documents from the existing ones, taking the be= st parts of all of them.


This is a rough assignment and not necessarily exhaustive, but th= e point is that much of the content is probably already there is some form,= and can be reinterpreted into these documents.

Wh= at do people think about this approach? Any aspects that are missed here th= at would need to be separate documents, or new sections across the document= s?

Personally I like the = approach but I=E2=80=99d caution that we need a tight connection between th= e lines in the table. For everything we do, we must make sure it=E2=80=99s = implementable, and explain how. Hence, a document describing API primitives= should also clarify how these primitives could be implemented - with the s= plit you describe above, by pointing at a specific section for each functio= nality in a "line 3=E2=80=9D document (if these things really are goin= g to be separate documents?).

=
That=E2=80=99s why I=E2=80=99d propose having three docum= ents that are adopted as a group, that are designed to go through the proce= ss together, and heavily reference one another. The definition of what goes= in each should be based on the audience. One other comment I have for the = API is that it should likely remain agnostic to specific protocols: it shou= ld say =E2=80=9Chere=E2=80=99s how to send/receive with these kind of optio= ns, and protocols will treat them like this=E2=80=9D; but the implementatio= n document can go into details of how those map down to specific protocol d= etails in existing mappings (TCP, SCTP, UDP, QUIC). My two goals in saying = this are:
1) The API should be simple and easy to understand for an ad= opter=E2=80=99s perspective
2) The API should be relevant despite change= s in transport protocols de jour. Maybe in fifty years no one is using TCP = anymore; we=E2=80=99ll publish implementation and mapping updates, but the = API document should still be unchanged.

+1, especially for decoupling the API from specific protocols.

Best,
Chris
--001a11400fe4e79f7705630e3fae-- From nobody Mon Jan 22 12:05: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 11B961270A0 for ; Mon, 22 Jan 2018 12:05:24 -0800 (PST) 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 Mo2_TmIzfZK3 for ; Mon, 22 Jan 2018 12:05:20 -0800 (PST) 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 1E0B212706D for ; Mon, 22 Jan 2018 12:05:19 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id z11so24047568qtm.3 for ; Mon, 22 Jan 2018 12:05:19 -0800 (PST) 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=3TXkePEEuBZDmJlRUXCuPqTpb38LKGRJ42aAv2FkIcs=; b=D5PgNK8Gr7HslPwsjj4CWa9/YyGQVR4m45OWFahAQKs60ptf17HFmvGb++S1pMEXLd FuL/6jJQenu9caR0jwXwNyKOmg5f3A9gvJ6W7jks/FLuEo5m9pS09HYAHaDc1u3y8uc8 8nMgLapNYH2589RR1X5dA3Svk3B6oFqgU5liW8sC3ebFA1B1InzB1yF09Rq2O1W4MGfY 2uW52BsWrSnMhkJn2chqhXWGZACsMt6NyCb/VpsnqQhcyHpmZ2AOr3CtkZNxj/nw0WNd R4Ir4gcgLRTU0zjqN7u5q6gET6tQ1BaewnJm9VELvUxl9fq0ZH+OMVymX8RpDV/VSxX1 4igg== 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=3TXkePEEuBZDmJlRUXCuPqTpb38LKGRJ42aAv2FkIcs=; b=VDElajlQ6PLGf0nCHUV0c6xrRmNr90/CluA5nyP1ynep3diAMg6z1+EPsFN1htzKXY jM4ABBF8FABz8tatP9gosa++BAVQaghA9/6IDjclBX1MuYEvBAZJPVlxOZhNk7vAI/tp HiqPpK5/o8c72s/z+Sso61Ds8p3a/TNFP+2wPEvbwTZfT1MFdRjUooWRa7HHEo7W5grE poe6i3R6SYaKfRq0dgnHbH2MQnkw7KHX18nsGXXTzGG32VG1dGZAiUMkQVibHl5WiJ4s 2kmSwqyOLKutkpWbcAjVVHfXw8kE9DXFlDCBIpYxPWGbM8gRiPGJaQi0No1o3f+FBT4V i4jQ== X-Gm-Message-State: AKwxytfLdRymv4dfgQt9JV2pFMI/rcC2HOD18kNaU0cptQMHwKsPgiqF 4vwLWdMXzLGCGHSlllc40yM= X-Google-Smtp-Source: AH8x2274Mc+x/fYuWnDPjAV9WQcS0vgDQvQqGzTT93NdY+I6B5RGqbGKSG3YJ8aRF6wK1ROns7voIg== X-Received: by 10.200.37.216 with SMTP id f24mr12379496qtf.165.1516651518051; Mon, 22 Jan 2018 12:05:18 -0800 (PST) Received: from [172.19.42.4] ([2601:184:4980:a321:ad2c:a022:cd3c:59bb]) by smtp.gmail.com with ESMTPSA id e16sm11990509qte.97.2018.01.22.12.05.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 12:05:17 -0800 (PST) From: "Aaron Falk" To: "Christopher Wood" Cc: "Tommy Pauly" , "Michael Welzl" , taps@ietf.org Date: Mon, 22 Jan 2018 15:05:15 -0500 X-Mailer: MailMate (1.10r5443) Message-ID: In-Reply-To: References: <19E34FCD-7BD6-41DB-8830-C376CF6B0623@apple.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B8E78D88-1C4B-44F9-BCC1-2F46BC500383_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[840, 14439], "plain":[461, 6272], "uuid":"13327A26-1C2E-4EC6-8E80-F4FD172660B5"}] Archived-At: Subject: Re: [Taps] TAPS Documents for Charter Item 3 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, 22 Jan 2018 20:05:24 -0000 --=_MailMate_B8E78D88-1C4B-44F9-BCC1-2F46BC500383_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I like this structure (quite a bit!) but it’s not clear to me from the discussion whether we have one approach or several. Can we consolidate into a single approach? We had discussed this in Singapore but I want to be sure folks believe it. :) When we chartered, we imagined that there may be multiple approaches, which seemed undesirable but tolerable given the researchy nature of the wg. —aaron On 18 Jan 2018, at 10:02, Christopher Wood wrote: > On Thu, Jan 11, 2018 at 7:28 AM, Tommy Pauly wrote: > >> >> >> On Jan 11, 2018, at 12:23 AM, Michael Welzl >> wrote: >> >> Hi Tommy, >> >> A few answers below: >> >> On Jan 10, 2018, at 6:11 PM, Tommy Pauly wrote: >> >> Hello TAPS, >> >> In Singapore, there was much discussion about where we go after the >> minset >> drafts, and what documents will form charter item 3: >> >> 3) Specify experimental support mechanisms to provide the Transport >> Services identified in work item 2. This document will explain >> how to select and engage an appropriate protocol and how to >> discover which protocols are available for the selected service >> between a given pair of end points. Further, it will provide a >> basis for incremental deployment. Work on this document will >> begin when the TAPS Transport Services have been specified. >> >> Since it would be good to get convergence and adoption of documents >> in >> London, I’d like to take a stab at how we can structure the WG >> documents >> and start a discussion on this list to decide our collective >> approach. >> >> At a high level, based on the work of NEAT, Post Sockets, Happy >> Eyeballs, >> Socket Intents, etc, it seems like the “support mechanisms” for >> TAPS are >> converging into categories (a) how to expose functionality in an >> Abstract >> API and (b) guidance on how to implement a library that provides TAPS >> functionality. These two categories are not unrelated, but have >> different >> audiences; Abstract APIs are aimed at adopters of a TAPS system, >> while the >> implementation guidance aspects are aimed at library and system >> implementers. The high-level concepts that bind these together form >> the >> overall TAPS architecture. >> >> Looking at things in this way, I could imagine three documents, which >> would form the capstone of the TAPS work >> 1) TAPS Architecture: high level explanation of the approach and >> goals, >> how the API and implementations relate, and how the system is derived >> from >> the protocol surveys and minset. Defines consistent terminology for >> concepts used in the other documents. >> 2) TAPS API: document aimed at adopters taking advantage of a TAPS >> system: >> configuration, initiation of channels, listening/responding, data >> transfer, >> and maintenance. >> 3) TAPS Implementation Guide: document aimed at implementers on how >> to >> bring up connections (handling a multiplicity of paths, endpoints, >> and >> protocols), sending and receiving data through protocol stack >> instances, >> and interpreting configuration and system policy into decisions. >> >> >> Funny, I have also been thinking about item 3 in exactly this way for >> a >> long time … and I believe we two are not the only ones. >> This split really seems quite natural. >> >> >> Good to hear that the split seems reasonable! >> >> >> I believe that many (or all) of the outstanding documents we have in >> the >> WG already fall into one or more of the categories. Here’s a table >> with the >> three proposed documents as 1, 2, 3, and three aspects of a TAPS >> system/architecture as A, B, C: >> >> >> *A* >> *B* >> *C* >> *1. TAPS Architecture* >> Connection Establishment >> Data transfer >> Policy and Path Selection >> *2. TAPS API* >> Initiator/Listener/Responder >> Send/Receive >> Intents and configuration >> *3. TAPS Implementation Guide* >> Protocol Racing, Path Racing, Happy Eyeballs >> Protocol Stack Instance >> Policy engine >> >> In this table, we could see the existing documents contributing >> aspects to >> certain blocks: >> >> draft-fairhurst-taps-neat: 1A, 1B, 1C, 2A, 2B, 2C, 3C >> draft-trammell-taps-post-sockets: 1A, 1B, 1C, 2A, 2B, (2C), (3B) >> draft-pauly-taps-guidelines: 3A, (1C) >> draft-grinnemo-taps-he: 3A >> draft-tiesel-taps-socketintents: 2C >> >> >> I agree with this rough assessment. This table is good to think >> about! >> I think draft-tiesel-taps-communitgrany is missing for 1) (not sure >> if >> it’s A / B / C, but it’s about terminology) >> >> >> Yes, this wasn’t a complete list. Also note that I’m not >> proposing that we >> adopt any of the documents as they are, but specifically adopt WG >> items for >> Architecture, API, and Implementation, and we build those documents >> from >> the existing ones, taking the best parts of all of them. >> >> >> >> This is a rough assignment and not necessarily exhaustive, but the >> point >> is that much of the content is probably already there is some form, >> and can >> be reinterpreted into these documents. >> >> What do people think about this approach? Any aspects that are missed >> here >> that would need to be separate documents, or new sections across the >> documents? >> >> >> Personally I like the approach but I’d caution that we need a tight >> connection between the lines in the table. For everything we do, we >> must >> make sure it’s implementable, and explain how. Hence, a document >> describing >> API primitives should also clarify how these primitives could be >> implemented - with the split you describe above, by pointing at a >> specific >> section for each functionality in a "line 3” document (if these >> things >> really are going to be separate documents?). >> >> >> That’s why I’d propose having three documents that are adopted as >> a group, >> that are designed to go through the process together, and heavily >> reference >> one another. The definition of what goes in each should be based on >> the >> audience. One other comment I have for the API is that it should >> likely >> remain agnostic to specific protocols: it should say “here’s how >> to >> send/receive with these kind of options, and protocols will treat >> them like >> this”; but the implementation document can go into details of how >> those map >> down to specific protocol details in existing mappings (TCP, SCTP, >> UDP, >> QUIC). My two goals in saying this are: >> 1) The API should be simple and easy to understand for an adopter’s >> perspective >> 2) The API should be relevant despite changes in transport protocols >> de >> jour. Maybe in fifty years no one is using TCP anymore; we’ll >> publish >> implementation and mapping updates, but the API document should still >> be >> unchanged. >> > > +1, especially for decoupling the API from specific protocols. > > Best, > Chris > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --=_MailMate_B8E78D88-1C4B-44F9-BCC1-2F46BC500383_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I like this structure (quite a bit!) but it=E2=80=99s not = clear to me from the discussion whether we have one approach or several. = Can we consolidate into a single approach? We had discussed this in Sin= gapore but I want to be sure folks believe it. :) When we chartered, we= imagined that there may be multiple approaches, which seemed undesirable= but tolerable given the researchy nature of the wg.

=E2=80=94aaron

On 18 Jan 2018, at 10:02, Christopher Wood wrote:

On Thu, Jan 11, 2018 at 7:28 AM, Tommy Pauly <tpauly@app= le.com> wrote:


On Jan 11, 2018, at 12:23 AM, Michael Welzl <= ;michawe@ifi.uio.= no> wrote:

Hi Tommy,

A few answers below:

On Jan 10, 2018, at 6:11 PM, Tommy Paul= y <tpauly@apple.= com> wrote:

Hello TAPS,

In Singapore, there was much disc= ussion about where we go after the minset drafts, and what documents will= form charter item 3:

3) Specify experimental su= pport mechanisms to provide the Transport=C2=A0
Services identified in= work item 2. This document will explain=C2=A0
how to select and engag= e an appropriate protocol and how to=C2=A0
discover which protocols ar= e available for the selected service=C2=A0
between a given pair of end= points. Further, it will provide a=C2=A0
basis for incremental deploy= ment. Work on this document will=C2=A0
begin when the TAPS Transport S= ervices have been specified.

Since it would be g= ood to get convergence and adoption of documents in London, I=E2=80=99d l= ike to take a stab at how we can structure the WG documents and start a d= iscussion on this list to decide our collective approach.

<= /div>
At a high level, based on the work of NEAT, Post Sockets, Happy= Eyeballs, Socket Intents, etc, it seems like the =E2=80=9Csupport mechan= isms=E2=80=9D for TAPS are converging into categories (a) how to expose f= unctionality in an Abstract API and (b) guidance on how to implement a li= brary that provides TAPS functionality. These two categories are not unre= lated, but have different audiences; Abstract APIs are aimed at adopters = of a TAPS system, while the implementation guidance aspects are aimed at = library and system implementers. The high-level concepts that bind these = together form the overall TAPS architecture.

Loo= king at things in this way, I could imagine three documents, which would = form the capstone of the TAPS work
1) TAPS Architecture: high l= evel explanation of the approach and goals, how the API and implementatio= ns relate, and how the system is derived from the protocol surveys and mi= nset. Defines consistent terminology for concepts used in the other docum= ents.
2) TAPS API: document aimed at adopters taking advantage = of a TAPS system: configuration, initiation of channels, listening/respon= ding, data transfer, and maintenance.
3) TAPS Implementation Gu= ide: document aimed at implementers on how to bring up connections (handl= ing a multiplicity of paths, endpoints, and protocols), sending and recei= ving data through protocol stack instances, and interpreting configuratio= n and system policy into decisions.
Funny, I have also been thinking about item 3 in exactly thi= s way for a long time =E2=80=A6 and I believe we two are not the only one= s.
This split really seems quite natural.

<= /div>

Good to hear tha= t the split seems reasonable!


I believe that many (or all) of the outstanding documents we have in t= he WG already fall into one or more of the categories. Here=E2=80=99s a t= able with the three proposed documents as 1, 2, 3, and three aspects of a= TAPS system/architecture as A, B, C:


A
B
C
1. TAPS Architecture
Connection Establi= shment
Data transfer
Policy and Path Se= lection
2.= TAPS API
Initiator/Listener/Responder
<= /td>
Send/Receive
Intents and configuration
<= /td>
3. TAPS Implementation = Guide
= Protocol Racing, Path Racing, Happy Eyeballs
Protocol Stack Instance
Policy engine

In this table, we could = see the existing documents contributing aspects to certain blocks:
<= div>
draft-fairhurst-taps-neat: 1A, 1B, 1C, 2A, 2B, 2C, 3C<= /div>
draft-trammell-taps-post-sockets: 1A, 1B, 1C, 2A, 2B, (2C)= , (3B)
draft-pauly-taps-guidelines: 3A, (1C)
draft-gr= innemo-taps-he: 3A
draft-tiesel-taps-socketintents: 2C

I agree with this rough as= sessment. This table is good to think about!
I think=C2=A0draft= -tiesel-taps-communitgrany is missing for 1) =C2=A0(not sure if it=E2= =80=99s A / B / C, but it=E2=80=99s about terminology)
<= /div>

Yes, this wasn=E2=80=99t a comple= te list. Also note that I=E2=80=99m not proposing that we adopt any of th= e documents as they are, but specifically adopt WG items for Architecture= , API, and Implementation, and we build those documents from the existing= ones, taking the best parts of all of them.


This is a rough assignment and no= t necessarily exhaustive, but the point is that much of the content is pr= obably already there is some form, and can be reinterpreted into these do= cuments.

What do people think about this approac= h? Any aspects that are missed here that would need to be separate docume= nts, or new sections across the documents?
=

Personally I like the approach but I=E2=80=99d cautio= n that we need a tight connection between the lines in the table. For eve= rything we do, we must make sure it=E2=80=99s implementable, and explain = how. Hence, a document describing API primitives should also clarify how = these primitives could be implemented - with the split you describe above= , by pointing at a specific section for each functionality in a "lin= e 3=E2=80=9D document (if these things really are going to be separate do= cuments?).

That=E2=80=99s why I=E2=80=99d propose having three documents that are a= dopted as a group, that are designed to go through the process together, = and heavily reference one another. The definition of what goes in each sh= ould be based on the audience. One other comment I have for the API is th= at it should likely remain agnostic to specific protocols: it should say = =E2=80=9Chere=E2=80=99s how to send/receive with these kind of options, a= nd protocols will treat them like this=E2=80=9D; but the implementation d= ocument can go into details of how those map down to specific protocol de= tails in existing mappings (TCP, SCTP, UDP, QUIC). My two goals in saying= this are:
1) The API should be simple and easy to understand for an= adopter=E2=80=99s perspective
2) The API should be relevant despite c= hanges in transport protocols de jour. Maybe in fifty years no one is usi= ng TCP anymore; we=E2=80=99ll publish implementation and mapping updates,= but the API document should still be unchanged.=

+1, especially for decoupling the API from specific p= rotocols.

Best,
Chris

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

--=_MailMate_B8E78D88-1C4B-44F9-BCC1-2F46BC500383_=-- From nobody Mon Jan 22 12:59: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 991F012D7E4 for ; Mon, 22 Jan 2018 12:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_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 8-mMR1wjsQzA for ; Mon, 22 Jan 2018 12:59:53 -0800 (PST) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0AC12D7E5 for ; Mon, 22 Jan 2018 12:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1516654792; x=2380568392; 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=/jPni7+wUDi5jfqewsVg4yRQbwxqH67LHe6PipuUYXI=; b=QpQ13YyrnQoammF6tb3xOJ+CbbHHUcFiH+5u9uMYgOJTFAt9p/UiX2NG08EuZk47 QDje70WD7p6xcHBvKU4dhhxEfhOmA271Z3Q/wmKbvdNC3KZwZE3OPjiEn0vXJegp ZCLk8g2ikRfJEpGkZqSu4i2r4jU5xYj2ZkzSyi+xPByFyav2kwyWkeHvsOV9ltS/ 2TEGUmgw4XYUAod7xXlHq4cBQT9et1nRVMFa9w3cyIXB+JjQKYjys4AJ+n8K/xN3 ziF4C+GtMzPNgnvI6bAcl+7WrkrlNUVozdkXsITKG+29tfX+BakMRehyhhHwW9xH hcvGXSFOGmcaCfC82zf/yQ==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id 80.4E.05970.7C0566A5; Mon, 22 Jan 2018 12:59:52 -0800 (PST) X-AuditID: 11ab0217-f00cb9e000001752-99-5a6650c75ae6 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay4.apple.com (Apple SCV relay) with SMTP id 4C.A3.21277.7C0566A5; Mon, 22 Jan 2018 12:59:51 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_1+/GxQWe30rM1wjq8et5ZQ)" Received: from da0602a-dhcp178.apple.com (da0602a-dhcp178.apple.com [17.226.23.178]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.1.20180104 64bit (built Jan 4 2018)) with ESMTPSA id <0P2Z009KX6BRZ4A0@nwk-mmpp-sz12.apple.com>; Mon, 22 Jan 2018 12:59:51 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Mon, 22 Jan 2018 12:59:50 -0800 In-reply-to: Cc: Christopher Wood , Michael Welzl , taps@ietf.org To: Aaron Falk References: <19E34FCD-7BD6-41DB-8830-C376CF6B0623@apple.com> X-Mailer: Apple Mail (2.3458) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUi2FAYrnsiIC3KYHGvqEXb72msFtO/X2Oz +HF2J6vFnRgHFo+ds+6yeyxZ8pPJY/Xqh8wBzFFcNimpOZllqUX6dglcGW+erWQtOP+EseJr 42WmBsbdxxm7GDk5JARMJB5dmcPUxcjFISSwhkliQecZZphEZ+9yFhBbSOAQo8S2xy4gNq+A oMSPyffA4swCYRKn33yHal7LJLH5ewt7FyMHh7CAhMTmPYkgNWwCKhLHv21ghui1kXj+YjYj RImpxLWF1iBhFgFViQddV5lAbE4BW4kvX79AjU+XWLO3jw3EFgGqWfainQ1i1VwmiV33pkHd KSuxcvZdVpCEhMAaNolF196zT2AUmoXk1llIbp0FtJtZQF1iypRciLC2xJN3F1ghbDWJhb8X MSGLL2BkW8UonJuYmaObmWdkrJdYUJCTqpecn7uJERQpq5nEdzB+fm14iFGAg1GJh1eBMS1K iDWxrLgy9xCjNAeLkjjvi5rEKCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Mqn6+XSnKz0Ss rN/6HDTR1A1Ll8yf9e5YTeweO5vlSyJ3J6WFRkRWFzCKnj9QKyaoGVbg0r0qwdTc88uyxGlR eycq3V8UeXlvl/vmlulfdi421b+y8P3tt/kihsmyxts3/BY+3reOW1OO/3j7/CWVC32FFbl7 dOK15HlDAptrE5ZK3FNN/azEUpyRaKjFXFScCAD50zxydQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUi2FB8Rvd4QFqUwf5mbYu239NYLaZ/v8Zm 8ePsTlaLOzEOLB47Z91l91iy5CeTx+rVD5kDmKO4bFJSczLLUov07RK4Mt48W8lacP4JY8XX xstMDYy7jzN2MXJySAiYSHT2LmcBsYUEDjFKbHvsAmLzCghK/Jh8DyzOLBAmcfrNd6YuRi6g mrVMEpu/t7B3MXJwCAtISGzekwhSwyagInH82wZmiF4biecvZjNClJhKXFtoDRJmEVCVeNB1 lQnE5hSwlfjy9QvU+HSJNXv72EBsEaCaZS/a2SBWzWWS2HVvGjPEnbISK2ffZZ3AyD8LyXmz kJw3C2gds4C6xJQpuRBhbYkn7y6wQthqEgt/L2JCFl/AyLaKUaAoNSex0kQvsaAgJ1UvOT93 EyM4rAvDdzD+W2Z1iFGAg1GJh/fEv9QoIdbEsuLKXGAQcTArifCmrQAK8aYkVlalFuXHF5Xm pBYfYpTmYFES542/kRIlJJCeWJKanZpakFoEk2Xi4JRqYOSxnL5M4dXTjr0LXjyPuHp42efk HoEMVaXt52//O1J31u7guhqDDx9UCtwex3Or31FgcFwVf2XvvdlbF5741JQQsFWutO7nCpf2 FJ+ITS8kj/Z8Sfe0WJk+VUHou490q9mbiopHl4TYd3l9vfMm+sE9//aXDwMm//gYmG+tVsT6 zn/28SoWVT0lluKMREMt5qLiRACF5EqpZwIAAA== Archived-At: Subject: Re: [Taps] TAPS Documents for Charter Item 3 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, 22 Jan 2018 20:59:56 -0000 --Boundary_(ID_1+/GxQWe30rM1wjq8et5ZQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable I think we=E2=80=99re going to try to discuss and come together for a = single approach for the architecture and documents. Ideally, I=E2=80=99d = like to see a single set of unified Architecture/API/Implementation = documents that embody the generic TAPS work as an approach. However, = since there will be many different implementations (which is always a = good thing for IETF work), I=E2=80=99d expect that the specific names = and terms will vary in the individual codebases. The goal would be that = the documents provide a common set of language for referring to aspects = beyond any one implementation as a framework and guide for specific = implementations. If we can get all agreed, it would be great to have a set of common = documents we can look over for London! Thanks, Tommy > On Jan 22, 2018, at 12:05 PM, Aaron Falk wrote: >=20 > I like this structure (quite a bit!) but it=E2=80=99s not clear to me = from the discussion whether we have one approach or several. Can we = consolidate into a single approach? We had discussed this in Singapore = but I want to be sure folks believe it. :) When we chartered, we = imagined that there may be multiple approaches, which seemed undesirable = but tolerable given the researchy nature of the wg. >=20 > =E2=80=94aaron >=20 > On 18 Jan 2018, at 10:02, Christopher Wood wrote: >=20 > On Thu, Jan 11, 2018 at 7:28 AM, Tommy Pauly > wrote: >=20 >=20 >> On Jan 11, 2018, at 12:23 AM, Michael Welzl > wrote: >>=20 >> Hi Tommy, >>=20 >> A few answers below: >>=20 >>> On Jan 10, 2018, at 6:11 PM, Tommy Pauly > wrote: >>>=20 >>> Hello TAPS, >>>=20 >>> In Singapore, there was much discussion about where we go after the = minset drafts, and what documents will form charter item 3: >>>=20 >>> 3) Specify experimental support mechanisms to provide the Transport=20= >>> Services identified in work item 2. This document will explain=20 >>> how to select and engage an appropriate protocol and how to=20 >>> discover which protocols are available for the selected service=20 >>> between a given pair of end points. Further, it will provide a=20 >>> basis for incremental deployment. Work on this document will=20 >>> begin when the TAPS Transport Services have been specified. >>>=20 >>> Since it would be good to get convergence and adoption of documents = in London, I=E2=80=99d like to take a stab at how we can structure the = WG documents and start a discussion on this list to decide our = collective approach. >>>=20 >>> At a high level, based on the work of NEAT, Post Sockets, Happy = Eyeballs, Socket Intents, etc, it seems like the =E2=80=9Csupport = mechanisms=E2=80=9D for TAPS are converging into categories (a) how to = expose functionality in an Abstract API and (b) guidance on how to = implement a library that provides TAPS functionality. These two = categories are not unrelated, but have different audiences; Abstract = APIs are aimed at adopters of a TAPS system, while the implementation = guidance aspects are aimed at library and system implementers. The = high-level concepts that bind these together form the overall TAPS = architecture. >>>=20 >>> Looking at things in this way, I could imagine three documents, = which would form the capstone of the TAPS work >>> 1) TAPS Architecture: high level explanation of the approach and = goals, how the API and implementations relate, and how the system is = derived from the protocol surveys and minset. Defines consistent = terminology for concepts used in the other documents. >>> 2) TAPS API: document aimed at adopters taking advantage of a TAPS = system: configuration, initiation of channels, listening/responding, = data transfer, and maintenance. >>> 3) TAPS Implementation Guide: document aimed at implementers on how = to bring up connections (handling a multiplicity of paths, endpoints, = and protocols), sending and receiving data through protocol stack = instances, and interpreting configuration and system policy into = decisions. >>=20 >> Funny, I have also been thinking about item 3 in exactly this way for = a long time =E2=80=A6 and I believe we two are not the only ones. >> This split really seems quite natural. >>=20 >=20 > Good to hear that the split seems reasonable! >=20 >>=20 >>> I believe that many (or all) of the outstanding documents we have in = the WG already fall into one or more of the categories. Here=E2=80=99s a = table with the three proposed documents as 1, 2, 3, and three aspects of = a TAPS system/architecture as A, B, C: >>>=20 >>>=20 >>> A >>> B >>> C >>> 1. TAPS Architecture >>> Connection Establishment >>> Data transfer >>> Policy and Path Selection >>> 2. TAPS API >>> Initiator/Listener/Responder >>> Send/Receive >>> Intents and configuration >>> 3. TAPS Implementation Guide >>> Protocol Racing, Path Racing, Happy Eyeballs >>> Protocol Stack Instance >>> Policy engine >>>=20 >>> In this table, we could see the existing documents contributing = aspects to certain blocks: >>>=20 >>> draft-fairhurst-taps-neat: 1A, 1B, 1C, 2A, 2B, 2C, 3C >>> draft-trammell-taps-post-sockets: 1A, 1B, 1C, 2A, 2B, (2C), (3B) >>> draft-pauly-taps-guidelines: 3A, (1C) >>> draft-grinnemo-taps-he: 3A >>> draft-tiesel-taps-socketintents: 2C >>=20 >> I agree with this rough assessment. This table is good to think = about! >> I think draft-tiesel-taps-communitgrany is missing for 1) (not sure = if it=E2=80=99s A / B / C, but it=E2=80=99s about terminology) >=20 > Yes, this wasn=E2=80=99t a complete list. Also note that I=E2=80=99m = not proposing that we adopt any of the documents as they are, but = specifically adopt WG items for Architecture, API, and Implementation, = and we build those documents from the existing ones, taking the best = parts of all of them. >>=20 >>=20 >>> This is a rough assignment and not necessarily exhaustive, but the = point is that much of the content is probably already there is some = form, and can be reinterpreted into these documents. >>>=20 >>> What do people think about this approach? Any aspects that are = missed here that would need to be separate documents, or new sections = across the documents? >>=20 >> Personally I like the approach but I=E2=80=99d caution that we need a = tight connection between the lines in the table. For everything we do, = we must make sure it=E2=80=99s implementable, and explain how. Hence, a = document describing API primitives should also clarify how these = primitives could be implemented - with the split you describe above, by = pointing at a specific section for each functionality in a "line 3=E2=80=9D= document (if these things really are going to be separate documents?). >=20 > That=E2=80=99s why I=E2=80=99d propose having three documents that are = adopted as a group, that are designed to go through the process = together, and heavily reference one another. The definition of what goes = in each should be based on the audience. One other comment I have for = the API is that it should likely remain agnostic to specific protocols: = it should say =E2=80=9Chere=E2=80=99s how to send/receive with these = kind of options, and protocols will treat them like this=E2=80=9D; but = the implementation document can go into details of how those map down to = specific protocol details in existing mappings (TCP, SCTP, UDP, QUIC). = My two goals in saying this are: > 1) The API should be simple and easy to understand for an adopter=E2=80=99= s perspective > 2) The API should be relevant despite changes in transport protocols = de jour. Maybe in fifty years no one is using TCP anymore; we=E2=80=99ll = publish implementation and mapping updates, but the API document should = still be unchanged. >=20 > +1, especially for decoupling the API from specific protocols. >=20 > Best, > Chris > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps = --Boundary_(ID_1+/GxQWe30rM1wjq8et5ZQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable I = think we=E2=80=99re going to try to discuss and come together for a = single approach for the architecture and documents. Ideally, I=E2=80=99d = like to see a single set of unified Architecture/API/Implementation = documents that embody the generic TAPS work as an approach. However, = since there will be many different implementations (which is always a = good thing for IETF work), I=E2=80=99d expect that the specific names = and terms will vary in the individual codebases. The goal would be that = the documents provide a common set of language for referring to aspects = beyond any one implementation as a framework and guide for specific = implementations.

If = we can get all agreed, it would be great to have a set of common = documents we can look over for London!

Thanks,
Tommy

On Jan 22, 2018, at 12:05 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

I = like this structure (quite a bit!) but it=E2=80=99s not clear to me from = the discussion whether we have one approach or several. Can we = consolidate into a single approach? We had discussed this in Singapore = but I want to be sure folks believe it. :) When we chartered, we = imagined that there may be multiple approaches, which seemed undesirable = but tolerable given the researchy nature of the wg.

=E2=80=94aaron

On 18 Jan 2018, = at 10:02, Christopher Wood wrote:

On Thu, Jan 11, 2018 at 7:28 AM, Tommy Pauly <tpauly@apple.com> wrote:

On Jan 11, 2018, at 12:23 AM, = Michael Welzl <michawe@ifi.uio.no> wrote:

Hi = Tommy,

A few answers below:

On Jan 10, 2018, at 6:11 PM, = Tommy Pauly <tpauly@apple.com> wrote:

Hello TAPS,

In Singapore, there was much discussion about where we go = after the minset drafts, and what documents will form charter item = 3:

3) Specify = experimental support mechanisms to provide the Transport 
Services identified in work item 2. This document will = explain 
how to select and engage an appropriate = protocol and how to 
discover which protocols are = available for the selected service 
between a given = pair of end points. Further, it will provide a 
basis = for incremental deployment. Work on this document will 
begin when the TAPS Transport Services have been = specified.

Since= it would be good to get convergence and adoption of documents in = London, I=E2=80=99d like to take a stab at how we can structure the WG = documents and start a discussion on this list to decide our collective = approach.

At a = high level, based on the work of NEAT, Post Sockets, Happy Eyeballs, = Socket Intents, etc, it seems like the =E2=80=9Csupport mechanisms=E2=80=9D= for TAPS are converging into categories (a) how to expose functionality = in an Abstract API and (b) guidance on how to implement a library that = provides TAPS functionality. These two categories are not unrelated, but = have different audiences; Abstract APIs are aimed at adopters of a TAPS = system, while the implementation guidance aspects are aimed at library = and system implementers. The high-level concepts that bind these = together form the overall TAPS architecture.

Looking at things in this way, I could = imagine three documents, which would form the capstone of the TAPS = work
1) TAPS Architecture: high level explanation = of the approach and goals, how the API and implementations relate, and = how the system is derived from the protocol surveys and minset. Defines = consistent terminology for concepts used in the other = documents.
2) TAPS API: document aimed at adopters = taking advantage of a TAPS system: configuration, initiation of = channels, listening/responding, data transfer, and = maintenance.
3) TAPS Implementation Guide: document = aimed at implementers on how to bring up connections (handling a = multiplicity of paths, endpoints, and protocols), sending and receiving = data through protocol stack instances, and interpreting configuration = and system policy into decisions.

Funny, I have also been = thinking about item 3 in exactly this way for a long time =E2=80=A6 and = I believe we two are not the only ones.
This split = really seems quite natural.


Good to hear that the split = seems reasonable!


I believe that many (or all) of the = outstanding documents we have in the WG already fall into one or more of = the categories. Here=E2=80=99s a table with the three proposed documents = as 1, 2, 3, and three aspects of a TAPS system/architecture as A, B, = C:


A
B
C
1. TAPS Architecture
Connection Establishment
Data transfer
Policy and Path Selection
2. TAPS API
Initiator/Listener/Responder
Send/Receive
Intents and configuration
3. TAPS Implementation = Guide
Protocol Racing, Path Racing, Happy = Eyeballs
Protocol Stack Instance
Policy engine

In this table, we could see the = existing documents contributing aspects to certain blocks:

draft-fairhurst-taps-neat:= 1A, 1B, 1C, 2A, 2B, 2C, 3C
draft-trammell-taps-post-sockets: 1A, 1B, 1C, = 2A, 2B, (2C), (3B)
draft-pauly-taps-guidelines: 3A, = (1C)
draft-grinnemo-taps-he: 3A
draft-tiesel-taps-socketintents: = 2C

I agree with this rough assessment. This table is good to = think about!
I think draft-tiesel-taps-communitgrany is missing for 1)  (not sure if it=E2=80=99s= A / B / C, but it=E2=80=99s about = terminology)

Yes, this wasn=E2=80=99t a complete list. Also = note that I=E2=80=99m not proposing that we adopt any of the documents = as they are, but specifically adopt WG items for Architecture, API, and = Implementation, and we build those documents from the existing ones, = taking the best parts of all of them.


This is a rough assignment and not = necessarily exhaustive, but the point is that much of the content is = probably already there is some form, and can be reinterpreted into these = documents.

What = do people think about this approach? Any aspects that are missed here = that would need to be separate documents, or new sections across the = documents?

Personally I like the approach but = I=E2=80=99d caution that we need a tight connection between the lines in = the table. For everything we do, we must make sure it=E2=80=99s = implementable, and explain how. Hence, a document describing API = primitives should also clarify how these primitives could be implemented = - with the split you describe above, by pointing at a specific section = for each functionality in a "line 3=E2=80=9D document (if these things = really are going to be separate = documents?).

That=E2=80=99s why I=E2=80=99d = propose having three documents that are adopted as a group, that are = designed to go through the process together, and heavily reference one = another. The definition of what goes in each should be based on the = audience. One other comment I have for the API is that it should likely = remain agnostic to specific protocols: it should say =E2=80=9Chere=E2=80=99= s how to send/receive with these kind of options, and protocols will = treat them like this=E2=80=9D; but the implementation document can go = into details of how those map down to specific protocol details in = existing mappings (TCP, SCTP, UDP, QUIC). My two goals in saying this = are:
1) The API should be simple and easy to understand for an = adopter=E2=80=99s perspective
2) The API should be = relevant despite changes in transport protocols de jour. Maybe in fifty = years no one is using TCP anymore; we=E2=80=99ll publish implementation = and mapping updates, but the API document should still be = unchanged.

+1, especially for decoupling the API = from specific protocols.

Best,
Chris

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


= --Boundary_(ID_1+/GxQWe30rM1wjq8et5ZQ)-- From nobody Tue Jan 23 19:43:01 2018 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 954DA1275C5; Tue, 23 Jan 2018 19:42:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: taps-chairs@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151676537558.24169.380539291213052978.idtracker@ietfa.amsl.com> Date: Tue, 23 Jan 2018 19:42:55 -0800 Archived-At: Subject: [Taps] Ben Campbell's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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, 24 Jan 2018 03:42:55 -0000 Ben Campbell has entered the following ballot position for charter-ietf-taps-01-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Do I read correctly that the only change from the previous charter is to remove the paragraph about coordinating with TCPINC? If so, I'm not sure that change is important enough to justify rechartering, but I won't get in the way if other people agree with it. From nobody Wed Jan 24 01:53: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 9E01F12DA0C for ; Wed, 24 Jan 2018 01:53:12 -0800 (PST) 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 cFM7EROwwuPq for ; Wed, 24 Jan 2018 01:53:10 -0800 (PST) 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 E30B012DA07 for ; Wed, 24 Jan 2018 01:53:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=bwkz4s4I9jbDPbc9GJAdLOo5UUhfVaNhWVJCXqto3BiO8rZhsqlF1R4NGcESkhV2PIMrSOVIYMMkcso8aSqst4SzJwRBU/r11agK90IK3AHgbTS/2KQ2FBcplhm7ndyE2trSDDmeLD44Uv0/BUuXDkcnptzLBu97y0VuG23Sz2o=; h=Received:Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 25972 invoked from network); 24 Jan 2018 10:53:07 +0100 Received: from nb-10688.ethz.ch (HELO ?82.130.103.20?) (82.130.103.20) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 24 Jan 2018 10:53:07 +0100 To: Ben Campbell , The IESG Cc: taps-chairs@ietf.org, taps@ietf.org References: <151676537558.24169.380539291213052978.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <30b504ab-76e4-2f53-7f39-4678f2784753@kuehlewind.net> Date: Wed, 24 Jan 2018 10:53:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <151676537558.24169.380539291213052978.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-PPP-Message-ID: <20180124095307.25965.63037@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Taps] Ben Campbell's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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, 24 Jan 2018 09:53:13 -0000 Hi Ben, this change rather removed the restriction to not analyze features of security protocols (other than tcpinc); this is mainly the first sentence. As we see a closer integration of TLS with QUIC and we in general think that security features are important, it is actually an important change to allow us to do some additional work in this space. Mirja On 24.01.2018 04:42, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > charter-ietf-taps-01-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-taps/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Do I read correctly that the only change from the previous charter is to remove > the paragraph about coordinating with TCPINC? If so, I'm not sure that change > is important enough to justify rechartering, but I won't get in the way if > other people agree with it. > > From nobody Wed Jan 24 06:38:15 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2F5124D68; Wed, 24 Jan 2018 06:38:08 -0800 (PST) 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 SnyacZQ0RvpJ; Wed, 24 Jan 2018 06:38:06 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608C412422F; Wed, 24 Jan 2018 06:38:06 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id t201so1559169ywf.1; Wed, 24 Jan 2018 06:38:06 -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; bh=lI6toIkdHsXR/74T1FLUw90c5pe7Mihnb2WzYyIg+G8=; b=Uy55k81hf5pdTjKJIv5R40XjL7bQYfYyKChgWAZ1gwWR0YNpaLToImdt0tyE2pNSZ2 XwA39/YcwCSh7eMQfYqVpHtVaFS3BaGUYFiCRL79Xvq8BIEqtZN4LaZFQu6U0zfRJulH yxAFfD9+nSciaw5D/ai59rhwXX84z8uvkZVPv8ec6a2XSu9IBB+vFxs7aU0lddWSZSWQ Puq6L+vjAB2DYR5wb5MtkqTYLCR1TwdoV2hkktU/+rB4/pnkV5obr4FH5J3Is0oCPfpQ ims3JgizR7/3lKZKvN6J+EKlkMhobWxhYM7ETqXQwPnnG+GdrR9I8D9lt+rr9L+q33I1 69Ng== 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=lI6toIkdHsXR/74T1FLUw90c5pe7Mihnb2WzYyIg+G8=; b=Ye4gnzdrbEQpJvkkL3nohQS3CQjIcpYcEq0rCKRuvbz+BEjdO/Qz1TTsXSKJ/DKHSi cxumZUaDlIFhzOV1AIrXFeNpd0XzwpyDfgB4/lBAk9e+VEKvGQZxrnCDR4OWQRf0aORc nOVC4YlVD0maLSAu3AbGY4D+TvQX4d9sNkD8bo699VmFF59/UNzOYDKeUqq2T5QaU2oJ WfWijRg4UpMmeZ+mjpb3gxdmYeNMP1okW0O/cHSxwnFEzDweV8DkezbZnaObiXonaBp4 Nbzb3nK04ZI6xSrxfM/5FmHRSPxATC+MtDnulQJKD/HAm5VgdHrDf+J0xv71cqEcpb77 Fbsw== X-Gm-Message-State: AKwxytcMiE9TY5PNMnaQ50Scse9+drncg4BFjdnLkf/nLuH3lPh2wtKv cjiscSmpv+vU+W9dcQcvVaFKffa/5V4kJOSJ43w= X-Google-Smtp-Source: AH8x227rbBn4Vr1cNlM4nEbIVy4x869vDIMmrApv7xhD+LDihm9Xqz0KfSniaOfmnvkx5YiDKM9/fKYb0JWIkH0ZYNg= X-Received: by 10.129.78.14 with SMTP id c14mr5427453ywb.109.1516804685448; Wed, 24 Jan 2018 06:38:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.20.4 with HTTP; Wed, 24 Jan 2018 06:38:05 -0800 (PST) In-Reply-To: <30b504ab-76e4-2f53-7f39-4678f2784753@kuehlewind.net> References: <151676537558.24169.380539291213052978.idtracker@ietfa.amsl.com> <30b504ab-76e4-2f53-7f39-4678f2784753@kuehlewind.net> From: Spencer Dawkins at IETF Date: Wed, 24 Jan 2018 08:38:05 -0600 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Ben Campbell , The IESG , taps-chairs@ietf.org, taps@ietf.org Content-Type: multipart/alternative; boundary="001a114d7d3e784a6b0563869c48" Archived-At: Subject: Re: [Taps] Ben Campbell's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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, 24 Jan 2018 14:38:09 -0000 --001a114d7d3e784a6b0563869c48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Ben, On Wed, Jan 24, 2018 at 3:53 AM, Mirja K=C3=BChlewind wrote: > Hi Ben, > > this change rather removed the restriction to not analyze features of > security protocols (other than tcpinc); this is mainly the first sentence= . > As we see a closer integration of TLS with QUIC and we in general think > that security features are important, it is actually an important change = to > allow us to do some additional work in this space. > What Mirja said, but more than that - when I chartered TAPS, I was thinking about choosing between transport protocols, but that's morphing into choosing paths based on the way each potential path supports those transport protocols, and paths can differ in the way they treat transport security. So the working group should be including transport security in its analysis, and that was excluded in the current charter. Does that help? Spencer > Mirjas > > > On 24.01.2018 04:42, Ben Campbell wrote: > >> Ben Campbell has entered the following ballot position for >> charter-ietf-taps-01-00: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-taps/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Do I read correctly that the only change from the previous charter is to >> remove >> the paragraph about coordinating with TCPINC? If so, I'm not sure that >> change >> is important enough to justify rechartering, but I won't get in the way = if >> other people agree with it. >> >> >> > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --001a114d7d3e784a6b0563869c48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Ben,

On Wed, Jan 24, 2018 at 3:53 AM, Mirja K=C3=BChlewind <ietf@kueh= lewind.net> wrote:
Hi Ben,<= br>
this change rather removed the restriction to not analyze features of secur= ity protocols (other than tcpinc); this is mainly the first sentence. As we= see a closer integration of TLS with QUIC and we in general think that sec= urity features are important, it is actually an important change to allow u= s to do some additional work in this space.

=
What Mirja said, but more than that - when I chartered TAPS, I was thi= nking about choosing between transport protocols, but that's morphing i= nto choosing paths based on the way each potential path supports those tran= sport protocols, and paths can differ in the way they treat transport secur= ity. So the working group should be including transport security in its ana= lysis, and that was excluded in the current charter.

Does that help?

Spencer


Mirjas


On 24.01.2018 04:42, Ben Campbell wrote:
Ben Campbell has entered the following ballot position for
charter-ietf-taps-01-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-iet= f-taps/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Do I read correctly that the only change from the previous charter is to re= move
the paragraph about coordinating with TCPINC? If so, I'm not sure that = change
is important enough to justify rechartering, but I won't get in the way= if
other people agree with it.



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

--001a114d7d3e784a6b0563869c48-- From nobody Wed Jan 24 07:40:50 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 5AB5612DA47; Wed, 24 Jan 2018 07:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 rJc6hVsAYuy5; Wed, 24 Jan 2018 07:40:46 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 66345126CB6; Wed, 24 Jan 2018 07:40:46 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0OFejYY086451 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 Jan 2018 09:40:45 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: <09AE33BF-D211-469B-8118-5712951FB0B1@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8EF54A95-AF15-4E45-96A7-6A78FB0D8023"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 24 Jan 2018 09:40:44 -0600 In-Reply-To: <30b504ab-76e4-2f53-7f39-4678f2784753@kuehlewind.net> Cc: The IESG , taps-chairs@ietf.org, taps@ietf.org To: =?utf-8?Q?Mirja_K=C3=BChlewind?= References: <151676537558.24169.380539291213052978.idtracker@ietfa.amsl.com> <30b504ab-76e4-2f53-7f39-4678f2784753@kuehlewind.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Taps] Ben Campbell's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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, 24 Jan 2018 15:40:48 -0000 --Apple-Mail=_8EF54A95-AF15-4E45-96A7-6A78FB0D8023 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 24, 2018, at 3:53 AM, Mirja K=C3=BChlewind = wrote: >=20 > Hi Ben, >=20 > this change rather removed the restriction to not analyze features of = security protocols (other than tcpinc); this is mainly the first = sentence. As we see a closer integration of TLS with QUIC and we in = general think that security features are important, it is actually an = important change to allow us to do some additional work in this space. I had read that to just move the restriction not to work on security = into the =E2=80=9Cout of scope=E2=80=9D section above, but I can see = that there could be a difference between =E2=80=9Cwon=E2=80=99t work on = security protocols=E2=80=9D and =E2=80=9Cwon=E2=80=99t analyze the = features of security protocols=E2=80=9D. Were those statements intended = to prohibit substantially different things? >=20 > Mirja >=20 > On 24.01.2018 04:42, Ben Campbell wrote: >> Ben Campbell has entered the following ballot position for >> charter-ietf-taps-01-00: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-taps/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Do I read correctly that the only change from the previous charter is = to remove >> the paragraph about coordinating with TCPINC? If so, I'm not sure = that change >> is important enough to justify rechartering, but I won't get in the = way if >> other people agree with it. >>=20 >>=20 >=20 --Apple-Mail=_8EF54A95-AF15-4E45-96A7-6A78FB0D8023 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----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpoqPwACgkQgFZKbJXz 1A0K7Q/+MFCXrSF+eitIwIfxv8AUQgNO3EIhc84Rq+uQaLs10x0W5kjWt5Yl0fwI 8dcGeGHvVkE0tP1Sdyq7qhWNetL4jJtsMKHyaSolHPB4knx5ru0OpwCSYXVHoo5I tZfG6iLg+0Swr6j1w2EOk1ekXpeBQR1xPMjpNhQWgHkWVXIQuRZZeowL6cY8Ab6Z ToSp0xZZDvL6p+VBUAdYJACV6gMXBjsUJcPl0Cqzu4aG45kNsMNX3a4me99wzspm 80syZHMEiUZ/pExLhxS8X52z5QJG3KGAB1zGM5gqxeYUAlDyd7rZ24EY/k7WxU4q K0IwQZbu0Guhv49/r0jvkyt1zzxY81ph8q1Xau5fpAiZ3B69psNFBKKPNDN9kGI0 EgNnxnFNoFkeM2+gERqmgCh03CLiCXhqYPdCIhz1lF2PwC/hNedL1YfPWzFw/i6W vgawgVX0y3SHdDdryDp7fvOQZaCQxMLgvEhWmyeH//Amf19eiXUuNJzFLk+b7TfI 2YU8jLTbyduVpRkfW8SgY/kTNqd8CwXGUP9pOgLn5qkr1EikMhxbxbiMunCer3xw 0glwySDCQXKjQS/TiyUZM7h93EyzgZeTcVpQWnCjqFmW9AKAx2J1jJ5iRN/MlkRg FlvoXQMS121rEewwPDe/k5cp6H7r7lsjy7vHt7o4UdhlatJ6tvk= =6lz3 -----END PGP SIGNATURE----- --Apple-Mail=_8EF54A95-AF15-4E45-96A7-6A78FB0D8023-- From nobody Wed Jan 24 07:42: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 2540F126CB6; Wed, 24 Jan 2018 07:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 o7rgwItssVtH; Wed, 24 Jan 2018 07:42:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 7B017126C3D; Wed, 24 Jan 2018 07:42:22 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0OFgK37086624 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 Jan 2018 09:42:21 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: <5CA8D18C-754D-4882-8CC3-FC8797391762@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A467300F-662B-4C49-BA06-2771C90BBCD3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 24 Jan 2018 09:42:19 -0600 In-Reply-To: Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , The IESG , taps-chairs@ietf.org, taps@ietf.org To: Spencer Dawkins at IETF References: <151676537558.24169.380539291213052978.idtracker@ietfa.amsl.com> <30b504ab-76e4-2f53-7f39-4678f2784753@kuehlewind.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Taps] Ben Campbell's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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, 24 Jan 2018 15:42:24 -0000 --Apple-Mail=_A467300F-662B-4C49-BA06-2771C90BBCD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 24, 2018, at 8:38 AM, Spencer Dawkins at IETF = wrote: >=20 > Hi, Ben, >=20 > On Wed, Jan 24, 2018 at 3:53 AM, Mirja K=C3=BChlewind = wrote: > Hi Ben, >=20 > this change rather removed the restriction to not analyze features of = security protocols (other than tcpinc); this is mainly the first = sentence. As we see a closer integration of TLS with QUIC and we in = general think that security features are important, it is actually an = important change to allow us to do some additional work in this space. >=20 > What Mirja said, but more than that - when I chartered TAPS, I was = thinking about choosing between transport protocols, but that's morphing = into choosing paths based on the way each potential path supports those = transport protocols, and paths can differ in the way they treat = transport security. So the working group should be including transport = security in its analysis, and that was excluded in the current charter. >=20 > Does that help? Yes, and it answers the question I just asked in response to Mirja=E2=80=99= s email :-) Would it make sense to put =E2=80=9Cinclude transport security in it=E2=80= =99s analysis=E2=80=9D in the explicitly in-scope bits? >=20 > Spencer >=20 >=20 > Mirjas >=20 >=20 > On 24.01.2018 04:42, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > charter-ietf-taps-01-00: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-taps/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Do I read correctly that the only change from the previous charter is = to remove > the paragraph about coordinating with TCPINC? If so, I'm not sure that = change > is important enough to justify rechartering, but I won't get in the = way if > other people agree with it. >=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_A467300F-662B-4C49-BA06-2771C90BBCD3 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----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpoqVsACgkQgFZKbJXz 1A0/NQ/+PzaBmTE+mROmBPJI2yoJf8TjjLYUyHW/O8yzdrivPylqf2hldpi2Hs7f L854m+2epmFxE5qakKqz3uSwVr7XHkxkIRoKDLunIL9MoBvrFHlCmfGLITLvd9Qc 4X9P877kjxPxG9QyiEa/zUge2ywUn8bdM8QRiXeUUTApTmRWzhRpqCunIaT+Hlp6 OfGBYldZs+Y9CNHiuamFLI4Lri/1CnE1WXr7t2w6y5KndW+CFFGg3SFxbquIXzN9 bpoF1J0gjiejvVunJ34Ls7jaN0lullEnXuenxc1PW3NqlhJj8t/YodLpixY7KLiq JfN+3X8hyODDv2k7y+VqO+v1D6MnZg7tatkNkWdqy72IsWgRfuHEmnWuJWm6G84p u5EjwOqR/OaEkrY4irDATNZovfkHAIqOb29nCuid8ovkT1v8gYVwqGNDjwy+BKna jHiuXzY6DL1IjDAu5A58tAuhLBzenwxHUu/Bn8lV2ZnYV5IPilw1tPZOIMNX3nS+ yYm3gOuIWAN72tYQzPAa19Hl+8VH+HAr+cSyKJ7B8aCXo2AVtBWJ2xtaQQ2r2a2L G+fZkDfqUQcewPW2XvtUFAD166wCkPWAQGXnD3WPwGn6k7E8R9ulDsrpABEM5kbM kV/WPI7eGH+PQwwlG8ZVnrwLNynYoZJNbCylwPo7hMRQMiiJCfA= =G/Yq -----END PGP SIGNATURE----- --Apple-Mail=_A467300F-662B-4C49-BA06-2771C90BBCD3-- From nobody Wed Jan 24 08:20:16 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 7AFA31205D3; Wed, 24 Jan 2018 08:20:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: taps-chairs@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151681080944.22669.18174017653662773869.idtracker@ietfa.amsl.com> Date: Wed, 24 Jan 2018 08:20:09 -0800 Archived-At: Subject: [Taps] Alissa Cooper's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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, 24 Jan 2018 16:20:10 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-taps-01-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Since the point of this update is to add security analysis to the charter scope, would it make sense to specify how the WG plans to engage with the security area, as is typically done when there is overlap or coupling between work in different WGs? E.g., will the WG be seeking early review from the security area on relevant drafts? From nobody Wed Jan 24 11:53:23 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 8FA1312700F; Wed, 24 Jan 2018 11:53:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: taps-chairs@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151682360154.22641.15130233207454756485.idtracker@ietfa.amsl.com> Date: Wed, 24 Jan 2018 11:53:21 -0800 Archived-At: Subject: [Taps] Kathleen Moriarty's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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, 24 Jan 2018 19:53:21 -0000 Kathleen Moriarty has entered the following ballot position for charter-ietf-taps-01-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It would be nice to see the goals of the WG include descriptions of security properties for the described protocols. I don't see any mention of security properties in comparison work for the WG. Can you propose some text to add to the charter? Thanks. From nobody Wed Jan 24 15:13:58 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 AB6DE12AF84; Wed, 24 Jan 2018 15:13:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: taps-chairs@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151683563565.15990.9714453735483930902.idtracker@ietfa.amsl.com> Date: Wed, 24 Jan 2018 15:13:55 -0800 Archived-At: Subject: [Taps] Adam Roach's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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, 24 Jan 2018 23:13:56 -0000 Adam Roach has entered the following ballot position for charter-ietf-taps-01-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Ben that it would be valuable to add text to the charter that explicitly says what is being added (e.g., that the WG will "include transport security in its analysis"), rather than simply removing the prohibition. From nobody Wed Jan 24 18:39:43 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 E116012AF6E; Wed, 24 Jan 2018 18:39:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana To: "The IESG" Cc: taps-chairs@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151684797788.15925.7185496560141643927.idtracker@ietfa.amsl.com> Date: Wed, 24 Jan 2018 18:39:37 -0800 Archived-At: Subject: [Taps] Alvaro Retana's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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: Thu, 25 Jan 2018 02:39:38 -0000 Alvaro Retana has entered the following ballot position for charter-ietf-taps-01-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don’t object the charter, but I don’t think it should be approved without an updated set of milestones. From nobody Thu Jan 25 04:52:44 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 A2B95129C6C; Thu, 25 Jan 2018 04:52:37 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-8u-v4i9zhO; Thu, 25 Jan 2018 04:52:35 -0800 (PST) Received: from mail-yb0-f176.google.com (mail-yb0-f176.google.com [209.85.213.176]) (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 A3D4A1200B9; Thu, 25 Jan 2018 04:52:35 -0800 (PST) Received: by mail-yb0-f176.google.com with SMTP id u35so2941966ybi.1; Thu, 25 Jan 2018 04:52:35 -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; bh=/epmwu9hC+Cl6ZMtn1sdaBvNgUQ/e+BgC1cuXpQ9+Zk=; b=Ncf83ropwjGb8eEktVyb2mqboYLTbdbbE5LzEoEoEVGCWuX71RHUq/ACguW7DZ/d5Y ekeL184lNin1FhXcoimGur59GhIa/+n9464YldbWIRe1cVq/fxIoGFqlqF9uf2/EZbu2 /E/Nchtma/OH0/6umBbtrDC+QlHKwolPwvK18ulomR7NtbFhqh+ewC2fiOwB+/LMCqTD zzWHtn65vKNKmUCihWcxoj/GMzR4Fimf5jJ71oBC3/PjbYyh+2y7dHY1vCIqRUlruqni HLisZqMWhF1xYjGbfnXny4YSK1Vj0hACiLcfsxz2pJU0eImyXx3I8fG4EBU6ydGrbU/o gYfg== 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=/epmwu9hC+Cl6ZMtn1sdaBvNgUQ/e+BgC1cuXpQ9+Zk=; b=GoljmTvisABWxt6895PrqsGo1j/qYle/930k1KKGYrXnA8uqoy/uWCoXeL6DplSQ7i ztgRUS3hdHTiWskotN4dyizb1Q4O8BG5yl3PbgaKDbKxaJX315T9leFI8mKP7u+qVE2n d+Sz2qprDwGave9wjQhdwCJBg695yTbGuio2x4HURJAg1PyB8W7w0zZN4JiJ3v4IS8jl 0xgqs3+JeJSflrLoEmsEqbiadzD3xHOH6hZ/o+qbyYt+JBfkG5PoWsS/w/FYCHV1Gzo4 +s0Vcx62/12EP3mJ8ts285LKd107mOFA5lZBEOpcBrCAzAutKe+tFymGkDcG6XQTRjU6 EQcA== X-Gm-Message-State: AKwxytfPBnwlRGwSRJ3J85U8lFry8cYATsoZOESG5zUxlYnEMvhG9e1w I7Do/Vau2Gcbc9RUdLtQceISmSn/wpFEWjaTrvE= X-Google-Smtp-Source: AH8x22783HQ6RGia7UMf5ZnlC1JJAhrUBq0Y/QDat7zBniWNZ++C29gWX4SPGelHoUdV5ri1DqCSsqef2NwyYObknuE= X-Received: by 10.37.50.74 with SMTP id y71mr292567yby.417.1516884694527; Thu, 25 Jan 2018 04:51:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.20.4 with HTTP; Thu, 25 Jan 2018 04:51:34 -0800 (PST) Received: by 10.37.20.4 with HTTP; Thu, 25 Jan 2018 04:51:34 -0800 (PST) In-Reply-To: <5CA8D18C-754D-4882-8CC3-FC8797391762@nostrum.com> References: <151676537558.24169.380539291213052978.idtracker@ietfa.amsl.com> <30b504ab-76e4-2f53-7f39-4678f2784753@kuehlewind.net> <5CA8D18C-754D-4882-8CC3-FC8797391762@nostrum.com> From: Spencer Dawkins at IETF Date: Thu, 25 Jan 2018 06:51:34 -0600 Message-ID: To: Ben Campbell Cc: Mirja Kuehlewind , IESG , taps-chairs@ietf.org, taps@ietf.org Content-Type: multipart/alternative; boundary="001a1146db9861f43f0563993dc4" Archived-At: Subject: Re: [Taps] Ben Campbell's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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, 25 Jan 2018 12:52:38 -0000 --001a1146db9861f43f0563993dc4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Ben, On Jan 24, 2018 9:42 AM, "Ben Campbell" wrote: > On Jan 24, 2018, at 8:38 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > > Hi, Ben, > > On Wed, Jan 24, 2018 at 3:53 AM, Mirja K=C3=BChlewind wrote: > Hi Ben, > > this change rather removed the restriction to not analyze features of security protocols (other than tcpinc); this is mainly the first sentence. As we see a closer integration of TLS with QUIC and we in general think that security features are important, it is actually an important change to allow us to do some additional work in this space. > > What Mirja said, but more than that - when I chartered TAPS, I was thinking about choosing between transport protocols, but that's morphing into choosing paths based on the way each potential path supports those transport protocols, and paths can differ in the way they treat transport security. So the working group should be including transport security in its analysis, and that was excluded in the current charter. > > Does that help? Yes, and it answers the question I just asked in response to Mirja=E2=80=99= s email :-) Would it make sense to put =E2=80=9Cinclude transport security in it=E2=80= =99s analysis=E2=80=9D in the explicitly in-scope bits? That doesn't seem obviously wrong. We may have been more focused on removing the prohibition than saying what should happen, now that the prohibition has been removed :-) Let me talk to the TAPSters about specific wording. And thanks for asking. Spencer > > Spencer > > > Mirjas > > > On 24.01.2018 04:42, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > charter-ietf-taps-01-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-taps/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Do I read correctly that the only change from the previous charter is to remove > the paragraph about coordinating with TCPINC? If so, I'm not sure that change > is important enough to justify rechartering, but I won't get in the way i= f > other people agree with it. > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --001a1146db9861f43f0563993dc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Ben,

On Jan 24, 2018 9:42 AM, "Ben Campbell" <ben@nostrum.com> wrote:


> On Jan 24, 2018, at 8:38 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com&= gt; wrote:
>
> Hi, Ben,
>
> On Wed, Jan 24, 2018 at 3:53 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:
> Hi Ben,
>
> this change rather removed the restriction to not analyze features of = security protocols (other than tcpinc); this is mainly the first sentence. = As we see a closer integration of TLS with QUIC and we in general think tha= t security features are important, it is actually an important change to al= low us to do some additional work in this space.
>
> What Mirja said, but more than that - when I chartered TAPS, I was thi= nking about choosing between transport protocols, but that's morphing i= nto choosing paths based on the way each potential path supports those tran= sport protocols, and paths can differ in the way they treat transport secur= ity. So the working group should be including transport security in its ana= lysis, and that was excluded in the current charter.
>
> Does that help?

Yes, and it answers the question I just asked in response to Mirja=E2= =80=99s email :-)

Would it make sense to put =E2=80=9Cinclude transport security in it=E2=80= =99s analysis=E2=80=9D in the explicitly in-scope bits?

That doesn'= ;t seem obviously wrong.=C2=A0

We may have been more focused on removing the prohibition than sayin= g what should happen, now that the prohibition has been removed :-)

Let me talk to the TAPSters abo= ut specific wording.

And= thanks for asking.

Spen= cer



>
> Spencer
>
>
> Mirjas
>
>
> On 24.01.2018 04:42, Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> charter-ietf-taps-01-00: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charte= r-ietf-taps/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Do I read correctly that the only change from the previous charter is = to remove
> the paragraph about coordinating with TCPINC? If so, I'm not sure = that change
> is important enough to justify rechartering, but I won't get in th= e way if
> other people agree with it.
>
>
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

--001a1146db9861f43f0563993dc4-- From nobody Thu Jan 25 06:31:23 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 07A83120726; Thu, 25 Jan 2018 06:31:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: taps-chairs@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151689067798.20238.12264789631948366527.idtracker@ietfa.amsl.com> Date: Thu, 25 Jan 2018 06:31:17 -0800 Archived-At: Subject: [Taps] Benoit Claise's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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: Thu, 25 Jan 2018 14:31:18 -0000 Benoit Claise has entered the following ballot position for charter-ietf-taps-01-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Agree with Ben and Adam. I completely missed the subtleties of this change. The "or" in the following excerpt really don't help The following topics are out of scope for this Working Group: - Extension, modification, or creation of transport or security protocols What is out of scope: A, B, or maybe C or D? Not blocking this recharter, but please improve. From nobody Mon Jan 29 09:03:51 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 7E45812F2B2; Mon, 29 Jan 2018 09:03:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aafalk@akamai.com, taps-chairs@ietf.org, spencerdawkins.ietf@gmail.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151724542851.13017.2379793809174220496.idtracker@ietfa.amsl.com> Date: Mon, 29 Jan 2018 09:03:48 -0800 Archived-At: Subject: [Taps] taps - New Meeting Session Request for IETF 101 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, 29 Jan 2018 17:03:48 -0000 A new meeting session request has just been submitted by Aaron Falk, a Chair of the taps working group. --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic Second Priority: tcpinc nvo3 mptcp icnrg httpbis dots i2nsf saag Third Priority: mmusic tram sacm mile ipwave cfrg People who must be present: Aaron Falk Michael Welzl Spencer Dawkins Brian Trammell Zaheduzzaman Sarker Mirja Kuehlewind Tommy Pauly Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: U-shaped room would be nice, not required. --------------------------------------------------------- From nobody Tue Jan 30 16:42: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 48F201300E8; Tue, 30 Jan 2018 16:42:27 -0800 (PST) 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 cVxVcXBSRbGd; Tue, 30 Jan 2018 16:42:25 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 10FBF12EB22; Tue, 30 Jan 2018 16:42:25 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id v139so6247908ywg.4; Tue, 30 Jan 2018 16:42:25 -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; bh=siYOqn6nWRvFN58oFkAX4canVIalXqxhZMqTWllDnxA=; b=YHILOBH+XIYc8jX7ev01SePUBmBNL+MYHDyjHC/1xcuW6FF0mPR4QdG8T/DOAkLnG5 O6Qx5SqNDjqeKaJb7zeIlvmSjj+9jiGGVURXZgLS5q1pwtJtV1qd6TTyfrBATg6YQsSt S1RPL0gXF4cKlUOMzfGfWgDMgQpDMXsxQY4WIMKbSpuyuir0aV3bCMnjyyHfOKfeV/10 wUM7VjZP8l/tDcHtBNrrP4cJm1KljSoO3nIS2I0CIqHH01sNBBrjhOnpYjF+fFORVWes KL9ga6cYitHXKR5peZEBR1FTETZWP0U1ZBGK4yammHbpzd/v6lgwREXECnqCd2S3KB+w ezjA== 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=siYOqn6nWRvFN58oFkAX4canVIalXqxhZMqTWllDnxA=; b=lnWODFV0yF0uxu7ExJZ3F63TwMMW0vS0NPay9YxIdZM9YyJU3RauY/JrTy9hdu2267 BM2rzu3YxRABc3yIbO4BebxYs3CknZ9PqUhegrWzHAhbF4D/0O5FKUWHHuDgeuT+w4Qz RU6kqP7GHiwUAcHAnLk0lSl6MPzAMUaRoR8ZDWbf7KH1A8tqzjAn97efe7ZbVBCpmaiw Xz/u9I0SuboHwPPd9yphxjzv9tZEc2pfyM1sBm9IrCLdnkTNjW3DNyxD1/i673LbUv50 /pVuEKMv7dw5lymgeCt5v6y39OztPIXpqJtjFR6Ppn3uEOBKXQQz1GPHPKXAisYy2SgE D2/A== X-Gm-Message-State: AKwxytfleg2NoONYkmtul0tt/7hzdF7xJViWRJklCJTUUkftfB0kB8PS r3Xc7hGX0pOFbQTFEZ+eg69C8WdYfJ2FCNzkluA= X-Google-Smtp-Source: AH8x225mAUpAt3is16OX5uC59Ze9InYPvQV6IgUkiBc9PEIPO9CirEzev8Z5g6T8izTQljRwwXHZXSIVMjM4foTvIcA= X-Received: by 10.13.232.194 with SMTP id r185mr15600878ywe.284.1517359343878; Tue, 30 Jan 2018 16:42:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.41.69 with HTTP; Tue, 30 Jan 2018 16:42:23 -0800 (PST) In-Reply-To: <151681080944.22669.18174017653662773869.idtracker@ietfa.amsl.com> References: <151681080944.22669.18174017653662773869.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Tue, 30 Jan 2018 18:42:23 -0600 Message-ID: To: Alissa Cooper Cc: The IESG , taps-chairs@ietf.org, taps@ietf.org Content-Type: multipart/alternative; boundary="94eb2c08711eb04ab8056407c0e5" Archived-At: Subject: Re: [Taps] Alissa Cooper's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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, 31 Jan 2018 00:42:27 -0000 --94eb2c08711eb04ab8056407c0e5 Content-Type: text/plain; charset="UTF-8" Dear TAPsters, On Wed, Jan 24, 2018 at 10:20 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-taps-01-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-taps/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Since the point of this update is to add security analysis to the charter > scope, would it make sense to specify how the WG plans to engage with the > security area, as is typically done when there is overlap or coupling > between > work in different WGs? E.g., will the WG be seeking early review from the > security area on relevant drafts? > Alissa has a reasonable question here. Could you let me know what you're thinking about the best way to interact with the security area for this work? Thanks, Spencer --94eb2c08711eb04ab8056407c0e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear TAPsters,

On Wed, Jan 24, 2018 at 10:20 AM, Alissa Cooper <alissa@coop= erw.in> wrote:
Alissa Coope= r has entered the following ballot position for
charter-ietf-taps-01-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-iet= f-taps/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Since the point of this update is to add security analysis to the charter scope, would it make sense to specify how the WG plans to engage with the security area, as is typically done when there is overlap or coupling betwe= en
work in different WGs? E.g., will the WG be seeking early review from the security area on relevant drafts?

Aliss= a has a reasonable question here. Could you let me know what you're thi= nking about the best way to interact with the security area for this work?<= /div>

Thanks,

Spencer=C2=A0
--94eb2c08711eb04ab8056407c0e5-- From nobody Tue Jan 30 16:50:50 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 53CF513147D; Tue, 30 Jan 2018 16:50:38 -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 8tY2SHeZs2Yg; Tue, 30 Jan 2018 16:50:36 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E79126D74; Tue, 30 Jan 2018 16:50:36 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id k201so12665725qke.9; Tue, 30 Jan 2018 16:50:36 -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; bh=k1kup5t02erPBFm/xyzdb4lcfFwbUMV1MCEVtnxFTrQ=; b=spRZcW8vj41T7FEiRAcymPIGBr49DoSk8D2jQJGGySPaDZV8pasm28BaYWnUeK4ezF yeFkBt6gEU/xDUAo8cl6NjGR5N6TfLijC8jtylc0BuLOOsJuDP91KADBxeVKTFOAKlaf m8Gv5qDRx9xgPxVGbK1rZs3wgl+M3YkzX1D406aDXgNqvWAqzp3haoi0zl/WJwIl7E7Q tppUbqKf0Y5BFuziFSP+IUgkGHd5ybNUkcOUio6UlGlY3WX9wr8VSKPfi/+eWDN9M2Ei TNl4fPDiYGEJLBD/BfmySvjNjnkzU9yNMpON/uWNTAm6YiD9reLDeOP5/nWo/Fp9nSSG Znrw== 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=k1kup5t02erPBFm/xyzdb4lcfFwbUMV1MCEVtnxFTrQ=; b=Wxh82CFHEmnc1gGh1T4qaPWZ+KYlaAK9j5Ywo6eJTGCtFelc0HS4w81hcwp+/uJFLH B3e5gWyju2ijQjPKjqgTKLgx0ui8zq1GM8fvnrt/YRB7OYIeMlghqIGpg3Pst+qRM1YL /ht8nU7KfYITjzeVlasnjp3u8xeMf2z7LYvknkUNgKziIJUg8oajgIl1E7IaWh4zSmUQ T5nPSYHnnZ/aBMOhlDsp+U/KsEcLykgO+WSAcJFY6HW8Ty3NgsSmwwbZElorKhKqNWHM 5duTtKGB+fsOI0vTKeDLg3vjybEbCDKRcrbN8Dq1NRvnBS9SAbdy2qx7iDcRoe3eoeDf A0Hg== X-Gm-Message-State: AKwxyteut5n805T5ECNOtMPRMNjkDk527EuHSm4jI1+Ien7u4T2xnOg9 +ydcxRSU8wmmM1tsrm+2rcSmh7KwxQBKfTROZ/Q= X-Google-Smtp-Source: AH8x227nmIQQgAv519E0mAMZvBU423THa//1W913OaO35qWvgFQV34SQWmid63segEALad0TfB7XIWAxKsRxLiHVc+s= X-Received: by 10.55.96.4 with SMTP id u4mr45144690qkb.323.1517359835145; Tue, 30 Jan 2018 16:50:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.83.72 with HTTP; Tue, 30 Jan 2018 16:50:34 -0800 (PST) In-Reply-To: References: <151681080944.22669.18174017653662773869.idtracker@ietfa.amsl.com> From: Christopher Wood Date: Tue, 30 Jan 2018 16:50:34 -0800 Message-ID: To: Spencer Dawkins at IETF Cc: Alissa Cooper , taps-chairs@ietf.org, The IESG , taps WG , ekr@rtfm.com Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Taps] Alissa Cooper's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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, 31 Jan 2018 00:50:38 -0000 Hi Spencer, On Tue, Jan 30, 2018 at 4:42 PM, Spencer Dawkins at IETF wrote: > Dear TAPsters, > > On Wed, Jan 24, 2018 at 10:20 AM, Alissa Cooper wrote: >> >> Alissa Cooper has entered the following ballot position for >> charter-ietf-taps-01-00: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-taps/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Since the point of this update is to add security analysis to the charter >> scope, would it make sense to specify how the WG plans to engage with the >> security area, as is typically done when there is overlap or coupling >> between >> work in different WGs? E.g., will the WG be seeking early review from the >> security area on relevant drafts? > > > Alissa has a reasonable question here. Could you let me know what you're > thinking about the best way to interact with the security area for this > work? I imagined we'd circulate polished drafts to SecDispatch or SAAG for review. However, if there is relevant precedent in this sort of cross-area collaboration, it'd make sense to follow that instead. Best, Chris From nobody Wed Jan 31 10:41:23 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 EAC9712EBE3; Wed, 31 Jan 2018 10:41:21 -0800 (PST) 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 KDgsYO8QHd1d; Wed, 31 Jan 2018 10:41:19 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 B388712ECB2; Wed, 31 Jan 2018 10:41:19 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id t201so8338144ywf.1; Wed, 31 Jan 2018 10:41:19 -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; bh=0J7aCA9egLVjxVExkeF5vf9B4Jv/sWgOStsWEvcNlMU=; b=Q+Wgi8L8rZoeI9yGDG8DP/1ncL0KUxPa6+2c6iKeg962+/PwXGbnNobY4vi2Eu3xUl STSTUqMsqPb35KXeMoumJWFp1BkZYah3dQy31LbDyC37/r7UtwZFfQq0PG/MVYZwSsEU A2SwIZw2x7m81mifUALhVAT3joWGwazablC4F/gXquzROl1bwXVp78xJpjTaqn5X/yDk 5HUg0wymjesFYClRySKw0Gt7oaHIjzAWkYNNUR1oKEgMSzTd4qFSzhBE0/vNV1EXjMvJ 5SglDTcQLFObdiT1usbYnV3ZnWlsl6e78livyuvaHwmn7zIDaRIQJY0nwo3LI5TrjD2y AF2w== 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=0J7aCA9egLVjxVExkeF5vf9B4Jv/sWgOStsWEvcNlMU=; b=JwLTl4hUnYHgz+KY0OPTBuq9G6ysTfahhS86ZFzvKQVcF7X3KPkinqEwa864PqmTFx x3f3XWAcMfYlGDpRc40IEteB+G/mGPBjMRK3jRiFT2X8O/YY1kgXJFa17/4Xbw4ueKVx MExJKAL7Ci6amjYaz1kU6uJHxcY6yf3KlRHCzUrvFXTv49b2QfF+C1OBJnAC20g7SD8W 4KX3bFuwUwJBCBQUa6lL5fmyTSI11cwT1ErK4+ehnei8SbPFiBvBzPiugdg10ZCgHlwa EirkgJ2pgKyGA7pBfweAOKgf+WYXq28YbCCF5mkNeVjwODGk4rMmgNc3MCg2ajWFVeql acjw== X-Gm-Message-State: AKwxytdWHzn41ryDRxTCuSE7Yu6nkAJUs6+d1U/gagDIwH/Hk4WmytnD fpWD7Wz4wszQJ84n+mTDpF4N9+vLHZW2jTTNSJQ= X-Google-Smtp-Source: AH8x226zT/gE+Vk6V/WGSTL2AxgzfQBFLiEFlYYItIFnOP1sac04q/LlgkqYQP8TTQhSPXgGEiYxEKRiRh1VU7RujS8= X-Received: by 10.129.87.2 with SMTP id l2mr23249933ywb.454.1517424078752; Wed, 31 Jan 2018 10:41:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.41.69 with HTTP; Wed, 31 Jan 2018 10:41:18 -0800 (PST) In-Reply-To: <151689067798.20238.12264789631948366527.idtracker@ietfa.amsl.com> References: <151689067798.20238.12264789631948366527.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 31 Jan 2018 12:41:18 -0600 Message-ID: To: Benoit Claise Cc: The IESG , taps-chairs@ietf.org, taps@ietf.org Content-Type: multipart/alternative; boundary="001a113a3c4e301170056416d304" Archived-At: Subject: Re: [Taps] Benoit Claise's No Objection on charter-ietf-taps-01-00: (with COMMENT) 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, 31 Jan 2018 18:41:22 -0000 --001a113a3c4e301170056416d304 Content-Type: text/plain; charset="UTF-8" Hi, Benoit, On Thu, Jan 25, 2018 at 8:31 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > charter-ietf-taps-01-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-taps/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Agree with Ben and Adam. I completely missed the subtleties of this > change. > > The "or" in the following excerpt really don't help > The following topics are out of scope for this Working Group: > - Extension, modification, or creation of transport or > security protocols > > What is out of scope: A, B, or maybe C or D? > > Not blocking this recharter, but please improve. > Agreed. I had stuffed more text into an existing bullet, and the new text would almost certainly be clearer in its own bullet, so separating into - Extension, modification, or creation of transport protocols - Extension, modification, or creation of security protocols Thanks, Spencer --001a113a3c4e301170056416d304 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Benoit,

On Thu, Jan 25, 2018 at 8:31 AM, Benoit Claise <bclaise@cisco.c= om> wrote:
Benoit Claise has entered the following ballot position for
charter-ietf-taps-01-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-iet= f-taps/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Agree with Ben and Adam.=C2=A0 I completely missed the subtleties of this c= hange.

The "or" in the following excerpt really don't help
=C2=A0 =C2=A0The following topics are out of scope for this Working Group:<= br> =C2=A0 =C2=A0- Extension, modification, or creation of transport or
=C2=A0 =C2=A0 =C2=A0security protocols

What is out of scope: A, B, or maybe C or D?

Not blocking this recharter, but please improve.

<= /div>
Agreed. I had stuffed more text into an existing bullet, and the = new text would almost certainly be clearer in its own bullet, so separating= into

=C2=A0 =C2=A0- Extension, modification,= or creation of transport protocols

=C2=A0 =C2=A0- Extension, modification, or creation of se= curity protocols

=
Thanks,

Spencer
--001a113a3c4e301170056416d304--